За время работы с технологическими стартапами я не раз видел, как инвесторы и предприниматели тратили по шесть–девять месяцев на разработку продукта, инвестировали десятки миллионов рублей, но не получали результата.
Причем эта ситуация характерна не только для стартапов. Я принимал участие в проекте по созданию цифровой платформы внутри крупной корпорации. При разработке выяснилось, что явной боли, которую она могла бы закрыть, нет. Правда, это стало понятно уже после того, как было потрачено пятьдесят миллионов рублей.
Проверка гипотезы
Самый лучший путь — это проверить ценность продукта на старте с помощью MVP (Minimum Viable Product — минимально жизнеспособный продукт). Многие стартапы в софтверной индустрии стараются придерживаться этого подхода.
Упрощенно это выглядит так: у вас рождается гипотеза проблемы клиента; вы хотите решить ее с помощью набора технологий в своем продукте. Сначала нужно подтвердить, что проблема действительно существует. Самый быстрый способ — это пообщаться с потенциальными клиентами и отраслевыми экспертами (глубинные интервью). Затем создаем MVP, идем к клиентам и пробуем его продать, чтобы подтвердить ценность своего решения.
В классическом подходе Customer Development есть еще промежуточный этап решенческого интервью: после выявления проблемы возвращаемся к клиенту с описанием решения и просим дать обратную связь.
Один из первых шагов при проверки гипотезы — это создание ручного прототипа, или Manual Viable Product (ручной жизнеспособный продукт), с нулевыми затратами, который уже может решать проблему клиента. На мой взгляд, сразу после этого нужно начинать продавать.
Как правило, в такой конфигурации обратная связь от пользователя становится более ценной для доработки продукта. На этом этапе может быть много «нет», но это хорошо, так как всегда можно спросить: «Почему? Чего не хватает? Как вы поняли, что мы не сможем закрыть эту потребность? Почему это дорого, с чем вы сравниваете?». Когда обратная связь получена, нужно доработать MVP и еще раз идти продавать его клиентам.
На нашей программе мы учим студентов создавать и развивать стартапы с нуля. Внутри программы студенты разбиваются на команды, каждая из которых ведет свой проект.
История первая
У команды Sinta родилась гипотеза, что пользователи Tinder тратят много времени и ресурсов на личные встречи, которые ни к чему не приводят. Они решили сделать формат speed dating онлайн — за час пользователь проводит четыре-пять коротких видеосвиданий и решает, с кем хочет встретиться.
Проблемные интервью показали, что проблема есть, но в Tinder нет подходящей фичи. Прежде чем делать приложение, мы решили сначала проверить гипотезу на знакомых: собрать в Zoom спиддейтинг-комнаты и понять, нужно это людям или нет.
Ребята провели несколько подобных форматов, получили первые деньги и поняли, что потенциал у этой идеи есть. На это ушло три-четыре недели.
История вторая
Команда Flashgift увидела проблему в сборе средств на подарки для коллег на дни рождения: собирать деньги долго и не всегда удобно (чувствуешь себя коллектором). Сегмент — люди, которые собирают деньги.
Как мы можем это проверить? Сейчас все общаются в мессенджерах. Появилась идея сделать специального бота в мессенджере — сначала в ручном режиме, чтобы подтвердить, что идея востребована, а затем уже создать чат-бота.
Мы провели порядка двадцати тестовых продаж в ручном режиме с помощью MVP (команда сама переписывалась с клиентами). В итоге подтвердили ценность решения и лучше поняли, как выстраивать чат-бота.
За полтора месяца ребята без вложений собрали 170 000 рублей на подарки со ста восьмидесяти человек, работая только с сотрудниками двух компаний. Причем 50 % — это повторные продажи.
История третья
Еще один пример — команда QUICQ. Один из основателей живет в Ярославле и знает, что сервисы доставки не привозят еду из ресторанов в удаленные районы. А жителям этого очень не хватает.
Ребята решили протестировать решение, договорились с ресторанами и впятером начали доставлять заказы. За несколько месяцев они подключили двенадцать ресторанов, выполнили более полутора тысяч доставок на общую сумму один миллион рублей, получили предложение от потенциальных инвесторов и параллельно начали разрабатывать софт.
Чему учат эти истории?
Опыт нашей работы со студентами показывает, что можно проверить любую продуктовую гипотезу. За три месяца учебы на программе мы получили следующие результаты: три команды с первыми продажами в B2C, две команды на стадии переговоров с первыми клиентами в B2B, одна команда заканчивает переговоры о продаже пакета с инвесторами, две команды с потенциалом интеграции в экосистему МТС.
Все команды разрабатывали свои идеи с нуля и использовали в работе принцип создания MVP, чтобы быстро проверить жизнеспособность своих идей.
Решая проблемы клиента, нужно найти сегмент, где проблему частично или вообще не решают. Некоторые наши команды уже несколько раз делали pivot. Самое главное — не бояться услышать нет.
Любопытство и желание узнать, почему нет, появляются только тогда, когда люди понимают важность решения, а также с первыми продажами. Это помогает не бояться запустить неидеальный продукт и идти дальше.
Кому подходит этот метод?
Manual Value Product, конечно, подходит стартапам, которые за неделю могут сделать три MVP. Скорость и гибкость — их сильная сторона. Но при работе с корпорациями больше подходит Minimum Viable Product с большим количеством тестирований, внутренних согласований и работой с фокус-группами. Бренд, большая клиентская группа и бюрократические процедуры усложняют проверку гипотез.
Кооперация между крупными компаниями и стартапами играет важную роль в развитии всех отраслей. Отрадно видеть, что в последнее время в России корпорации расширяют свою активность в этой сфере.
Как достичь максимума c помощью Manual Viable Product?
- Не увлекайтесь глубинными интервью с клиентами. Часто десяти интервью достаточно, чтобы выявить проблему и перейти к подготовке ручного MVP. Из-за длительных интервью команда может потерять мотивацию и темп. Кроме того, формирование навыка глубинных интервью требует времени. Лучше быстрее переходить к офферам, чтобы получить раннюю и более объективную обратную связь.
- Для ручного MVP используйте комбинацию сервисов и инструментов, которыми пользуются ваши клиенты. Если ваши клиенты собирают подарки через Telegram, не надо создавать прототип на базе WhatsApp. Не нужно усложнять людям жизнь — они этого не оценят.
- Используйте подход мягких продаж вашего ручного MVP. Ручной MVP нужен, чтобы лучше понять проблему клиента и ценность продукта. Важно не продать решение любой ценой, а понять клиента: задавайте больше вопросов, говорите о ситуации клиента. Слово «нет» — это возможность понять клиента лучше через вопросы, а не сигнал к убеждению через монолог.
- Определите адекватный ценник для своей целевой аудитории. Часто команды устанавливают слишком низкую цену для своего MVP, что приводит к подтверждению продаж, но не помогает выяснить ценность этого решения (люди просто пробуют что-то новое за небольшие деньги). Качественный анализ конкурентов и фактура из глубинных интервью помогут сориентироваться, сколько клиент тратит на решение этой проблемы сейчас.
Читайте статью в первоисточнике: Rusbase
