18 способов провалить свой MVP: чек-лист того, как не надо делать

Аббревиатура MVP (minimum viable product) известна многим. Но при этом команды при разработке часто допускают одни и те же ошибки. Этот чек-лист поможет оценить, а не делаете ли вы что-то не так.

Представьте, что вы хотите нанести удар кулаком. Чтобы удар получился сильным и точным, вам нужно рассчитать замах, траекторию, резкость. Этот кулак и есть ваш MVP, которым вы собираетесь ударить в рынок, чтобы достучаться до сердца пользователя и захватить долю на рынке. Но этот воображаемый кулак состоит из множества компонентов — правильные гипотезы, точная статистика, разработка, привлечение клиентов и так далее. Если все компоненты сработали так, как надо, то удар получится качественным. А если вы закопались с разработкой, не придумали, как привлекать пользователей, то даже вполне рабочая идея может обернуться неудачей. Какие ошибки чаще всего случаются при запуске MVP?

Антон Новоженин

Эксперт по разработке ИТ-продуктов

Забронировать звонок с экспертом

1. Перепутать цель MVP.Многие уверены, что задача MVP — помочь компании как можно скорее выйти на рынок. Но это не совсем так. Главная задача заключается в проверке гипотез о том, нужен ли ваш продукт клиентам или нет (гипотеза ценности) и готовы ли они за него платить и сколько (гипотеза монетизации). Вот для этого и нужен MVP. Если продукт оказался не востребован у аудитории, то надо менять позиционирование, дорабатывать идею. И как бы быстро вы на рынок не вышли, при отсутствии интереса у клиентов вам это никак не поможет.

2. Не провести custdev.У вас есть гениальная идея, которая перевернет мир? Отлично! А вы уверены, что проблема, которую вы хотите решить, волнует не только вас. Такое часто случается при запуске продуктов: основатели думают, что их продукт нужен абсолютно всем, но по факту оказывается, что проблема надумана. Вот тут и нужен CustDev (Customer Development). Эта методика помогает найти инсайты от пользователей: общаясь с ними, вы узнаете их боли и пытаетесь закрыть их своим продуктом. Вот только спрашивать в лоб «А пользовались бы вы вот таким продуктом?» вряд ли поможет. Есть много статей про то, как проводить CustDev, или, например, можнопочитать книгу «Спроси маму».

3. Пытаться запихнуть в MVP много функционала.Представьте, что у вашего продукта в идеале должно быть 100 функций. Можно, конечно, сделать их все, но для MVP это избыточно. Нужно выбрать минимальный набор функций, который позволит закрыть потребность клиента и при этом проверить гипотезу. Как выбрать? Отранжировать функции по приоритету и выбрать самые важные. Для этого у команды, а особенно у product owner, должно быть видение продукта и понимание, какие функции востребованы в первую очередь. При этом если сделать недостаточно функциональный продукт в качестве MVP, то пользователи могут не оценить его. Если вам удалось выбрать нужный набор функций и попасть в боль клиента, то этот минимальный продукт начнет приносит хоть какие-то деньги и окупать дальнейшую разработку.

4. Стараться довести продукт до идеала.При таком подходе разработка продукта может затянуться на месяцы, а то и годы. А при выходе на рынок окажется, что он никому не нужен. Улучшать и доводить продукт до идеала можно бесконечно. Но ваша задача — как можно быстрее проверить гипотезы и начать работать дальше. И нет ничего страшного в том, чтобы какие-то решения держались на «костылях». Например, есть проекту нужен свой сайт, то изначально это может быть просто лендинг на Tilda, который потом можно переработать.

5. Пытаться охватить сразу все платформы (веб/iOS/Android).Конечно, хорошо, если ваш продукт есть на всех платформах. Но для MVP это совсем необязательно. Проверить гипотезы можно только для iOS-пользователей, а в случае успеха потом сделать приложение и для Android. С момента первого MVP до полнофункционального продукта вы пройдете не одну итерацию, а концентрация на одной площадке поможет сохранить бюджет и время. Конечно, надо продумывать, как потом расширять продукт на новые платформы, но MVP можно протестировать и на одной. Еще можно рассмотреть кросс-платформу (React Native, Flutter). Для некоторых задач этого будет достаточно, и при этом сильно срежет стоимость на первых этапах. А дальше приложение можно будет переписать. Если в команде есть только android-разработчик, проще, конечно, начать с Android.

6. Не определить цели и ключевые метрики продукта.У вас есть гипотеза и вы сделали MVP, чтобы ее проверить. А как понять, что гипотеза подтвердилась? Должны быть какие-то критерии успеха. Заранее установленные метрики, которые позволяют говорить о подтверждении гипотезы — определенное количество скачиваний, оплат, просмотров или чего-то еще. Как правило, проверять можно несколько гипотез одновременно — например, опробовать продукт на разных аудиториях. Какая гипотеза проявит себя лучше, туда и нужно вкладывать дополнительные силы и средства. Но должны быть критерии, по которым можно определить успех той или иной гипотезы. И это не бинарный формат — успех или нет. Тут правильнее говорить о качественных показателях — одна гипотеза может оказаться успешнее других.

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

