Приоритизация фичей

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

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

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



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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

Итог


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

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

Средняя зарплата в IT

111 380 ₽/мес.
Средняя зарплата по всем IT-специализациям на основании 7 299 анкет, за 2-ое пол. 2020 года Узнать свою зарплату
AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Подробнее
Реклама

Комментарии 9

    –2
    Установите своим приоритиетом изучение русского языка, а то на вашу писанину смотреть больно.
      +3

      ТеоретИзация, типИзация.
      ПриорИтЕт, но приорИтИзация

        0
        Ну чего вы придрались? Сделайте скидку на гуманитариев :)
        +4

        Вот так и копятся годами баги: исправлять долго и неохота (три пальца сложности!), импакт небольшой (кто помнит о багах, кроме хейтеров? в топку их!). Лучше встроить ТикТок в Фотошоп: просто, быстро, молодежно.

          +2

          Ну хз насколько это быстро и просто.

          +10
          Мы как продукт менеджеры, генерируем неисчисляемое количество идей.
          Вы как продукт менеджеры генерируете неисчисляемое количество геморроя для разработчиков.

          1 палец — фича не очень, 2 пальца — фича норм, 3 пальца — фича просто бомба.
          Вы произносите фичу и на счет “раз, два, три”, члены команды поднимают пальцы.
          Читаю и понимаю, что всегда бы сидел с поднятым средним пальцем :-)
            +2
            Пример приоритизации по ROI

            Можно чуть детальнее раскрыть прибыль с оборота в 226%?
            Хотя бы привести полный пример, а не действия с ячейками в экселе, спасибо
              +2

              "Переводим все в челвоека часы и получаем стоимость разработки."
              Лучше завязывайте с этим. Это за гранью добра и зла.
              И статьи писать тоже.

                +3
                По-моему, метод poker planning — хороший способ погрязнуть в фичах, которые никому не нужны и далее участь проекта может стать незавидной(а то и похоронить его после неукротимого разбухания):

                Команде ставится условие: 1 палец — фича не очень, 2 пальца — фича норм, 3 пальца — фича просто бомба


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

                Я понимаю, что там есть ещё множитель «сложности». Но при равных сложностях выигрывают фичи, «любимые» командой, а не те, что нужны для успеха продукта. Хотя, часть фич может и совпасть.

                Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                Самое читаемое