Русский
Русский
English
Статистика
Реклама

Из песочницы Приоритизация фичей

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

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

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



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

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

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

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

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

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

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

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

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

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

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

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

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

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


Метод 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. Закопаться в мелочах. Смотрите на продукт сверху!

Итог


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

Спасибо за уделенное время.
Источник: habr.com
К списку статей
Опубликовано: 17.10.2020 16:19:19
0

Сейчас читают

Комментариев (0)
Имя
Электронная почта

Управление проектами

Backlog

Product management

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru