MVP, минимальный продукт — это та версия, которую неловко показывать: один экран, половина сценариев вручную, вместо админки таблица. Инструкция ниже о том, как довести такую версию до состояния, когда за неё платят незнакомые люди, и в каком порядке делать шаги, чтобы не потратить год на красивую архитектуру без пользователей.
Основа — статья Григория Мельникова, создателя сервиса защиты от ботов KillBot, «Как построить сервис с нуля самому. ПО ШАГАМ». Текст у него злой и местами грубый, но под эмоциями лежит понятный порядок действий, который я пересобрал в пошаговый вид и местами дополнил тем, как это выглядит на нашей стороне: контент-завод, на котором работает этот сайт, собирается по той же логике — сначала кривая работающая версия, потом всё остальное.
Сразу оговорка про цифры. Ни выручки, ни конверсий, ни сроков в исходном материале нет, и придумывать их я не буду. Всё, что ниже, — последовательность решений и способ проверить каждое из них на своих данных.
Что понадобится
До первого шага нужно иметь на руках:
- Задачу конкретного человека. Не «рынок нуждается в», а «вот этот человек тратит на это три часа в неделю». Если такого человека вы назвать не можете, у вас пока нет продукта.
- Канал связи с будущими пользователями. Чат, канал, форум, профильное сообщество, личные знакомства. Что угодно, где можно написать и получить ответ.
- Готовность рассказывать, как всё устроено. Мельников формулирует жёстко: бояться, что идею скопируют, нельзя. Рынок платит не за то, что в голове, а за то, что собрано и работает.
- Сам продукт в ежедневном использовании. Не в демо-режиме, а в своей рабочей рутине.
- Оценку своей себестоимости. Сервер, модели, подписки, часы. Это понадобится на шаге про цену — не для того, чтобы назначить цену по затратам, а чтобы понимать, с какого момента вы работаете в минус.
Чего не понадобится на старте: выбранного «правильного» фреймворка, схемы базы данных на будущие миллионы записей и красивого кода. К этому вернёмся на шаге проверки.
Шаг 1. Собрать MVP: минимальный продукт, который уже решает задачу
Выпишите один сценарий — от момента, когда у пользователя возникла проблема, до момента, когда она решена. Один. Всё остальное пока вычеркните.
Дальше соберите этот сценарий любым способом, который работает. Часть шагов может делать человек руками, часть — скрипт, интерфейсом может быть бот или форма. Критерий готовности один: чужой человек проходит путь до результата и результат его устраивает.
Мельников приводит в пример Цоя с сырой гитарой: аудитория нашлась до всякого продакшена. Там же — отсылка к «Бизнесу с нуля» Эрика Риса, где это называется MVP: не идеальный продукт, а минимальная рабочая версия для проверки гипотезы.
Чем чревата ошибка: вы делаете вторую и третью функцию до того, как кто-то воспользовался первой. Признак, что вы в этой ловушке, — в списке задач больше пунктов «доделать», чем пунктов «показать кому-то».
У нас первая версия конвейера выглядела так: ссылка на материал приходила вручную, текст генерировался одним запросом, публикация шла кнопкой из Telegram. Половина того, что сейчас делает система, тогда делалась руками. Зато было видно, какие посты вообще получаются, а какие приходится переписывать целиком.
Шаг 2. Рассказать устройство вслух и найти первых пользователей
Опишите, как ваш сервис работает, и покажите это там, где сидят люди с той самой задачей. Не «мы запустили платформу», а «вот задача, вот как я её решаю, вот что получается на выходе».
Как понять, что получилось: вам отвечают вопросами по существу — «а если у меня данные в другом формате», «а сколько это стоит». Молчание или вежливые лайки означают, что задача не попала.
Чем чревата ошибка: месяцы в режиме секретности. Аргумент из материала — идей в избытке, и сами по себе они не стоят почти ничего; ценность появляется в реализации, об этом Фрайд и Хайнемайер Хенссон писали в «Rework». Плюс технологический: то, что кажется прорывом сегодня, через три года может никому не понадобиться.
Что сюда не отдавать: чужие данные, которые у вас уже лежат. Рассказывать можно про устройство и про свои цифры — не про клиентов, их тексты и их метрики.
Шаг 3. Назначить цену от готовности платить, а не от своих трудозатрат
Соберите вопрос к первым пользователям в такой форме: сколько они сейчас тратят на эту задачу денег и времени и сколько готовы отдавать ежемесячно, чтобы не тратить. Ответы записывайте дословно.
Дальше назначьте цену внутри диапазона, который вы услышали, и сверьте её со своей себестоимостью из блока «Что понадобится». Если готовность платить ниже себестоимости — дело не в цене, а в сценарии: вы автоматизируете задачу, которая человеку обходится дешевле вручную.
Мельников честно пишет, что на первых порах сам называл неадекватные цены, и объясняет механику ошибки: кажется, что раз перед тобой предприниматель или директор, деньги у него есть и он заплатит за всё подряд. На деле клиент — такой же человек, который хочет экономить и у которого портится настроение, когда он платит много. Вложенный труд на цену не влияет. Эта логика разобрана в «Монетизации инноваций» Рамануджама и Таке: сначала выясняем, что нужно клиенту и сколько он за это готов платить, и только потом строим продукт вокруг этой цены.
Чем чревата ошибка: цену вниз двигать легко, вверх — почти невозможно, а завышенный ценник на старте просто обнуляет поток заявок, и вы не понимаете почему.
Шаг 4. Закрывать реальные ограничения, а не выдуманные угрозы
Составьте два списка. В первый — проблемы, которые у вас случились: падения, жалобы, отвалившиеся пользователи, места, где процесс встаёт. Во второй — то, что «может случиться». Работайте только по первому, пока он не пуст.
Если берёте пункт из второго списка, требуйте от себя конкретики: кто именно создаёт такой сценарий, каким софтом, какой масштаб ожидается. Без этих трёх ответов пункт остаётся фантазией. У Мельникова для этого есть образ с танком: если на тебя идёт броня в 50 мм, нужно ружьё, которое её пробивает, а не лазер, который расплавит танк целиком, — войну проиграешь раньше, чем закончишь чертежи.
Как понять, что получилось: вы можете назвать одно узкое место системы прямо сейчас и показать, что именно делаете с ним на этой неделе. Это мысль Голдратта из «Цели» — не улучшать всё подряд, а найти ограничение и направить ресурсы туда.
Шаг 5. Пользоваться своим продуктом каждый день
Переведите на свой сервис хотя бы один собственный рабочий процесс целиком и запретите себе обходные пути. Не «зашёл проверить, что живо», а работаете через него.
Как понять, что получилось: вы заводите баги сами, до того как о них напишут пользователи. Если все задачи приходят извне, вы смотрите на продукт глазами разработчика, а это та позиция, из которой жалобы звучат как «это только у вас» и «да не тупит там ничего».
Разница в двух фразах из материала. Разработчик: алгоритм отработал, лог чистый, всё работает. Пользователь: какого чёрта всё тупит. Если руководитель не пользуется своим продуктом в повседневной жизни, он остаётся на стороне первой фразы.
У нас этот шаг сработал на превью: пока посты смотрели выборочно, казалось, что генерация в порядке. Когда каждый текст стал проходить через одну и ту же кнопку перед публикацией, выяснилось, сколько в них одинаковых зачинов.
Шаг 6. Строить причину хотеть ваш продукт
Выпишите, почему человек выберет вас, а не соседний сервис с тем же набором функций. Если в списке только «дешевле», «быстрее» и «удобнее» — это список, который может написать про себя любой конкурент, и ценности в нём ноль.
Мельников доводит мысль до предела на примере Lamborghini Aventador: дёрганая коробка, нулевая обзорность назад, жёсткая подвеска — и именно это покупают. Эмоциональная связь с продуктом, по его словам, перекрывает недостатки, а технически лучший продукт проигрывает тому, который просто хотят. Теоретическая опора — «Эмоциональный брэндинг» Марка Гобэ: сильный бренд строится на связи между брендом и человеком, а не на перечне характеристик.
Практическая часть шага: решите, чьими руками это делается. Нанятый маркетолог не заменит вашего понимания, какие задачи он решает и какие цифры должны получиться на выходе, — об этом в материале отдельный злой раздел с выводом, что ответственность за результат исполнителя лежит на том, кто его выбрал и поставил задачу. Та же логика у Бена Хоровица в «Сложных решениях»: человека, который придёт и магически решит проблемы компании, ждать не нужно.
И фильтр на советы. Вес мнения зависит от того, решал ли человек вашу задачу: построил ли систему, которой регулярно платят незнакомые люди. Совет коллеги за соседним столом выслушать можно, инструкцией он становиться не должен. Далио в «Принципах» называет это тем же — не все мнения весят одинаково.
Как проверить результат
Считайте не ощущения, а четыре вещи, и сравнивайте их с собой же месяц назад:
- Повторное использование. Сколько человек из тех, кто попробовал, вернулись на второй и третий раз. Это главный сигнал: разовый заход ничего не доказывает.
- Платящие. Сколько людей, не знакомых с вами лично, заплатили по цене из шага 3. Друзья и бывшие коллеги в эту выборку не входят.
- Источник задач в бэклоге. Доля пунктов, пришедших от реальных сбоев и пользователей, против доли придуманных вами. Если вторая растёт, вы вернулись на шаг 4.
- Себестоимость одного пользователя. Сервер, модели, подписки, ваши часы. Нужна, чтобы увидеть момент, когда рост пользователей начинает увеличивать убыток.
Про оптимизацию. Кнут ещё в 1974 году сформулировал, что преждевременная оптимизация — корень большинства зол, и смысл не в отказе от неё, а в очерёдности: сначала понять, что критично, потом тратить ресурсы. Критерий для себя я держу такой: переписывать код и архитектуру имеет смысл, когда конкретная метрика из списка выше упирается в техническое ограничение, а не когда решение перестало нравиться.
Что делать, если не работает
Пользователи приходят и не возвращаются. Сценарий из шага 1 решает не ту задачу или решает её хуже, чем привычный ручной способ. Спросите у вернувшихся, что они делали вместо вас.
Никто не платит, хотя пользуются. Проверьте цену по шагу 3 и момент, в который вы её называете. Часто дело не в сумме, а в том, что ценность ещё не наступила, когда уже просят деньги.
Все силы уходят на поддержку. Это сигнал, что ручных кусков в MVP стало больше, чем вы можете нести. Автоматизируйте тот шаг, который чаще всего ломается, а не самый интересный.
Нанятый подрядчик не дал результата. Вернитесь к постановке задачи: какие именно цифры вы просили и почему решили, что эти действия приведут к результату. Если ответа нет, замена подрядчика ничего не изменит.
Пользователи есть, а желания платить нет ни у кого. Самый тяжёлый случай: вы закрыли задачу, которую люди согласны терпеть. Тут честнее менять сценарий, а не маркетинг.
Что с этим делать
- Выберите один сценарий и соберите MVP — минимальный продукт, который проходится чужим человеком до результата. Остальное из списка функций отложите.
- Расскажите устройство публично там, где сидят люди с этой задачей, и соберите вопросы по существу.
- Цену назначьте внутри диапазона, который назвали будущие пользователи, и сверьте её со своей себестоимостью.
- Заведите два списка проблем — случившихся и воображаемых — и работайте по первому.
- Переведите свою рабочую рутину на собственный сервис и держите её там.
- Раз в месяц считайте возвраты, платящих, источник задач и себестоимость пользователя. Эти четыре числа честнее любых ощущений по поводу продукта.