Про запуск удобно думать как про прямую линию: придумали, сделали, привели пользователей. У меня так не выходило ни разу. Между «продукт готов» и «продукт нормально работает» лежит слой, которого не видно в макетах: живые люди, живые деньги и ситуации, которых не было в тестовых сценариях.

Когда я запускала воркшопы CaseSociety, сам продукт был готов: лендинг, оплата через Kaspi, записанные материалы, бот для регистрации. А потом пришёл первый живой платёж — и выяснилось, что готов был продукт, а не система вокруг него.

Продукт можно довести до готовности в одиночку. А выживет ли он после первого платежа — решает система вокруг него.

Запуск — это ещё и то, что происходит после кнопки

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

Куда попадёт информация о клиенте, кто увидит оплату, как человек получит доступ — и что будет, если деньги списались, а доступ не выдался? У меня именно этот сценарий, «оплата прошла — доступа нет», оказался самым частым в первые недели. Решала я его руками: подтверждала платёж в Kaspi и выдавала доступ через личку. Для старта это нормально. Ненормально — не знать заранее, что так будет.

Всё это — операционная сторона продукта. Её забывают спроектировать чаще всего.

Что стоит закрыть до запуска

Я держу в голове два минимальных блока.

Продукт

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

Деньги

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

Второй пользователь, про которого забывают

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

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

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

Happy path — это ещё не продукт

Самая частая ловушка — спроектировать сценарий, в котором всё идёт идеально: зарегистрировался, оплатил, доволен. Живые продукты так себя не ведут.

Письмо не дошло. Платёж прошёл дважды. Или не прошёл. Человек указал не ту почту. Потерял пароль. Доступ не выдался автоматически. Хочет вернуть деньги. Написал в поддержку ночью в воскресенье. Зрелость продукта видно именно здесь — в том, что происходит, когда что-то ломается.

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

Кто за это отвечает

Ещё один вопрос, который легко проскочить: у каждого критического процесса есть owner? Фраза «если что — разберёмся» на практике означает «заранее никто не знает, кто будет разбираться».

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

Аналитику готовят до запуска, а не после

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

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

Куда двигаться после MVP

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

  • Проверка гипотезы: существует ли проблема и готовы ли люди пользоваться решением.
  • Поиск product-market fit: достаточно ли ценности, чтобы возвращаться и рекомендовать.
  • Масштабирование: как привлекать больше людей и не утонуть в ручных процессах.

Частая ошибка — начать масштабировать то, что ещё не доказало свою ценность.

Чек-лист перед запуском

Мой минимум, по которому я бы прошлась:

  • Продукт: ЦА, проблема и ценность сформулированы; основной сценарий работает; MVP ограничен одной гипотезой.
  • Опыт: регистрация и онбординг работают; базовые сценарии протестированы; ошибки обработаны; после действий человека уходит нужная коммуникация.
  • Администрирование: есть где управлять пользователями и оплатами; понятны статусы и права доступа; предусмотрены возвраты.
  • Операции: ключевые процессы описаны, у каждого есть ответственный; понятно, что делается руками, а что автоматизируется.
  • Аналитика: ключевые метрики определены, события настроены, ясно, где смотреть данные.
  • Поддержка: есть канал связи и понятный срок ответа; заготовлены ответы на частые вопросы.
  • Стратегия и риски: сформулированы гипотеза запуска и признак успеха; есть список «что может пойти не так» и что делать по критическим пунктам.

Главная мысль

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

Поэтому до запуска я проектирую не только продукт. Я проектирую систему, которая даст этому продукту жить.

MVP не заканчивается на кнопке Launch. В этот момент он только начинает главный тест — реальными пользователями.

Как я разбираю такие запуски на конкретных кейсах — в CaseSociety. Если тема близка, оставайтесь рядом.