Когда стартапу нужен CTO ради выручки, а не только ради кода

Почему проблема начинается вне кодовой базы

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

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

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

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

Первые трещины обычно видны в бизнес-сигналах:

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

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

Основатель, который спрашивает только: «Как быстро мы выпускаем продукт?», может пропустить более трудный вопрос: «Почему каждая новая сделка обходится так дорого в обслуживании?» Именно там риск для выручки проявляется раньше всего.

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

Что заранее говорят продления

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

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

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

Несколько сигналов заслуживают особого внимания:

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

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

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

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

Что показывают пилотные сделки

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

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

Конверсия пилотов показывает, успевают ли клиенты получить реальный результат до того, как у команды закончатся время или внимание. Если конверсия остается слабой несколько месяцев подряд, стоит считать, что в продукте или процессе где-то есть долг.

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

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

Для каждого пилота отслеживайте несколько простых фактов:

• сколько пилотов стартовало
• сколько дошло до первой ценности
• сколько времени заняла первая ценность
• сколько часов сотрудников ушло на настройку и поддержку
• сколько пилотов перешло в платное использование

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

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

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

Как валовая маржа показывает скрытое напряжение

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

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

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

Именно так прячется кастомная работа. Часто она растворяется внутри обычной поставки, поэтому никто не называет ее сервисной. Разработчик подправляет экспорт для одного клиента. Продакт-менеджер пишет особые правила для другого. Поддержка три раза объясняет сценарий, который должен занимать пять минут. В счете написано SaaS, а работа выглядит как агентская.

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

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

CTO с фокусом на выручку задает прямой вопрос: какие части поставки должны исчезнуть внутрь продукта, а какие должны остаться человеческими? Проблемы с маржой редко начинаются с одного дорогого сервера. Они начинаются тогда, когда команда продолжает делать работу, которую уже должен делать продукт.

Как пошагово проверить сигналы

Начните с четырех чисел за последние три–шесть месяцев. Оставьте их простыми и, если можете, разделите по типам клиентов:

• уровень продлений
• конверсия из пилота в оплату
• срок окупаемости клиента
• валовая маржа по продукту или сегменту аккаунтов

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

Затем запишите причину каждого задержанного продления, потерянного пилота или просадки маржи. Используйте простые категории: пробел в продукте, медленный онбординг, кастомная работа, слабое ценообразование, плохое соответствие, нагрузка на поддержку. Одной короткой заметки на аккаунт достаточно. После десяти-пятнадцати записей закономерности обычно уже сложно не заметить.

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

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

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

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

Простой пример из типичного сценария стартапа

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

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

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

Затем проявляется проблема с маржой. Каждый новый аккаунт требует ручной настройки, очистки данных, кастомных правил и большой поддержки в первые 30 дней. Один инженер тратит часы на онбординг. Поддержка отвечает на базовые вопросы, на которые продукт должен отвечать сам. Клиент с ежемесячным платежом в 4 000 долларов звучит неплохо, пока компания не посчитает реальный труд, который стоит за этим аккаунтом.

Именно в этот момент CTO перестает думать только о выпуске фич. Более трудный вопрос — какая работа должна стать стандартной, какие запросы нужно остановить и где команда теряет деньги даже при росте выручки. Если продления стоят на месте, пилоты спасает основатель, а онбординг съедает маржу, компании нужен не только инженерный, но и бизнес-триаж.

Хороший CTO по-прежнему заботится о скорости продукта и качестве кода. Но на этой стадии ему также нужно сидеть вместе с продажами, смотреть на расширение по аккаунтам и убирать кастомную работу, из-за которой компания буксует.

Ошибки, которые основатели допускают на этом этапе

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

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

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

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

Когда основатели считают скидки проблемой коучинга продаж, они пропускают более глубокое исправление. Команда закрывает выручку, но каждый контракт стартует слабее и стоит дороже в обслуживании.

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

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

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

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

Быстрая проверка на этот месяц

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

До конца месяца перед собой положите пять чисел:

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

Одно слабое число бывает у любого стартапа. Три слабых числа одновременно обычно указывают на одну и ту же проблему: компания по-прежнему продает и поставляет продукт вручную, даже если снаружи он выглядит зрелым.

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

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

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

Часто именно в этот момент компании нужен человек, который умеет связать продукт, продажи и поставку. И это не всегда означает найм на полную ставку.

Что делать дальше

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

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

Простой разбор работает лучше большого аудита:

• перечислите последние 10 продлений, расширений, зависших пилотов и потерянных сделок
• отметьте, где клиент застрял: настройка, отсутствующий сценарий, медленная поддержка, цена или стоимость доставки
• выберите одну-две проблемы, которые повторяются снова и снова
• назначьте одного человека за каждую область: здоровье продлений, поток пилотов и исправление маржи
• поставьте цель на 30 дней с одним числом, которое должно сдвинуться

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

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

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

Поставьте ревью в календарь уже на этой неделе. Принесите реальные цифры, назначьте владельцев до конца встречи и выберите первое исправление до того, как кто-нибудь попросит еще одну фичу.