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

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

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

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

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

MVP в целом

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

Uber

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

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

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

Официальный сайт 2009 года
Официальный сайт 2009 года
Первая версия приложения UberCab
Первая версия приложения UberCab

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

  • Веб приложение на PHP, адаптированное к виду приложения на телефоне (вебвью);
  • Можно было заказать одну из машин, которая реально принадлежала Ubercab (их было несколько);
  • Местоположение машины показывалось на карте;
  • Приложение Ubercab было скрыто из стора, доступ к нему давался через специальный код, который выдавал один из создателей проекта в ответ на письмо-заявку ему в личке;

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

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

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

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

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

Dropbox

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

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

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

То самое видео

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

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

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

MVP как процесс

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

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

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

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

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

Как думаете, такой проект взлетит?
Да, новый unicorn!
Нет, не взлетит
Я томат

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

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

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

Почему?

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

  • Вы можете потратить месяцы на то, чтобы узнать, как запускать пользовательские мобильные приложения для своих клиентов и как покрасивее разработать редактор ресторанных приложений, но в конце вы узнаете, что владельцу ресторана в первую очередь нужен оптимизированный для мобильных устройств веб-сайт, который легко найти в «Яндексе»;
  • Или, использовав все новейшие технологии для создания чата в реальном времени, вы обнаружите, что владельцы ресторанов с трудом справляются с электронной почтой и не хотят сидеть за компьютером весь день;
  • Или, что хуже всего, вы можете обнаружить, что владельцы ресторанов не хотят иметь дело с технологиями, они луддиты, не верят в мобильные приложения и не заинтересованы в использовании вашего продукта в целом;
  • Или ещё что-то, можно долго перечислять.

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

Нет ничего более бесполезного, чем делать с большой эффективностью то, что вообще не следует делать.

Питер Друкер, американский учёный-экономист

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

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

  • Какое моё самое рискованное предположение?
  • Существует ли небольшой эксперимент, который я могу провести, чтобы проверить своё предположение?

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

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

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

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

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

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

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

  • Какое мое самое рискованное предположение теперь?
  • Существует ли небольшой эксперимент, который я могу провести, чтобы проверить своё предположение?

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

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

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

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

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

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

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

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

  • Какое мое самое рискованное предположение теперь?
  • Существует ли небольшой эксперимент, который я могу провести, чтобы проверить своё предположение?

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

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

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

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

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

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

  • Какое мое самое рискованное предположение?
  • Существует ли небольшой эксперимент, который я могу провести, чтобы проверить своё предположение?

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

График того, как устроен постоянный поиск MVP, даже видно где сейчас DTF
График того, как устроен постоянный поиск MVP, даже видно где сейчас DTF

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

Так, а при чём тут магазины и лаунчеры?

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

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

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

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

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

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

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

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

Поздравляю, вы продуктолог!
Поздравляю, вы продуктолог!

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

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

525525
889 комментариев

Итого:
Эпиков нужно понять, потому что они молодой стартап с ограниченным бюджетом?

285
Ответить

Идея цифровой дистрибьюции просто очень новая, непонятно взлетит ли. А на дворе сейчас идет 2003 год.

201
Ответить

Точно их нельзя назвать «стабильным и большим стором, который давно на рынке»

72
Ответить

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

36
Ответить

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

19
Ответить

👌

5
Ответить

Не понять, а оправдать их лень, и то, почему спустя столько времени они ни хе ра не сделали со своим сервисом.

11
Ответить