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