Это провал: как сделать MVP, который никому не нужен

Что бывает, когда не прислушиваешься к пользователям. Разбираем на примере франшизы пекарен и слишком «умной» каски.

Мы уже рассказывали о том, как проводить Customer Development и к каким изменениям приводит исследование пользователей. Сегодня мы вместе с Михаилом Войтко, руководителем партнёрской программы «Яндекс.Облака» и куратором курса Customer Development & MVP в Binary District, на примере двух кейсов покажем, что происходит, если не проводить CustDev, и поделимся советами, как не провалить MVP.

Небольшая региональная компания открывала в своём городе пекарни. Через три года компания решила развивать свою франшизу, и встал вопрос о создании специализированной системы управления, с помощью которой франчайзи могли бы автоматизировать производство, а франчайзер — контролировать филиалы.

Основной и единственный эксперт в команде, работавший над созданием ИТ-системы, а также владелец продукта — ИТ-директор старого бизнеса, опытный в бухгалтерском и складском учёте.

На этапе проектирования пообщались с одним внешним пользователем. При разработке MVP учитывалась экспертиза двух человек, если брать в расчёт самого ИТ-директора. В состав MVP вошла автоматизация ежедневного цикла работы пекарни: планирование производства, управление цепочкой продуктов в течение одной смены, закрытие и планирование следующей смены.

Продвигалась сама франшиза, а ИТ-система была приятным дополнением к ней.

Первая обратная связь по MVP от внешних пользователей показала неадаптивность возможностей и интерфейсов к специфике других точек в соседних городах.

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

Отсутствие качественной информации от владельцев франшиз или потенциальных покупателей — серьёзный минус. Нужно было пообщаться с клиентами, взять глубинные интервью — для первого MVP пяти-шести бесед было бы достаточно.

Если пройтись по модулям, которые вошли в состав MVP, можно заметить, что полностью отсутствует часть, касающаяся денег. Хотя это важный (может быть, основной) элемент в системе для потенциальных покупателей франшизы.

В первую очередь нужно было походить по уже действующим франшизам, не обязательно по пекарням, чтобы выяснить, насколько важно наличие ИТ-системы во франшизе. Только после десятка попыток продать франшизу стало понятно, что ИТ-система — не приятный бонус, а необходимое условие.

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

• какие особенности ИТ-системы нужно предусмотреть для разных городов и регионов;
• какие модули должны быть в первом MVP;
• как архитектура системы влияет на адаптивность и дальнейшее масштабирование;
• какими должны быть способы технической реализации ИТ-системы.

Американский стартап разработал устройство, встраиваемое в обычную рабочую каску. Устройство состоит из RFID, Wi-Fi-контроллера и нескольких датчиков: влажности, температуры, акселерометр и так далее. Получается так называемая «умная» каска.

Команда в основном состояла из технических специалистов в области сетей и интернета вещей. Эксперт в области безопасности на производстве отсутствовал в принципе.

На этапе создания прототипа исследований пользователей не проводилось. Разработчики выдвинули несколько гипотез относительно того, для чего и когда могла бы быть полезна «умная» каска. В MVP1 «умной» каски вошёл широкий спектр возможностей: от контроля перемещений инженеров до отправки сообщения в случае падения работника.

Компания разработала довольно серьёзное с точки зрения технологий устройство, а поиск сфер применения этого устройства — забота самого клиента. Но клиенты почему-то не торопились этим заниматься.

Только спустя несколько этапов общения с потенциальными покупателями стартап выяснил, что большинство предложенных функций им просто не нужно. Для MVP2 была выбрана другая, необходимая клиентам функциональность.

Потенциальные клиенты в некоторых продуктах могут быть «сложными» — например, если речь идёт об узкой нише или корпоративном сегменте, где решение о покупке продукта принимает топ-менеджмент или директор.

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

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

Стоило погрузиться с головой в тематические форумы: строительные, инженерные и прочие.

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

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

• С технологической точки зрения продукт может быть построен идеально, но если он не соответствует запросам рынка (нет так называемого Product/Market Fit), то его никто не купит. Сначала нащупайте потребность рынка, затем выстраивайте технологическое решение проблемы.
• Обязательно проводите глубинные интервью со своими клиентами, даже если не знаете точно, что спрашивать. Спустя первые два-три интервью вы сможете правильно составить гайд вопросов. Проводите интервью до тех пор, пока респонденты не начнут повторяться.
  
• По возможности не стройте сразу космический корабль. Ваш продукт должен при минимальной функциональности решать проблему клиентов и приносить деньги, чтобы как можно раньше возвращать инвестиции для расширения возможностей продукта.
  
• Помните: даже если вы в одиночку создаёте стартап в свободное от работы время, цена ошибки от этого не снижается. Если вы потратили 1000 часов своего личного времени (допустим, оно стоит 1000 рублей в час) на создание сервиса и он провалился, то цена ошибки составит миллион рублей.