Чек-лист встречи с CTO для фаундеров перед первым звонком

Почему первые звонки с CTO часто получаются расплывчатыми

Большинство первых звонков идут вяло по простой причине: фаундеры приносят давление, а не четкую проблему. Они говорят что-то вроде «разработка тормозит», «команда застопорилась» или «нам нужен AI». Эти раздражающие моменты реальны, но это все еще только симптомы. CTO не сможет дать полезный совет, если видит лишь симптомы.

Настоящая проблема обычно находится на один слой глубже. Релизы могут сдвигаться, потому что каждый измененный участок должен лично одобрять один старший инженер. Отдел продаж может постоянно просить кастомные доработки, и из-за этого дорожная карта каждую неделю перекраивается. Расходы на облако могут расти, потому что никто не уверен в текущей схеме и не решается ее упростить. Когда вы называете реальное узкое место, разговор очень быстро становится точнее.

Еще одна частая ошибка — выбирать инструменты до того, как понятное решение вообще сформулировано. Фаундеры спрашивают, какой стек выбрать, какую модель использовать или нужен ли им Kubernetes, переписывание с нуля или новый найм. Звучит конкретно, но часто это еще слишком рано. Если вы не назвали решение, которое стоит за вопросом про инструмент, совет превращается в гадание.

Размытые цели только ухудшают ситуацию. «Мы хотим масштабироваться», «нам нужно работать быстрее» и «нам нужно лучше использовать AI» могут означать что угодно. Вам нужно сократить время релиза с двух недель до двух дней? Снизить расходы на инфраструктуру на 30%? Выпустить enterprise-функцию и не сломать основной продукт? Полезный разговор с CTO начинается тогда, когда у цели появляются четкие границы.

Одна конкретная проблема еще и делает встречу честной. Она не дает всем уйти в общие темы, которые звучат умно, но ни к чему не ведут. Это особенно важно, когда вы говорите с человеком с широким опытом в продукте, инфраструктуре, найме и архитектуре. Такой опыт сильнее всего работает тогда, когда он направлен на реальное ограничение.

Короткая подготовительная заметка лучше длинной истории компании. Принесите одно узкое место. Скажите, сколько оно стоит во времени, деньгах или риске. Потом скажите, какое решение вы не можете принять сами. Это даст собеседнику что-то конкретное, что можно проверить, оспорить и улучшить уже в первые минуты.

Принесите одно узкое место, а не весь бэклог

Первая встреча становится полезной очень быстро, если вы приносите одну проблему, которая уже сегодня тормозит команду. Если прийти со всей дорожной картой, разговор превращается в экскурсию по идеям, просьбам и недоделкам. На это уходит время, а настоящая проблема прячется.

Выбирайте то место, где работа постоянно останавливается. Не самую большую мечту. Не самый длинный список желаний. Выбирайте то, из-за чего люди ждут, переделывают работу или откладывают релиз.

Хорошее узкое место звучит конкретно. «Нам нужно лучшее техрешение» — слишком расплывчато. «Наша команда не может выпускать по пятницам, потому что деплои все еще ломаются, и один инженер тратит на исправления полдня» — это уже то, на что CTO может отреагировать.

Четко назовите, где именно возникает блок. Укажите шаг, человека и ожидание. Работа над продуктом может останавливаться, потому что backend-команда ждет, пока один фаундер одобрит каждое изменение схемы. Отдел продаж может ждать инженеров, потому что для каждой демонстрации нужны ручные настройки. Когда вы показываете, где именно все стопорится, проблема перестает звучать абстрактно.

Частота тоже важна. Проблема, которая возникает каждую неделю, отличается от проблемы, появившейся один раз во время тяжелого запуска. Скажите, как часто это происходит и сколько людей это затрагивает. Даже грубого ответа достаточно. «Три раза за спринт» — уже нормально. «Почти каждая enterprise-сделка» — тоже.

Остальной бэклог лучше не приносить на звонок, если он не объясняет блокировку. Фаундеры часто добавляют туда все подряд: найм, продуктовую стратегию, аналитику, ценообразование и планы по AI. Большую часть этого можно отложить. Одно конкретное узкое место проще проверить, измерить и исправить.

Если нужен простой способ подготовиться, запишите три вещи: узкое место в одном предложении, точку, где работа останавливается, и как часто это происходит и кто ждет. Это полезнее, чем двадцать открытых задач. Хороший CTO, в том числе fractional CTO, сможет сделать намного больше с одним ясным ограничением, чем с кучей смешанных проблем.

Выберите одну твердую метрику

Расплывчатая проблема остается расплывчатой, пока рядом с ней не появится число. Если ваше узкое место — «слишком долго выпускаем», это ощущение. Если это «за последний месяц релизы сдвинулись с 2 дней до 9 дней», CTO уже может работать с этим сразу.

