Устойчивый запуск — это не попытка устранить любой риск. Это ситуация, когда собственник понимает основные допущения, ограничивает возможный ущерб и заранее знает, по каким данным будет принимать следующее решение.
1. Спрос: кто и почему должен купить
Есть ли реальные интервью, заявки, предзаказы, сделки или хотя бы подтверждённая проблема? Не подменяйте доказательство спроса размером рынка и интересом знакомых.
- кто конкретный сегмент;
- какую альтернативу использует сейчас;
- что заставит сменить её;
- какой канал приводит первых клиентов.
2. Экономика: работает ли единица
Посчитайте цену без налогов, переменные расходы, валовую маржу, CAC, стоимость обслуживания и постоянный контур. Если юнит-экономика отрицательная, рост только ускорит расход денег.
Не только оптимистичный план
Финансовая модель должна показывать, при каком ухудшении конверсии, цены или себестоимости проект перестаёт иметь смысл.
3. Деньги: сколько проект может потребить до результата
Постройте cash flow. Учтите найм до выручки, закупки, авансы подрядчикам, дебиторку и налоги. Определите максимальную потребность в деньгах и убедитесь, что не финансируете эксперимент резервом, от которого зависит основной бизнес.
4. Команда: кто реально будет делать работу
Новый проект часто строится на скрытом предположении, что текущая команда «как-нибудь возьмёт ещё». Укажите роли, часы, владельца результата и то, какие текущие задачи будут сняты.
Если проект требует компетенции на несколько часов в неделю, внешний эксперт может быть рациональнее штатного найма. Если нужен ежедневный владелец функции — временный консультант её не заменит.
5. Процессы: что изменится в операционке
Новые продажи создают новые задачи для производства, поддержки, финансов, документооборота и руководителей. Пройдите путь одной сделки от первого контакта до получения денег и последующего обслуживания.
6. Налоги: соответствует ли модель реальной сделке
Проверьте режим налогообложения, НДС, договорную цепочку, агентские отношения, трансграничные платежи и влияние роста выручки на лимиты. Налоговый сценарий в модели должен совпадать с тем, как реально продаётся продукт.
7. Право и регулирование
Нужна ли лицензия? Есть ли обязательная маркировка? Можно ли рекламировать продукт выбранным способом? Что с персональными данными, потребительскими требованиями и правами на разработку?
Разделите риски на блокирующие запуск и те, которые можно безопасно закрыть перед масштабированием.
8. IT, данные и безопасность
Где живут клиентские данные? Кто имеет доступ? Что будет при отказе сервиса? Можно ли выгрузить информацию из поставщика SaaS? Есть ли резервная копия? Передаёт ли система персональные или коммерчески чувствительные сведения иностранным подрядчикам?
Для AI-сценария отдельно определите, какие данные можно отправлять модели и где человек обязан проверить результат.
9. Критерий остановки
До старта запишите, при каких фактах проект прекращается или возвращается на доработку. Например: CAC выше лимита после 100 лидов, спрос ниже заданного уровня, запуск задержан на три месяца, маржа ниже порога или потребность в капитале превысила резерв.
Правило остановки легче принять до того, как в проект вложены деньги, время и репутация собственника.
Итоговая оценка перед запуском
| Контур | Зелёный | Жёлтый | Красный |
|---|---|---|---|
| Спрос | Есть подтверждение | Гипотеза | Нет данных |
| Экономика | Работает в базе и стрессе | Зависит от одного допущения | Отрицательная |
| Cash | Есть резерв | Нужен контроль | Угроза основному бизнесу |
| Команда | Есть владелец и ресурс | Частичная перегрузка | Некому исполнять |
| Право / IT | Блокеров нет | Есть задачи до масштаба | Есть блокирующий риск |
Один красный блокер не всегда означает «проект навсегда плохой». Он означает, что инвестировать в следующий этап рано, пока конкретная проблема не закрыта.
10. Критические зависимости
Отдельно выпишите, без чего направление остановится: один поставщик, один рекламный канал, конкретный сотрудник, зарубежный SaaS, банк, API партнёра, склад или единственный крупный клиент. Для каждой зависимости оцените вероятность сбоя, время восстановления и запасной вариант.
Особенно опасны зависимости, которые в обычной работе невидимы. Например, финансовая модель продукта может быть устойчивой, но вся выдача клиенту зависит от одного внешнего API без договорного SLA и возможности быстро переключиться.
11. Кто и когда принимает решение после запуска
До старта задайте управленческий ритм: какие показатели смотрим каждую неделю, кто имеет право остановить расходы, кто меняет цену, кто согласует юридическое исключение. Если любое отклонение снова идёт к собственнику, новый проект быстро становится ещё одним источником операционной нагрузки.
Хороший pre-launch checklist заканчивается не фразой «риски проверены», а календарём решений на первые 30–90 дней после запуска.
Итог
Устойчивый запуск — это ограниченный эксперимент с понятной экономикой, владельцем, резервом и правилами остановки. Чем раньше компания видит слабое место на стыке функций, тем дешевле его исправить.
Новое направление выглядит перспективно, но нужно проверить всю картину?
Можно провести межфункциональный pre-launch аудит: экономика, управление, маркетинг, HR, IT и риски в одном контуре.
