Ручной MVP: как быстро и дешево проверить гипотезу при запуске технологичного продукта

За время работы с технологическими стартапами я не раз видел, как инвесторы и предприниматели тратили по 6–9 месяцев на разработку продукта, инвестировали десятки миллионов рублей, но не получили результата. 

Причем эта ситуация характерна не только для стартапов. Я принимал участие в проекте по созданию цифровой платформы внутри крупной корпорации. При разработке выяснилось, что явной боли, которую она могла бы закрыть, нет. Правда, это стало понятно уже после того, как было потрачено 50 млн рублей.

Проверка гипотезы  

Самый лучший путь — это проверить ценность продукта на старте с помощью MVP (Minimum Viable Product — минимально жизнеспособный продукт). Многие стартапы в софтверной индустрии стараются придерживаться этого подхода. 

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

В классическом подходе Customer Development есть еще промежуточный этап решенческого интервью: после выявления проблемы возвращаемся к клиенту с описанием решения и просим дать обратную связь. 

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

Когда обратная связь получена, нужно доработать MVP и еще раз идти продавать его клиентам.

Как мы проверяем гипотезы 

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

История первая

У команды Sinta родилась гипотеза, что пользователи Tinder тратят много времени и ресурсов на личные встречи, которые ни к чему не приводят. Они решили сделать формат онлайн speed dating (за час пользователь проводит 4–5 коротких видеосвиданий и решает, с кем хочет встретиться). 

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

Ребята провели несколько подобных форматов, получили первые деньги и поняли, что потенциал у этой идеи есть. На это ушло 3–4 недели.

История вторая

Команда Flashgift увидела проблему в сборе средств на подарки для коллег на дни рождения: собирать деньги долго и не всегда удобно (чувствуешь себя коллектором). Сегмент — люди, которые собирают деньги. 

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

Мы провели порядка 20 тестовых продаж в ручном режиме с помощью MVP (команда сама переписывалась с клиентами). В итоге подтвердили ценность решения и лучше поняли, как выстраивать чат-бота. 

За полтора месяца ребята без вложений собрали 170 тыс. рублей на подарки со 180 человек, работая только с сотрудниками двух компаний. Причем 50% — это повторные продажи.

История третья

Еще один пример — команда QUICQ. Один из основателей живет в Ярославле и знает, что сервисы доставки не привозят еду из ресторанов в удаленные районы. А жителям этого очень не хватает. 

Ребята решили протестировать решение, договорились с ресторанами и впятером начали доставлять заказы. За несколько месяцев они подключили 12 ресторанов, выполнили более 1,5 тыс. доставок на общую сумму 1 млн рублей, получили предложение от потенциальных инвесторов и параллельно начали разрабатывать софт. 

Чему учат эти истории? 

Опыт нашей работы со студентами показывает, что можно проверить любую продуктовую гипотезу. За три месяца учебы на программе мы получили следующие результаты: три команды с первыми продажами в B2C, две команды на стадии переговоров с первыми клиентами в B2B, одна команда заканчивает переговоры о продаже пакета с инвесторами, две команды с потенциалом интеграции в экосистему МТС. 

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

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

Кому подходит этот метод? 

Manual Value Product, конечно, подходит стартапам, которые за неделю могут сделать три MVP. Скорость и гибкость — их сильная сторона. Но при работе с корпорациями больше подходит Minimum Viable Product с большим количеством тестирований, внутренних согласований и работой с фокус-группами. Бренд, большая клиентская группа и бюрократические процедуры усложняют проверку гипотез. 

Кооперация между крупными компаниями и стартапами играет важную роль в развитии всех отраслей. Отрадно видеть, что в последнее время в России корпорации расширяют свою активность в этой сфере.

Как достичь максимума c помощью Manual Viable Product

• Не увлекайтесь глубинными интервью с клиентами. Часто десяти интервью достаточно, чтобы выявить проблему и перейти к подготовке ручного MVP. Из-за длительных интервью команда может потерять мотивацию и темп. Кроме того, формирование навыка глубинных интервью требует  времени. Лучше быстрее переходить к офферам, чтобы получить раннюю и более объективную обратную связь.
• Для ручного MVP используйте комбинацию сервисов и инструментов, которыми  пользуются ваши клиенты. Если ваши клиенты собирают подарки через Telegram, не надо создавать прототип на базе WhatsApp. Не нужно усложнять людям жизнь — они этого не оценят.
• Используйте подход мягких продаж вашего ручного MVP. Ручной MVP нужен, чтобы лучше понять проблему клиента и ценность продукта. Важно не продать решение любой ценой, а понять клиента: задавайте больше вопросов, говорите о ситуации клиента. Слово «нет» — это возможность понять клиента лучше через вопросы, а не сигнал к убеждению через монолог.
• Определите адекватный ценник для своей целевой аудитории. Часто команды устанавливают слишком низкую цену для своего MVP, что приводит к подтверждению продаж, но не помогает выяснить ценность этого решения (люди просто пробуют что-то новое за небольшие деньги). Качественный анализ конкурентов и фактура из глубинных интервью помогут сориентироваться, сколько клиент тратит на решение этой проблемы сейчас.

Фото на обложке и в тексте: Unsplash