8. Применять Waterfall вместо Scrum/Lean Startup.Это две методологии разработки проекта. Waterfall подразумевает составление четкого и подробного плана (ТЗ) и потом следование ему. Но в случае с MVP такой подход не работает. И больше подойдет гибкая методология, вроде Scrum или Lean Startup. MVP подразумевает быструю проверку гипотез и, соответственно, быстрое изменение курса по итогам проверки гипотез. На такие изменения способна только гибкая команда. А если вы заранее пропишите план, то просто потеряете время, если проверка первой же гипотезы опровергнет все ваши предположения о продукте.

9. Гнаться за уникальностью.Да, все хотят сделать уникальный продукт, который откроет новый рынок. К сожалению, так удается далеко не всегда. Гнаться нужно не за уникальностью, а за решением конкретной проблемы пользователя. Если у него есть проблема, то существующие продукты (даже если они есть) не закрывают ее или делают это недостаточно хорошо. И это ваш шанс заполучить клиентов. Есть теория об алых и голубых океанах. Алый океан — уже поделенный рынок, голубой — еще несуществующий, но потенциально большой рынок. Мало кто сходу может открыть голубой океан. Чаще всего требуется досконально изучить алый океан, понять, какие боли клиентов еще не закрыты, а потом уже идти в эту сторону. И, возможно, закрыв одну боль клиента, вы получите дополнительный инсайт, который позволит найти свой голубой океан.

10. Не проводить конкурентный анализ.Отчасти это продолжение предыдущего пункта. Многие уверены, что их продукт абсолютно уникальный. Но это не так. У всех есть конкурента, даже если и не прямые. Конкурентный анализ — обязательный пункт при подготовке любого MVP. Вам нужно понимать, что предлагают конкуренты и как от них отстраиваться.

11. Забивать на качество продукта во имя скорости разработки.Это обратная сторона идеальности. Конечно, MVP нужно делать быстро и с минимумом функций, закрывающих проблему, но надо сохранять качество. Если вы сделаете приложение, а оно будет вылетать при запуске, то клиент просто не сможет оценить ваш продукт. Быстро, с минимально достаточным набором функций и качественно.

12. Не уделять внимание UX.Это опять вопрос «качество vs скорость». Нужно быть быстрым, но при этом сохранять качество. У пользователей есть определенные ожидания. И как бы круто ваш продукт не закрывал боль клиента, но если UX в. нем сделан на уровне Windows 98, то пользоваться таким продуктом будут не очень охотно.

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

14. Делать ставку на очень широкую аудиторию.Нельзя сделать продукт для всех. Как минимум, ваш MVP разрастется настолько, что вы потратите на него кучу времени и денег. Нужно фокусироваться, работать на определенную аудиторию. Чем лучше вы определяете свою нишу, тем лучше можно проработать идею и продукт. Конечно, никто не мешает вам потом расширять свою аудиторию или тестировать MVP сразу в нескольких нишах. Но на первом этапе должна сфокусированность. Это помогает и выбором приоритетных функций, и при таргетировании продукта на пользователей.

15. Не иметь плана по привлечению пользователей после запуска.Вы сделали MVP — например, приложение. Загрузили в магазин приложений. Что дальше? Если вы ждете, что аудитория оценит ваш уникальный продукт, и пользователи ринутся его скачивать, то мы вас растроим — не ринутся. У вас должен быть четкий план того, как привлекать аудиторию. И бюджет на это. Реклама в соцсетях, работа с инфлюенсерами, работа с B2B-клиентами (если ваш продукт в этой нише) — это требует времени и средств. И лучше, если такой план у вас будет заранее, чтобы не терять время.

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

17. Пробовать новое в разработке.Когда разработки не избежать, то работайте с хорошо знакомыми инструментами. Иногда бывает соблазн попробовать что-то новенькое. «Давайте задействуем новый язык или фреймворк, раз мы делаем новый продукт». Но при таком подходе вашей экспертизы может не хватить. И в конечном счете, эта разработка затягивается, растет бюджет, что особенно губительно для MVP. Используйте те инструменты, с которыми хорошо знакомы. Первая версия Twitter была сделана на Ruby, а Instagram — на Python. Это, может быть, не самые подходящие инструменты для таких продуктов, но для первой версии подойдут. Ваша задача сделать работающий прототип максимально быстро и качественно.

18. Впасть в оверинжиниринг.У некоторых разработчиков есть такая напасть — делать слишком основательно. Это хорошая черта, но не для MVP. Вам нужно сделать быстро, а ваши разработчики строят целый плацдарм для завоевания мира. Конечно, нужно держать в голове план масштабирования, но сразу тратить громадные силы и средства на подготовку к цунами из пользователей вряд ли стоит. Зачем раздумывать о том, как вы будете подключать ферму из 100 серверов на Amazon, если у вас еще нет пользователей? Избежать такого сценария поможет четкая координация в команде. У вас должен быть product owner с продуктовым видением, который думает о стратегии, а еще product manager, который следит за тем, чтобы разработчики с одной стороны не строили космический корабль, а с другой — не допускали обидных ляпов и недоработок. Часто крупные компании нанимают аутсорс-разработчиков для создания MVP. И первая цель — не сэкономить деньги. У многих крупных компаний уже есть сформировавшее мышление, глобальный подход. И таким командам сложно перестроиться на быструю и гибкую работу.

А еще мы собрали все эти пункты в небольшом плакате — своеобразном чек-листе, который вы можете распечатать и повесить у себя на рабочем месте.