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

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

Для начала рассмотрим переменную таблицу методов приоритизаций:



Исходя из данной таблицы, можно сделать вывод.

По горизонтали есть внутренние методы приоритизации, которые решаются в рамках компании — команды.

Если же принимают участие пользователи, то соответственно это внешние.

По вертикали, то сколько данных есть для принятия решений.

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

Внешние методы применяются:
Когда продукт только вышел в свет, и мы пока не понимаем глубинных потребностей потребителя.

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

Внутренние методы применяются:

Когда есть история какая функциональность меняет метрики, можно сделать приоритизация внутри команды.

Уточнение результатов полученных из внешних методов;

Мы рассмотрели основные различия внутренних и внешних методов.

Далее мы рассмотрим такие методы приоритизации как быстрая (на пальцах) и медленная.

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

Быстрые методы

Метод 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’ов

1. Оценивать в одиночку.

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

2. Не учитывают влияние одной части на другие части продукта.

Очень важно думать как вся экосистема работает, чтобы не проседали другие части продукта;

3. Повестись на хейтеров.

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

4. Количественная оценка не всегда лучше, чем качественная.

Если продукт новый, или не большой, лучше всего общаться со своей аудиторий и понимать ее глубинные потребности.

5. Закопаться в мелочах. Смотрите на продукт сверху!

Итог

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

Спасибо за уделенное время.