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