MVP. Как миллионы рублей улетают в трубу
В корпоративной среде MVP перестаёт быть MVP и превращается в долгострой с высоким потенциалом закрытия и потери денег. Далее, предлагаю называть такой тип проектов «корпоративный MVP».
К счастью или к сожалению, у меня был неоднократный опыт управления подобными продуктами. Это полезный опыт, который взрастил меня как продакта и теперь заставляет задуматься при появлении симптомов корпоративного MVP. Поделюсь наблюдениями.
Проблема
На корпоративный MVP навешивают излишний функционал, который кажется важным и необходимым, что увеличивает сроки разработки в десятки раз.
Но цель MVP - как можно быстрее получить заинтересованность потенциальных клиентов и начать собирать обратную связь у ЦА о продукте, чтобы развивать только то, что нужно ЦА (за что нам будут платить).
Проект не доживает до первых пользователей, его могут прикрыть в процессе. У инвестора заканчиваются деньги, желание вкладываться, перестаёт нравиться идея, появляется другая, более перспективная идея, меняются параметры рынка, тренды и т.п.
Но даже если корпоративный MVP реализовали, спустя месяцы разработки (на самом деле это уже не MVP), то отклика от потенциальных клиентов может не оказаться. Или он такой маленький, на уровне статистической погрешности, что выводы сделать трудно.
И вот, у нас на руках обвешанная фичами штуковина, которая нравится команде. А потребителю это не нужно)) У него и так всё хорошо.
Почему так происходит
В каждом отдельном случае причины разные. Я замечал такие:
- В компаниях/корпорациях много заинтересованных лиц. Все лоббируют свои интересы и без основательно настаивают на внедрении той или иной функции. Каждая фича удлиняет длительность разработки и не факт, что эта фича на что-то существенно повлияет или вообще нужна клиенту.
- Частный случай пункта выше - инвестор/собственник активно участвует в работе и настаивает «продукт должен быть как я его вижу».
- Компания попадает в порочный круг - не хочет ударить в грязь лицом перед клиентами и хочет сразу выпустить продукт, который идеально работает и имеет все основные и дополнительные функции. Но чтобы выпустить продукт, который работает - нужно сделать очень много фич, которые увеличивают длительность работ в десятки раз. А пока команда делает все фичи из бэклога, оказывается, что их нужно делать в несколько раз дольше, чем предполагалось. И момент проверки MVP в бою постоянно откладывается.
- Компании/корпорации прошли стадию «Стартап», находятся в стадии Роста/Зрелости/Стагнации. Появились бюрократические процессы, множество людей участвуют в принятии решений, нет той скорости реакции как раньше, когда компания работала в подвальном офисе и кофе было из пакетиков, а не кофемашины. Продакт не можем принять решение без согласования. Да ещё и не факт, что согласуют.
- Команда не до конца понимает приоритеты и/или приоритеты меняются (когда есть несколько заинтересованных сторон и они не согласуют действия между собой). Время и деньги расходуются на смену приоритетов и разработку нового функционала.
- Нет настоящих продуктовых процессов, для быстрых тестов гипотезы. Компания привыкла получать деньги от центральной деятельности и не вкладывается в исследовательскую деятельность и RnD команду, которая занимается тестами бизнес-гипотез, порой без видимого мгновенно результата. На выращивание RnD команды и процессов нужны месяцы слаженной работы. Но руководство думает, что если сразу нет результата, можно и не вкладываться в RnD;
- Команда недостаточно внимания уделяет глубинным интервью (custdev) и стратегии продукта (JTBD). Продукт разрабатывается без понимания боли, которую решаем (product/solution fit) и зачем клиентам наш продукт (job story). И поливается этот бутерброд соусом из больших сроков разработки.
В итоге работа над корпоративным MVP работается, а заветный момент получения обратной связи от рынка - отсутствует. Команда вслепую или на основе своих галлюцинаций приоритизирует и добавляет новые фичи, которые снова не доходят до пробы в бою.
Косвенные потери
Не все думают о негативном опыте участников корпоративного MVP (который закрыли или который не нашёл отклик у аудитории).
Команда остаётся демотивирована, что не смогла сделать успешный продукт. Собственник или инвестор теряет деньги и время. Топ-менеджеры, которые руководили или отвечали за продукт - теряют доверие инвестора.
Могут сформироваться ошибочные логические цепочки:
- «Проект провалился - команда слабая». Не факт, что команда слабая, но подход был слабый.
- «Если снова пробовать что-то новое и неизведанное - случится провал». Менеджеры опасаются быть за это ответственными. Но для выстраивания сложных процессов исследований и тестирований новых ниш нужно время. С первого раза у команды может не получиться, нужно не останавливаться и пробовать ещё. При этом меняя подход, улучшая навыки продуктовой команды.
Во всем виноваты продакты!
И да, и нет :)
Менеджер продукта должен выполнять свою работу по построению стратегии продукта, проводить интервью, искать боли, анализировать конкурентов, приоритизировать фичи, чтобы на разработку и тест MVP уходили дни, максимум недели.
Но в корпоративной среде бывают блокеры (описанные в выше). Уровень навыков и развитости команды усредняется исходя из состава команды. Если кто-то не понимает принципов MVP и влияет на принятие решений, то результаты команды будут хромать.
Какое решение
Инвестор, менеджеры, все кто влияют на концепцию проекта, приоритизацию фич, должны знать принципы MVP:
- Основная задача - протестировать идею как можно скорее;
- MVP необязательно должен быть идеальным. Если что-то сбоит или ещё не завершено, но это не мешает клиентам пользоваться продуктом - нужно скорее пробовать;
- Хороший результат тестирования MVP - потенциальные клиенты заинтересовались в продукте/услуге;
- MVP обладает ровно тем минимумом функций, который удовлетворит потребности ЦА и они смогут пользоваться продуктом. Все дополнительные фичи - лишнее трата времени и денег, на этапе тестирования гипотезы;
- MVP должен являться источником обратной связи целевой аудитории. Если эту связь можно получить через CustDev или посадочную страницу с описанием продукта, то можно ни чего и не разрабатывать, а запустить лендинг и собрать заявки. Большинство функций или вообще сам продукт можно сделать на готовых фрейморках/платформах, с использованием No Code, Low Code, Zero code решений;
- До разработки, нужно выявить проблему/боль целевой аудитории, которую мы хотим решить. Для этого нужно общаться с потенциальными клиентами по средствам глубинных интервью (custdev). Интервью должно быть достаточно, чтобы понять тенденции. Лучше плохой custdev, чем его отсутствие;
- Если в проекте много заинтересованных лиц, лучше собрать всех и убедиться, что приоритеты вся команда понимает одинаково. И MVP в итоге закроет ровно ту гипотезу, которую все хотят протестировать.
- Если MVP не нашёл успеха, гипотеза не подтвердилась, то без изменений гипотезы, сегмента ЦА, не нужно делать из текущей версии MVP бизнес. Он с большей долей вероятности провалится.
Выводы
В поиске новых ниш и выводе продукта на рынок - миллиард подводных камней и шанс 1 из 1000, что получится. Следование принципам MVP не гарантирует успеха, но поможет избежать базовых ошибок и заранее увидеть симптомы отклонения от курса.
Моё мнение: верная стратегия заключается в повышении продуктовых знаний (своих и команды), применении знаний чаще на практике, чтобы любые тесты становились быстрыми и дешевыми.
Если у тебя есть похожий опыт, будет интересно узнать о нем: напиши в комментариях.
Понравилась статья? Подпишись на мой канал https://t.me/dzhumailocom про продакт-менеджмент.
Дык именно поэтому Гугл купил стартап, разрабатывающий андроид, а не разработал его сам с нуля. Та же байда с ютубом. Энтерпрайз со всеми его потрохами не заточен под нормальную продуктовую разработку, не говоря уже про MVP. Успешные и настоящие MVP у корпоратов это крайне редкая история. Чтобы начать делать продукты нужно сначала с мясом вырезать все корпоративное, и не на словах, а на деле.
Резонное замечание. Но компании все равно продолжают вкладываться в тестирование идей, так как проект уже в записали в планы. Но иногда упускаются базовые нюансы и начинается то, что описал в статье :)
Точно так и есть, но не уверен что в десятки раз увеличивает срок релиза, но на пару спринтов точно
Я присутствовал при таком, что MVP с планом на 2 недели, разрабатывался в итоге 3 месяца из-за смены приоритетов и того, что добавляется новый функционал, который настоятельно пропихивают в разработку. И это при том, что 50% фич и задач - удалось срезать