MVP, часть 4: как избежать неудачи при запуске

Опубликовано 15.03.2021 · в Сайт своими руками

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

То, с чем часто сталкиваются клиенты, которые не привыкли запускать проект малыми циклами.

Расскажем на примере:

У вас есть классная идея для монетизации, проект, дело на миллион. И вы хотите сразу запустить его со всеми фишками и плюшками. Показать, какой интересный и полезный для потребителей.
У вас в голове есть бизнес-план, который вы переносите в бриф.
А дальше-отдаете в команду разработки с целью — «Ребята, внедряем все и взлетаем!».
Серьезно, и с таким лозунгом к нам приходили)

Хотите узнать, что будет дальше? Провал, крах и прочие пугающие слова.

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

Предусловия: на вас работают профессионалы, а не команда «раскрутить клиента и доить его по-максимуму».

Во-первых, вы забыли про Product Owner-а. Вы можете быть гуру в построении бизнеса, но не нужно забывать, что роль данного человека:

  • Разгрузить вас, позволяя освободить время для генерации идей
  • Наладить связь с разработчиками (чаще всего это PM)

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

Во-вторых, идеи и фичи требуют разделения по приоритетности.
Не стоит внедрять все-все сразу. Для этого есть 2 основания:

  1. Продукт новый, вы может сформировать описание целевой аудитории, даже Customer Journey Map, но вы не сможете понять поведенческие факторы при взаимодействии с уже собранным продуктом.
  2. Фичи и идеи на бумаге это теория, без нее, конечно, никуда. Многие фичи не совсем уживаются друг с другом — это практика.

В-третьих, далее, зная о всех рисках и пытаясь учесть все-все при запуске, вы проходите цикл «создание — анализ «все ли учли»- правки — анализ «все ли устраивает»».

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

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

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

Клиент устал — он ждал запуска быстрее
Разработчики — получили часть прибыли
Потребители — так и не узнали о хорошей идее.

© Реальность

Мораль сей басни такова — используйте Agile в разработке, пошагово внедряя фичи, получая обратную связь от потребителей и улучшая интерфейс!