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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Монетизация

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

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

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

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

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

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

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

Люди

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

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

Маркетинг

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

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

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

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