Почему в новом сервисе никогда нет всех нужных функций сразу

И что такое «MVP как процесс».

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

Я не использовал все модные термины индустрии в тексте, так что надеюсь, будет понятно. А ещё я делюсь этим просто так, чтобы те, кто не связан с разработкой классического софта, примерно понимали как это устроено — у меня нет любимого лаунчера или лаунчера, который я бы не любил, как нет и ПК в принципе *плачет*.

А ещё MVP, наверное, не применим к разработке игр — в этом направлении у меня нет опыта.

В разработке любого софта существует такое понятие как «Minimum Viable Product» или по-русски «Минимально Ценный Продукт». Это условно то, ради чего вы делаете продукт — одна или несколько самых важных вещей, ради которой вы готовы запустить проект, вещь, которая нужна не только вам, но и рынку, на который вы выходите.

Представьте, что вы запускаете Uber в 2009 году (на тот момент ещё UberCab) — у вас ограниченный бюджет, нет аналитики для принятия решений, вы не уверены, выстрелит ли ваша гипотеза, и вам очень хотелось бы проверить идею до того, как вы вложите все ваши деньги в неё — вы очень рискуете, вы ведь не знаете, что будет в результате.

Какую минимально ценную версию продукта вы бы закладывали с точки зрения разработки?

Подумайте немного, ниже будет ответ.

Что сделал Uber при запуске бета-версии:

Это всё. Заявки водителям передавались руками: об этом свидетельствует утверждение CEO, что как только они добавили ещё пару машин в пул, сразу стало сложнее распределять заказы на машины.

Как только они встретили эту сложность, CEO Uber позвонил 10 водителям в Сан-Франциско и предложил им самим получать заявки в приложении. Трое водителей согласились, а Uber сформулировал свою бизнес модель, которую теперь использует весь мир такси.

Какие выводы можно сделать из MVP Uber? До того, как начать вкладывать деньги в маркетинг и разработку, ребята протестировали идею, поняли, что быть такси-диспетчерской очень сложно, смогли перенести все эти функции на плечи водителей и сервера.

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

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

Шёл 2007 год, и облачные хранения файлов как таковые были ещё не такими популярными, кроме как у linux-гиков, знающих про rsync.

Ребята из Dropbox проверили MVP совсем не так, как привык рынок — они сделали небольшую страницу с анонсом продукта и мемное видео, которое закинули на Digg (это проект, который появился до Reddit, но никогда не слушал свое сообщество и умер) — за ночь они получили около 80 тысяч заявок от желающих принять участие в проекте.

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

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

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

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

Сразу начну с примера, чтобы было понятнее, что такое «MVP как процесс». Взял я его из прекрасной статьи YCombinator.

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

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

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

«Это будет круто!» — говорит ваш внутренний стартапер.

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

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

Что в целом не важно, так как, скорее всего, ваш продукт потерпит неудачу.

Почему?

Вы за раз выдвигаете много гипотез, которые могут оказаться неверными, например:

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

Но ситуацию с проектом выше можно поправить ещё на ранних этапах, применив подход «MVP как процесс».

Разумно развивать продукт, на каждом этапе спрашивая себя:

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

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

Можно спросить их, есть ли у них мобильное приложение сейчас? Если нет, то почему? Они вообще хотят приложение? Насколько они технически готовы к приложениям? Они понимают преимущества ресторанных приложений?

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

Дёшево, а результат вы получаете такой же, как после нескольких месяцев разработки.

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

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

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

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

Им нравится? Они впечатлены, что веб-сайт готов так быстро? Сколько они заплатят за запуск такого сайта сегодня?

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

Или, может быть, вы узнаете, что рестораны готовы платить. Таким образом, вы принимаете оплату за несколько месяцев обслуживания самым простым способом, запускаете сайты и просите ресторан написать вам по электронной почте, если им нужно обновить что-то на сайте.

Да, это будет ручная работа с вашей стороны. Да, это не будет масштабироваться, если число клиентов будет расти.

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

Ну а пока, вам нужно повторить процесс MVP ещё раз.

На данном этапе ваша стратегия маркетинга работает, есть какие-то деньги, но вы же не можете обойти все рестораны мира и предлагать им сделать сайт?

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

Затем вы можете купить рекламы на несколько сотен долларов в социальных сетях и посмотреть, что будет дальше.

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

Это, в двух словах, MVP как процесс.

Разрабатываете ли вы дизайн продукта, маркетинговый план или пишете код, всегда спрашивайте себя:

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

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

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

Настоящее удаление профилей (не бан) и смена ника не через разработчиков (вы можете писать на [email protected], и мы сменим), появились через два года существования DTF, потому что мы постоянно фокусировались на более критичных для платформы вещах.

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

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

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

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

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

Можно ли без MVP? Конечно можно – Notion, Figma, примеры проектов где у компаний было и время, и деньги, чтобы запуститься с полноценным функционалом. Но если бы что-то пошло не так и они не стали популярны как продукт, риски были бы намного выше.

Кстати, интересный факт: в этой статье словосочетание MVP написано 20 раз.

Если вам интересно, можете попробовать угадать MVP-версию современного DTF в комментариях, первому победителю — ачивка-сердечко возле ника 💖. UPD. Конкурс закончился, победитель получил ачивку.

#мнение