Разрастание продукта в стартапе: как акселераторы останавливают его на раннем этапе

Как выглядит разрастание продукта в стартапе

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

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

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

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

Ранние сигналы легко пропустить:

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

Меняется и язык. Когда команда перестаёт говорить «вот так работает наш продукт» и начинает говорить «зависит от клиента», продукт уже уходит в сторону.

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

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

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

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

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

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

Акселераторы иногда невольно усугубляют это. Давление перед demo day реально, и менторы часто спрашивают: «Сколько клиентов подписалось?» Вопрос справедливый, но он не учитывает стоимость выполнения. Две подписанные сделки, которым каждой нужно по 30 часов настройки, могут навредить сильнее, чем один более скромный клиент на стандартном тарифе.

Хорошая привычка — с самого начала отслеживать несколько простых цифр:

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

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

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

Именно поэтому ментор, startup advisor или Fractional CTO должен задать жёсткий вопрос: если ещё пять клиентов попросят то же самое, сможет ли команда поддерживать это, не ломая roadmap? Если ответ «нет», сделка должна стоить дороже, быть поставлена на более поздний срок или получить вежливый отказ.

Сначала задайте одно стандартное предложение, пока кастомные запросы не навалились

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

Базовое предложение помогает ранним продажам оставаться простыми. Каждому стартапу нужен один пакет, который он продаёт первым, с одной ценой и одним понятным объёмом. Когда покупатель спрашивает: «Что мы получаем?», ответ уже должен быть готов на простом языке.

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

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

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

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

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

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

Как шаг за шагом оценивать исключения

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

Начните с одного вопроса: нужны ли это хотя бы ещё двум или трём будущим клиентам? Если ответ «нет», считайте это исключением, а не функцией продукта. Именно это решение не даёт roadmap заполняться работой ради одного клиента.

Хорошо работает простой способ расчёта:

1. Проверьте спрос за пределами текущей сделки. Смотрите на воронку, а не только на этого клиента. Если больше никто не просит это же самое, считайте, что повторно продать решение будет сложно.
2. Посчитайте полную стоимость выполнения. Включите время разработки, QA, крайние случаи, документацию, изменения в онбординге и нагрузку на поддержку после запуска.
3. Оцените задержку roadmap. Если команда потратит две недели на этот запрос, какая запланированная работа сдвинется? Назначьте этой задержке цену, даже если она будет приблизительной.
4. Добавьте надбавку, а не скидку. Кастомная работа должна стоить дороже стандартной настройки, потому что она создаёт больше рисков и больше будущей работы.
5. Назначьте дату окончания. Пересмотрите исключение через 6 или 12 месяцев, а затем уберите его, продлите или встроите в основной продукт.

Небольшой пример делает это нагляднее. Клиент просит кастомный формат отчёта. Разработка занимает 20 часов. Тестирование — 8. Поддержке, скорее всего, понадобится ещё 2 часа в месяц, потому что финансовые команды замечают каждое несоответствие. При этом команда откладывает исправление онбординга, которое помогло бы каждому новому клиенту. Если вы берёте деньги только за первые 20 часов, вы теряете деньги и делаете продукт более запутанным.

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

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

Простой пример из когорты акселератора

Одна B2B SaaS-команда в акселераторе продала свой первый серьёзный пилот средней компании. Клиенту понравился продукт, но он попросил кастомный CSV-экспорт, чтобы сотрудники могли загружать данные в старую внутреннюю систему. Основатель сразу сказал «да». Казалось, что запрос маленький, а сделка — слишком хорошая, чтобы ею рисковать.

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

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

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

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

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

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

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

Защитите roadmap во время продаж

Давление со стороны продаж может быстро увести продукт не туда. Один крупный потенциальный клиент просит особый сценарий работы, другой — кастомный отчёт, и внезапно каждый спринт забит боковыми задачами.

Решение не в том, чтобы отвергать каждый необычный запрос. Решение — контролировать, кто говорит «да», как часто и по какой цене.

Оставляйте фиксированную долю каждого спринта под основной roadmap. Большинству команд нужен жёсткий минимум, а не расплывчатая цель. Если 70–80% времени спринта остаётся за основным продуктом, продажи всё ещё могут закрывать сделки, не выдёргивая инженеров с плана каждую неделю.

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

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

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

Несколько правил делают это проще:

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

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

Такая дисциплина может казаться жёсткой. Но она экономит месяцы уборки позже.

Ошибки, из-за которых продукт становится запутанным

Запутанный продукт редко появляется из-за одного плохого решения. Обычно он растёт из маленьких обещаний, которые в моменте кажутся безобидными. Один кастомный field здесь, один ручной отчёт там — и вскоре команда тратит больше времени на крайние случаи, чем на улучшение продукта.

Распространённая ошибка — позволять продажам обещать функции до того, как продукт рассмотрит запрос. Основатель хочет закрыть сделку, клиент звучит срочно, и команда слишком рано говорит «да». Потом инженерная команда получает поспешное обязательство, которое может не подходить roadmap, коду или другим клиентам.

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

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

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

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

Короткая проверка ловит большую часть этого. Спросите:

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

Если ответ «нет» больше одного раза, скорее всего, сделка стоит дороже, чем кажется.

Быстрые проверки перед тем, как одобрить индивидуальную сделку

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

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

• Попросит ли это вскоре больше клиентов? Если да, возможно, этому место в продукте, а не в одном контракте.
• Сможет ли команда сделать это, не меняя основной сценарий для всех остальных? Запросы, которые затрагивают вход, биллинг, права доступа или основной путь пользователя, обычно стоят дороже, чем кажутся сначала.
• Взяли ли вы деньги за настройку, время поддержки и будущую поддержку? Основатели часто считают только разработку и забывают про хвост. Именно там исчезает маржа.
• Кто будет отвечать за это после закрытия сделки? Назначьте одного человека или команду. Если владельца нет, тикеты поддержки начнут прыгать туда-сюда.
• Какой пункт roadmap вы отложите, если скажете «да»? Запишите конкретную функцию или исправление, которое сдвинется.

Эта проверка занимает десять минут. Она может сэкономить месяцы уборки.

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

Акселераторы могут помочь, заставляя основателей записывать эти ответы до того, как они одобрят сделку. Хороший advisor или Fractional CTO часто задаёт ещё один вопрос: «Будет ли это всё ещё иметь смысл, когда у вас появится ещё 20 клиентов?» Этот вопрос очень быстро отрезвляет.

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

Индивидуальная сделка стоит того только тогда, когда сходятся цифры и продукт остаётся понятным.

Что должны сделать основатели и акселераторы дальше

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

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

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

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

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

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

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

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

Некоторым командам нужна помощь со стороны, потому что они слишком близко к проблеме. В таком случае startup advisor или Fractional CTO может проверить цену, запуск и границы продукта, пока беспорядок не стал ещё больше. Олег Сотников на oleg.is делает такую работу со стартапами и небольшими командами, особенно когда кастомные сделки начинают влиять на продукт сильнее, чем продуктовая стратегия.

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