Я полностью один построил этот продукт, в основном по вечерам, выходным и за счёт большего количества праздников, чем мне хотелось бы признавать. Долгое время он всё равно ощущался как личный проект, который просто оказался доступен в интернете.
Включение платежей мгновенно изменило это ощущение. Код не стал вдруг сложнее, но моя ответственность за продукт стала другой. Как только человек может заплатить, сломанный флоу уже не выглядит просто недоделанным edge case. Онбординг, модерация, retention, доверие и надёжность перестают быть вопросами «на будущее». Они становятся частью того, что продукт обещает прямо сейчас.
Главный вывод, который я вынес из запуска: построить насыщенный функциями соло-проект и эксплуатировать настоящий продукт — это две разные работы.
В соло-разработке узким местом стало внимание
Пока я строил продукт, я почти исчез из соцсетей. Это не было стратегией запуска. Продуктовые решения, реализация, edge cases, тестирование флоу и подготовка релиза конкурировали за одни и те же ограниченные часы.
Эту часть соло-разработки я теперь понимаю намного лучше. Ограничение не всегда в том, насколько быстро я могу писать код. Ограничение в том, сколько внимания я способен уделить растущему числу состояний, переходов и вариантов отказа внутри продукта.
Успешная сборка на эти вопросы не отвечает. Успешный платёж — тоже.
Платежи изменили для меня само значение бага
До платежей я ещё мог относить шероховатости к категории «починю позже». После их запуска эта модель для меня перестала работать. Платный продукт не обязан быть без единого бага, но цена оставленной известной проблемы становится другой, когда другой человек уже доверил продукту свои деньги.
То же самое с онбордингом и модерацией. Во время разработки их легко воспринимать как вспомогательные системы вокруг «главной» функции. В проде они становятся частью этой функции, потому что пользователь сталкивается с ними напрямую. С retention похожая история: хорошая первая сессия ещё не доказывает, что у человека есть причина вернуться.
Платежи не доказали, что продукт закончен. Они показали, сколько работы скрывалось за словом «готово».
Запуск дал мне другой тип информации
После релиза началась менее фотогеничная работа: баги, которые становятся заметны только после публикации, сломанные флоу, проблемы модерации, которые становятся реальными с приходом пользователей, и вопросы retention, которые намного сложнее, чем просто сделать хорошее первое впечатление.
Я стараюсь не переоценивать такие сигналы. Баг после релиза не означает автоматически, что архитектура плохая. Проблема с retention сама по себе не является диагнозом product-market fit. Проблема модерации не доказывает, что вся система небезопасна. Симптом показывает, где искать, но не объясняет автоматически причину.
Изменилось качество доказательств. До запуска я могу тестировать то, как, по моему ожиданию, люди будут пользоваться продуктом. После запуска приходится иметь дело с тем, как они пользуются им на самом деле. Релиз — не момент, когда неопределённость исчезает. Это момент, когда часть самой важной неопределённости наконец становится наблюдаемой.
Какой цикл после запуска я использую сейчас
Теперь мне интереснее работа после запуска, чем полировка самой истории запуска: уроки по платежам, сломанные флоу, сложности модерации, поведение пользователей, сюрпризы с retention и небольшие исправления, которые постепенно делают продукт надёжнее.
- Смотреть на реальный сценарий. Не считать, что путь, который я спроектировал, — это тот же путь, которым действительно идут пользователи.
- Отделять симптомы от причин. Сломанный шаг показывает, где что-то пошло не так, но не обязательно объясняет почему.
- Выше ставить ошибки, затрагивающие доверие. Платежи, доступ, онбординг и модерация для меня важнее косметических недочётов, потому что цена ошибки там выше.
- Сначала исправлять минимальную подтверждённую проблему. Я лучше уберу один реальный источник трения, чем перестрою систему вокруг догадки.
- После исправления снова проверять пользовательский опыт. Изменение в коде может быть технически правильным и при этом не решить проблему пользователя.
Это не универсальный фреймворк. Просто такой порядок работы кажется мне наиболее здравым после перехода от разработки к его эксплуатации.
Запуск поменял источник истины
Главное различие для меня теперь — между «продукт построен» и «я готов его эксплуатировать». Разработка отвечает на вопрос, умеет ли система делать то, что я спроектировал. Эксплуатация — что происходит, когда реальные люди ей пользуются, неправильно её понимают, уходят, возвращаются, платят или попадают в сценарий, которого я не ожидал.
Поэтому я больше не воспринимаю запуск как финиш. До запуска большая часть доказательств приходит из моих собственных предположений и тестов. После запуска продукт начинает отвечать через реальное поведение, сбои и повторное использование.