Что я считаю настоящим запуском продукта

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

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

Релиз — это готовность системы. Запуск — готовность человека

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

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

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

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

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

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

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

Это не призыв выпускать недоделку. У такого контура есть строгие границы:

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

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

Пять признаков, что запуск действительно начался

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

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

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

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

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

Что стоит подготовить до первого живого дня

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

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

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

Когда запуск лучше отложить

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

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

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

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

Первый запуск — это ещё и договорённость с командой

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

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

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

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

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

После запуска не нужно защищать каждую функцию

Самый дорогой режим — когда команда воспринимает каждое замечание как нападение на уже сделанную работу. Тогда объяснения становятся важнее наблюдений: «пользователь не понял», «надо обучить», «всё работает по требованиям». Иногда это правда. Но сначала полезно проверить, не пытается ли человек сделать разумное действие разумным способом.

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

Это особенно заметно в B2B-системах. Решение покупает один человек, а ежедневную работу делает другой. Поэтому «нам понравилось на встрече» и «мы используем это в понедельник утром» — два разных сигнала. Первый помогает начать. Второй даёт право говорить о запуске.

Короткая проверка перед словом «запустили»

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

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

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