Вступление.
Мы как продукт менеджеры, генерируем неисчисляемое количество идей. Каким-то образом у себя в голове их приоритизируем. Голова лопается, мы не знаем , что делать с этими идеями. В вашем “листе идей” какой-то ад творится… Особенно это знакомо людям которые только начинают свой путь в бизнесе, или же только начинают свой путь продуктами.
Эта статья поможет быстро (на пальцах) откинуть из сотни фичей большую часть. И оставить только те, которые действительно принесут бизнесу пользу.
Исходя из данной таблицы, можно сделать вывод.
По горизонтали есть внутренние методы приоритизации , которые решаются в рамках компании - команды.
Если же принимают участие пользователи, то соответственно это внешние.
По вертикали, то сколько данных есть для принятия решений.
Качественные когда вы делаете глубинные интервью от десятков респондентов. И количественные, когда имеется много разных аналитических данных.
Внешние методы применяются:
Когда продукт только вышел в свет, и мы пока не понимаем глубинных потребностей потребителя.
Когда внутри компании есть ключевые подразделения которые принимают решения (аналитика, маркетинг, сейлзы, стейкхолдеры).
Внутренние методы применяются:
Когда есть история какая функциональность меняет метрики, можно сделать приоритизация внутри команды.
Уточнение результатов полученных из внешних методов;
Мы рассмотрели основные различия внутренних и внешних методов.
Далее мы рассмотрим такие методы приоритизации как быстрая (на пальцах) и медленная.
Быстрая позволяет откинуть наиболее не ценные функции, а медленная помогает выбрать из оставшихся самые лучшие.
Быстрые методы:
Метод Reach/Frequency
Reach - охват аудитории. Сколько людей готовы воспользоваться фичей.
Frequency - частота использования фичи.
В идеале нам нужен верхний правый угол. Те кто все время пользуется и вся аудитория.
Метод Poker planning.
Идея взята из Agile методологий.
Оценка производится внутри команды.
Оценка пользы фичи:
Команде ставится условие: 1 палец - фича не очень, 2 пальца - фича норм, 3 пальца - фича просто бомба.
Вы произносите фичу и на счет “раз, два, три” , члены команды поднимают пальцы. Считаете средний балл. (Можете приглашать внешних людей из других проектов).
Оценка затрат:
Собираем разработчиков, говорим про функционал и так же ставим условие: 1 палец - быстро сделают. 2 пальца - разработка будет не сложной. 3 пальца - разработка будет очень сложной и долгой.
Далее мы делим пользу на затраты и получаем приблизительную оценку функциональности.
Фича 4 имеет самый высокий процент, значит точно будет вверху таблицы приоритизаций. Фича 2 имеет самый низкий процент - мы точно выкидываем из нашего бэклога.
Медленные методы.
RICE.
Разработан компанией intercom.
Это такой метод приоритезации идей и фич продукта, который включает 4 фактора, которые менеджер продукта использует для оценки и приоритизации фич:
Reach - охват аудитории. Не забываем, что охват именно тех людей, которые увидят эту фичу.
Impact - влияние фичи на пользователя. Его радость, бусты, эмоции от данной фичи. (0.25 - очень плохо, 0.5 - плохо, 1 - средне, 2 - хорошо, 3 - отлично)
*** Некоторые считают что impact - это именно влияние фичи на компанию. То есть какое количество метрик мы подымем при помощи этой фичи.
Confidence - Уверенность в гипотезе. Довольно важный параметр, показывающий на сколько вы считаете хороша ли гипотеза, т.к мы не всегда придумываем супер-топ идеи. ( Высокая = 100%, средняя = 80%, слабая = 50% и ниже)
Effort - Сложность разработки. Обычно указывается в месяцах. (пол месяца 0.5)
Приоритизация по ROI.
Изначально Вам нужно сделать иерархию метрик. Если Ваш продукт не Amazon и не google, более чем достаточно будет сделать древовидную систему. Что из чего происходит. Например Life time Value напрямую зависит от Retention. Отлично! Этого будет достаточно для интернет магазина. Далее по аналогии в зависимости от масштабов продукта, можно использовать аналитические данные и делать формулы.
Очень удобно когда есть идея, знать на какую метрику она повлияет. И понимать на каком уровне дерева находится. И чем будет придуманная фича ближе к главной метрике, тем профитнее она. Чем дальше, соответственно шансов почти нет, что она повлияет на главную метрику.
Пример приоритизаций из иерархии метрик:
С командой мы расставляем “вес” фичи, на сколько кто в нее верит. + ставится на те которые выбирает большинство. На них можно делать основной акцент на ближайшие пол года.
Пример приоритизации по ROI:
У нас есть количество пользователей за год. Мы делаем прогноз, что воспользуются продуктом 70%, а приобретут продукт 50% от пользователей.
Я прикидываю, что внедрение фичи принесет компании 4% от прибыли.
Зная сколько у нас прибыль от одной оплаты, не сложными расчетыми мы получаем сумму которую наша фича принесет за год дополнительно.
Далее мы идем к разработчикам и понимаем сколько будет длиться разработку. Перводим все в челвоека часы и получаем стоимость разработки.
Имея эти данные мы можем посчитать ROI ((доходы - расходы) / расходы * 100%) фичи.
Таким образом мы можем посчитать все фичи из бэклога и приоритизировать его.
*** Так же можно сделать более детальную проработку таблицы с Реальными % конверсии, пессимистичными и оптимистичными.
Плюсы:
Ты получаешь оценку в деньгах. Люди любят деньги:)
Люди верят числам.
Минусы:
Не учитываются абсолютные значения
Многое зависит от личных скилов продакт менеджера.
Мелкие фичи не понятно как считать.
Нюансы:
Считать прибыль, а не выручку.
Типичные ошибки Product manager’ов:
- Оценивать в одиночку.
Всегда просите , чтобы ваши расчеты кто нибудь проверил. Свежий взгляд всегда хорошо;
- Не учитывают влияние одной части на другие части продукта.
Очень важно думать как вся экосистема работает, чтобы не проседали другие части продукта;
- Повестись на хейтеров.
Всегда есть хейтеры которые пользуются продуктом, но всегда чем то не довольны. Главное не путать между обычными хейтерами и людьми которые хотят помочь продукту. Делать исследования глубже;
- Количественная оценка не всегда лучше, чем качественная.
Если продукт новый, или не большой, лучше всего общаться со своей аудиторий и понимать ее глубинные потребности.
- Закопаться в мелочах. Смотрите на продукт сверху!
Итог:
Подводя итог могу сказать, что та система приоритизации, которая работает в Яндексе, вряд ли будет работать, если вы захотите ее применить для стартапа, в котором работает четыре человека.
Компании разные, у них разные цели, разные задачи, разное позиционирование и положение на рынке — кто-то еле сводит концы с концами и важно заработать денег буквально завтра, иначе стартапу конец, а кому-то деньги уже не так важны в сравнении с положением на рынке или репутацией, у кого-то есть деньги на масштабирование и главной задачей является привлечение новых пользователей, а кто-то не может масштабироваться из-за ограничений инфраструктуры и хочет сократить круг пользователей, но зарабатывать больше денег с существующих. В общем, не все так просто.
Спасибо за уделенное время.