Берите число, которое вы уже отслеживаете. Не придумывайте новый показатель специально для встречи. Возьмите его из аналитики, биллинга, поддержки, логов ошибок, CRM или заметок по спринтам. Число, которому вы доверяете, пусть даже грубое, лучше красиво придуманной оценки.

Хорошие метрики чаще всего связаны с одной из четырех вещей: временем, деньгами, выручкой или сбоями. Выбирайте то, что болит сильнее всего. Если инженеры половину недели чинят баги, возьмите процент сбоев или количество багов. Если команда уперлась в найм, смотрите на скорость поставки или выручку на инженера. Если облачный счет растет, приносите реальную динамику расходов.

Одного числа недостаточно. Одна точка может ввести в заблуждение, поэтому возьмите еще короткий отрезок времени. Обычно для стартапа достаточно от двух до восьми недель. «Churn 6%» — слишком слабо. «Churn вырос с 3,8% до 6% за последние два месяца после изменений в онбординге» уже задает разговору форму.

Запишите метрику в одну строку рядом с узким местом. Формулируйте просто: «Узкое место: онбординг клиентов стопорится. Метрика: медианное время настройки выросло с 1,5 дня до 4 дней за последние 6 недель». В этой строке сразу два смысла: и боль, и ее масштаб.

Это еще и меняет тон разговора. Вместо обмена мнениями вы можете задавать более точные вопросы. Почему показатель сдвинулся? Что изменилось в продукте, команде или процессе? Какое исправление будет недорогим, а какое потребует более серьезного решения?

Одна честная метрика может сэкономить двадцать минут расплывчатых разговоров.

Назовите решение, которое вы не можете принять в одиночку

Первая встреча с CTO становится полезной, когда вы приносите одно застрявшее решение, а не общее чувство, что «с технарщиной все сложно». Скажите выбор вслух одним предложением. «Переписываем flow оформления заказа сейчас или продолжаем латать его до Q4?» — уже дает разговору форму.

Сделайте это выбором между двумя реальными вариантами. Избегайте фальшивых альтернатив вроде «починить» против «ничего не делать». Хорошая пара достаточно конкретна, чтобы можно было сравнить затраты, скорость и риск. Один путь может быть найм старшего инженера. Другой — пригласить fractional CTO на три месяца, чтобы сначала разобраться с архитектурой и процессами команды. Оба варианта реальные. У обоих есть компромиссы.

Запишите, сколько стоит ждать еще месяц. Многие фаундеры пропускают этот пункт, и тогда разговор остается абстрактным. Привяжите задержку к числу или к понятному бизнес-эффекту. Возможно, команда теряет 15 часов в неделю на ручной QA. Возможно, churn вырос с 3% до 5%. Возможно, сделка не закрывается, потому что enterprise-покупатели снова и снова спрашивают про безопасность и uptime. Ожидание всегда чего-то стоит.

Короткая заметка может выглядеть так:

• Решение: уходить от хрупкого монолита сейчас или отложить это до после запуска
• Вариант A: потратить 6 недель на исправление самых рискованных частей текущей командой
• Вариант B: продолжать выпускать фичи и принять более медленные релизы плюс больше инцидентов
• Цена ожидания 30 дней: примерно $12,000 потерянных сделок и еще две недели командного времени на переделки
• Финальное решение: фаундер принимает его после рекомендации CTO

Также скажите, кто будет принимать окончательное решение. Если вы — так и скажите. Если это должен одобрить софаундер, член совета директоров или head of product, тоже скажите. Хороший советник поможет вам подумать, но он должен понимать, кто владеет выбором.

Четкие решения приводят к четким советам. Расплывчатые проблемы приводят к длинным звонкам и почти нулевому прогрессу.

Уместите факты на одной странице

Ограничьтесь одной страницей. Если для объяснения проблемы нужны три страницы, разговор начнет уезжать еще до того, как станет полезным.

Смысл чек-листа встречи с CTO не в том, чтобы кого-то впечатлить. Он нужен, чтобы первые десять минут были достаточно ясными, и следующие двадцать можно было потратить на выбор, компромиссы и следующие шаги.

Этой странице нужны только четыре вещи: описание узкого места одним предложением простым языком, одна твердая метрика с текущим значением и желаемым значением, решение, которое вам нужно принять, с вариантами, между которыми вы выбираете, и один скриншот или простая схема, если это быстро снимет путаницу.

Опишите узкое место так, как объяснили бы его умному инвестору, который не знает ваш стек. «Онбординг клиентов стопорится, потому что наша команда все еще настраивает каждый аккаунт вручную» — понятно. «У нас проблемы с инфраструктурой и продуктом по всей активации» — слишком расплывчато, чтобы помочь.

