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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Монетизация

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

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

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

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

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

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

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

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

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

Люди

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

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

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

Маркетинг

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

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

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

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