MVP - немного мыслей по опыту

Всем привет, сегодня хочу покрутить тему создания MVP с точки зрения своего опыта - как CPO, COO, CTO и предпринимателя.

Я думаю, этот термин уже давно на слуху и на каждой конференции можно услышать что-то вроде "нет смысла пилить полноценное решение, когда можно проверить гипотезы на MVP".

Но ко мне часто приходят предприниматели с неким ТЗ, которое очень далеко по своему наполнению от смысла заложенного в понятие MVP.

Давайте пойдем по буквам. MVP - minimum viable product.

Minimum

Что значит минимальный?

  • Минимальный по стоимости?
  • Минимальный по своему функционалу?
  • Минимального качества?

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

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

  • Бизнес-модель
  • Организационная структура
  • Стратегия развития компании

А вот что происходило в техническом плане в это время.

  • Мы начали рисовать презентации, искать клиентов и т.д. в начале 2022 года.
  • В марте начались первые проекты на Google Sheets.
  • В апреле мы перешли на прототип в FlutterFlow + Firebase
  • В мае мы поменяли бэк с Firebase на XANO
  • В июне мы перешли полностью на чистый Flutter
  • В августе мы сделали рефакторинг кода
  • В сентябре мы наладили управленческие дэшборды в Google Sheets
  • В октябре мы выпустили обновление интерфейса
  • В ноябре я уволился, а новый разработчик переписал Flutter часть еще раз

Какие выводы я бы сделал из этой истории?

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

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

С другой стороны есть no-code решения и их основной минус - очень ограниченные возможности переиспользования и редактирования логики. Хороший код очень легко дорабатывается, а в ноукоде очень часто приходится переделывать что-то с нуля или дублировать, что приводит к тому, что проект не может развиваться дальше.

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

Что не так с ТЗ, которые я вижу?

Вкратце опишу неразумности, с которыми сталкиваюсь при общении с потенциальными клиентами:

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

Viable

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

В этом разделе хочется поговорить о двух аспектах

Осмысленность

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

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

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

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

Монетизация

Уже не раз встречал такой подход: "Это мы сейчас MVP сделаем, протестируем, а дальше будем делать монетизацию".

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

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

  • На реализацию монетизации потом может не хватить денег или энтузиазма
  • Платный продукт и бесплатный продукт - это вообще два разных продукта. У которых могут быть принципиально разные ЦА со всеми вытекающими.

Product

Ну и в завершение немного мыслей о том, что такое продукт.

ИТ составляющая - это только один кусочек продукта. А еще есть, как минимум, основной бизнес-процесс, люди и маркетинг. Без этих составляющих продукт остается очередным заброшенным репозиторием на GitHub.

Бизнес-процесс

Продукт - это в большинстве сфер всего лишь инструмент для доступа к некой услуге или товару. Приложение не приносит денег само по себе и не создает ценности само по себе. Попробуйте задать себе такие вопросы:

  • Какой бизнес-процесс стоит за вашим продуктом?
  • За что клиент, в конечном счете, заплатит деньги?
  • Действительно ли вы это делаете хорошо?
  • Все ли этапы доставки ценности клиенту у вас продуманы и реализованы?

Люди

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

И отсюда следует несколько важных вопросов:

  • Есть ли у вас люди, необходимые для функционирования бизнес-процесса? Соответствуют ли они требованиям этого бизнес-процесса или вы взяли тех, кто был. Нет ли конфликта между их текущей деятельностью и развитием продуктап?
  • На какой ФОТ вы выкатываете свой продукт? Если вы хотите заказать разработку за миллион рублей не имея ни одного сотрудника, не лучше ли будет просто нанять человека на 30-50к в месяц, который будет тестировать вашу гипотезу руками в чатах Telegram?

Маркетинг

Тестирование гипотез - это, по сути, столкновение продукта с трафиком. Нет трафика, нет тестирования. А самое интересное, знаете что? Что маркетинг может не получиться, а продукт - нет. Реализовать можно практически любую идею, любое приложение. А вот "свернуть воронку" на какую-то идею можно далеко не всегда.

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

Вроде выводов

Как видите, тема непростая, и, как говорится, лучше перебздеть, чем недобдеть. Я имею в виду, что лучше уделить побольше внимания проработке концепции и стратегии дальнейшего развития.

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

22
7 комментариев

Если делать продукт с одной фишкой, то её скопируют конкуренты и даже спасибо за тестирование не скажут. ,,Жизнеспособный", это когда предлагается концепция. Сколько фишек её реализуют? Сколько нужно! Это и будет минимально имеющий смысл продукт.

Ответить

На мой взгляд, фишки - это что-то очень факультативное. Для функционирования продукта совершенно не критичное. Вероятно, мы говорим о совсем разных продуктах и совсем разных нишах.

Ответить