Метрике нужен контекст. «Регистрации падают» — слабая формулировка. «Только 18% пользователей на trial завершают настройку, а нам нужно 35% к следующему кварталу» — уже то, с чем CTO может работать. Теперь у проблемы есть и масштаб, и цель.

Так же сформулируйте и решение. «Продолжаем латать текущее приложение, переписываем поток онбординга или добавляем внутренний инструмент для ops-команды? Нам нужно выбрать в этом месяце, пока sales не запустил новую кампанию». Это уже достаточно конкретно для настоящего обсуждения.

Используйте скриншот, если словами будет слишком долго. Путаный админский workflow, экран с неудачным деплоем или простая схема из блоков могут сэкономить пятнадцать минут. Обычно достаточно одной картинки. Пять карт превращают звонок в экскурсию.

Если вы отправите эту страницу до встречи, собеседнику придется меньше вытягивать факты из вас и больше проверять ваши предположения. Уже этого хватает, чтобы изменить тон разговора.

Простой пример для стартапа

У фаундера SaaS-стартапа каждую неделю повторяется один и тот же сценарий. Новые trial-пользователи регистрируются, начинают настройку и исчезают до того, как доходят до первой по-настоящему полезной задачи. Команда чувствует проблему в демо и ответах поддержки, но она остается расплывчатой, пока не появляется одно число: day-one activation rate составляет 24%.

Это число меняет разговор. Вместо общих слов о «плохом онбординге» фаундер может сказать: «Трое из четырех trial-пользователей не доходят до точки, где продукт начинает им помогать». CTO уже может работать с этим.

Фаундер также приносит одно решение, которое не может принять сам. Переписывать онбординг или добавить живую помощь на этапе настройки для перспективных новых trial? Оба варианта могут сработать, но у них очень разные затраты и риски.

Хороший разговор с CTO обычно начинается с выбора между компромиссами. Переписывание имеет смысл, если большинство пользователей путается на одном и том же шаге и команда может быстро выпускать изменения. Живая помощь при настройке имеет смысл, если клиентам нужен контекст, аккаунты дорогие, а команде нужны ответы уже на этой неделе, а не в следующем месяце.

Дальше разговор становится гораздо лучше. Переписывание может занять три недели, отвлечь дизайнера и двух инженеров от задач дорожной карты и все равно не решить реальную проблему, если продукт просит слишком много и слишком рано. Ручная помощь может стартовать уже завтра, показать команде, почему пользователи застревают, и быстро поднять активацию, но она требует времени каждый день и плохо масштабируется.

Именно здесь важнее всего не мнения, а затраты, скорость и риск. Если у стартапа 40 trial в месяц и небольшая команда, временный ручной шаг может оказаться разумнее. Если в ту же точку упираются сотни пользователей, ручная помощь превращается не в решение, а в заплатку.

Кто-то вроде Oleg Sotnikov, работающий как fractional CTO, скорее всего предложил бы короткий тест перед большой ставкой. Например, предложить помощь в настройке следующим 20 trial-аккаунтам, отследить активацию и сравнить ее с текущей базой. Если activation подскакивает с 24% до 40%, команда быстро получает полезный сигнал. Если нет, можно перестать гадать и перестроить поток настройки уже на реальных данных.

Ошибки, которые съедают первые полчаса

Самый быстрый способ испортить хороший разговор с CTO — начать с полной демонстрации продукта. Большинству первых встреч не нужна экскурсия по каждому экрану, каждой функции и всем идеям на следующий квартал. Если вы потратите двадцать минут на клик по приложению, человек на другой стороне все еще может не понять, где реальная проблема.

Короткое демо может помочь, если оно отвечает на один вопрос. «Пользователи уходят на этом шаге, и мы не знаем, это UX, скорость или ошибки backend» — у демо появляется задача. Все, что длиннее, обычно прячет узкое место, а не показывает его.

Еще одна частая ошибка — просить общую стратегию до того, как вы показали базовые факты. Фаундеры иногда начинают так: «Какой должна быть наша техстратегия на следующий год?» Звучит серьезно, но это слишком широко, чтобы ответить хорошо без контекста. CTO сначала нужно несколько твердых фактов: размер команды, текущий стек, темп релизов, история простоев, конверсия, burn rate или любой другой показатель, который связан с проблемой.

Грубые цифры лучше, чем никаких. Если данные у вас грязные, так и скажите и дайте лучшую оценку. «Кажется, завершение онбординга упало примерно с 62% до 45% за два месяца» — гораздо лучше, чем «мы знаем, что оно падает, но еще не выгрузили отчет». Серьезный разговор может начаться с несовершенных данных. Не может — с тумана.

Многие фаундеры также пытаются упаковать в один звонок четыре разных встречи. Они хотят советы по найму, дорожной карте, инфраструктуре, процессу продаж, автоматизации на AI и вопросам к инвесторам одновременно. В результате получаются поверхностные ответы и слабые решения.

Держите первую встречу короткой. Принесите одну бизнес-проблему, одну привязанную к ней метрику, одно застрявшее решение и один короткий контекст про команду или бюджет. Этого достаточно для полезного первого прохода. Даже если у советника есть опыт в продукте, инфраструктуре и AI-операциях, лучшие разговоры все равно начинаются с малого и конкретного.

Хороший чек-лист — это в основном фильтр. Уберите длинное демо. Уберите большой стратегический вопрос. Уберите пачку не связанных между собой тем. Но грубые цифры все равно принесите. Если первые полчаса останутся сфокусированными, во второй половине обычно удается дойти до самого важного: что делать дальше, кто должен это сделать и сколько это, скорее всего, будет стоить.

Быстрая проверка перед звонком

За пять минут до встречи сделайте честную проверку. Если ваши заметки не помещаются на один экран, скорее всего, они слишком расплывчатые.

Вы должны уметь сказать узкое место одним предложением. Держите его узким. «У нас ломается онбординг после регистрации» — подходит. «Техчасть замедляет нас» — нет.

Принесите одно твердое число и диапазон дат. «Переход из trial в платящих клиентов упал с 4,1% до 2,8% за последние 30 дней» или «деплои сорвались 6 раз в этом месяце» — этого достаточно. Одна метрика лучше, чем куча дашбордов.

Запишите решение простыми словами. «Переписываем этот поток или латать его еще один квартал?» — понятно. «Нам нужно обсудить архитектуру» — слишком туманно.

Потом скажите, что будет, если ничего не делать. Потеря выручки, срыв запуска, нагрузка на поддержку, выгорание команды или рост облачных расходов — все это меняет совет.

Эта проверка важна, потому что большинство первых звонков становятся мягкими, когда фаундеры приносят симптомы без ставки. CTO может помочь намного быстрее, если у проблемы есть форма, число и дедлайн.

Хорошо работает простой тест: прочитайте свои заметки вслух за 45 секунд. Если вы начинаете растекаться, сократите текст. Если метрике нужна длинная расшифровка, возьмите более чистую. Если решение звучит технически, а бизнес-риски по-прежнему неясны, перепишите его.

Например, не говорите: «У нас проблемы с производительностью, нужна помощь». Скажите: «Наша панель теперь загружается за 9 секунд для новых пользователей, по данным за последние 14 дней. Мы думаем, что это портит конверсию демо. Нам нужно решить, чинить ли query layer сейчас или отложить до после запуска. Если подождем, sales продолжит показывать медленный продукт».

Если вы разговариваете с fractional CTO вроде Oleg, такая подготовка помогает обеим сторонам быстро перейти к конкретике.

Что делать сразу после встречи

Хороший разговор все равно может никуда не привести, если заметки останутся размытыми. Прежде чем двигаться дальше, превратите обсуждение в один четкий следующий шаг. Назначьте одного ответственного, один тест и один дедлайн. Если ответственного нет, идея зависнет в чате и тихо исчезнет.

Тест важен, потому что «разобраться» — это не задача. «Измерить, где пользователи отваливаются на странице цен, к пятнице» — это задача. «Сравнить стоимость текущего стека с переносом одного сервиса на managed hosting» — тоже задача. Первый шаг должен быть достаточно маленьким, чтобы один человек мог быстро его завершить.

Запишите предположения, которые еще нужно доказать. После встречи фаундеры часто чувствуют уверенность, но команда все еще может только гадать о причине проблемы. Возможно, вы предполагаете, что пользователям сначала нужен mobile app. Возможно, вы думаете, что медленные релизы вызваны кодовой базой, хотя настоящая проблема — в процессе одобрения или слабом тестировании. Формулируйте каждое предположение простыми словами, чтобы его можно было проверить.

Отправьте короткое резюме команде в тот же день. Не ждите вылизанных заметок. Быстрое сообщение помогает всем оставаться на одной волне, пока разговор еще свежий. Включите проблему, которую вы договорились решать первой, метрику, за которой будете следить, следующий тест с ответственным и дедлайном, а также предположения, которые еще нужно проверить.

Это еще и помогает быстро заметить расхождение. Если два человека прочитают одно и то же резюме и увидят в нем разные действия, встреча была менее ясной, чем казалось.

Если план все еще оставляет два или три возможных пути, внешняя CTO-помощь может сэкономить время. Oleg Sotnikov на oleg.is работает со стартапами над техническим планированием, архитектурой, инфраструктурой и внедрением AI, так что короткий второй проход может быть полезен, когда выбор повлияет на команду на месяцы вперед. Это часто дешевле, чем потратить четыре недели на неправильное решение.

Полезный результат — не длинный документ. Это короткий список действий, с которых команда может начать уже завтра, и достаточно ясный, чтобы быстро подтвердить или опровергнуть идею.