[Управление проектами, Growth Hacking, Развитие стартапа, Управление продуктом] Как приоритизировать продуктовые гипотезы на основе юнит-экономики: разбираем примеры
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
Дел у менеджеров по продукту всегда больше, чем ресурсов. Новые задачи приходят со всех сторон — от дизайнеров до маркетологов и CEO. Но если брать в работу все подряд, есть риск получить на выходе не то, что нужно для развития проекта, а то, что было «по фану» кому-то из коллег. Так, сооснователь KISSmetrics Хитен Ша признался, что его компания потеряла позиции на рынке именно из-за ошибок приоритизации. Как только у него появлялись новые идеи, подчиненные должны были бросить все и начать работу над ними. О вдумчивом распределении сил речь тогда не шла. Пока команда пыталась успеть за руководителем, конкуренты захватывали рынок и выпускали новые продукты.Расскажем, как не допустить такого развития событий с помощью простых методик для приоритизации гипотез. Вообще говоря, эту тему часто поднимают на профильных конференциях и семинарах. Так, Мэтт Билотти, менеджер продукта в Drift, интерактивной маркетинговой платформы, которая заняла шестое место в рейтинге самых быстрорастущих компаний по версии Deloitte, поделился на Epic Growth SEASONS своим взглядом на то, как можно приоритизировать гипотезы на основе юнит-экономики. Он объяснил, в чем преимущества подхода и как его можно использовать в работе.
Источник: unsplash.comМетод оценки задач ICE и его соседиНекоторые команды расставляют приоритеты продуктовым задачам и гипотезам с помощью балльной системы — оценивают их по нескольким критериям: степени влияния на продукт, потенциальной скорости реализации, степени уверенности в успехе гипотезы и др. Каждому фактору участники команды присваивают баллы — от одного до десяти — и находят среднее арифметическое. Допустим, если реализовать идею можно достаточно оперативно, критерий скорости реализации получит восемь-десять баллов. Итоговые показатели по всем гипотезам можно сравнить и определить приоритет.Такой метод оценки называется ICE — влияние (Impact), уверенность (Confidence), усилия (Effort). Он был придуман Шоном Эллисом, автором термина «Growth Hacking». Преимущество подхода — в его простоте: чтобы оценить задачу, достаточно присвоить значения от одного до десяти для каждого из факторов и вычислить ICE Score:ICE Score = Impact*Confidence*Effort.Недостаток метода — в его субъективности. Кто-то выполнит задачу за несколько часов, другие — потратят пару дней или неделю. Этот момент достаточно сложно оценить, поэтому команды, использующие метод оценки ICE, часто вязнут в обсуждениях и вкусовщине, а объективные показатели оставляют за бортом.В отличие от него, так называемый RICE — охват (Reach), влияние (Impact), уверенность в оценке (Confidence), трудозатраты (Effort) — более сбалансирован. RICE Score = (Reach*Impact*Confidence) / Effort.Чтобы оценить фактор охвата, нужно рассчитать количество пользователей, которому придется столкнуться с изменениями в продукте. Фактор влияния обычно отражает ценность, которую фича приносит продукту. Для количественного выражения влияния используют шкалу множественного выбора (это такая модель выбора, когда нужно принять одно решение, но выбрать между тремя и более вариантами):
- 3 — массовое влияние;
- 2 — высокое;
- 1 — среднее;
- 0,5 — низкое;
- 0,25 — минимальное.
Оценка фактора уверенности всегда вызывает много вопросов. Если остальные показатели можно оценить достаточно точно, то как оценить уверенность? И как снизить субъективное влияние в процессе утверждения приоритетов? Можно использовать диаграмму Итамара Гилада, бывшего продакта в Google и Microsoft. На ней можно увидеть описание типичных фактов, на основе которых обычно рассчитывают значения параметра Confidence (личное мнение, экспертная оценка, идея коллеги, фича конкурента, результаты UX исследований, данные на основе интервью и др.). Предположим, ваша уверенность в успехе фичи основана на мнении кого-то из членов команды или личном мнении. Оценка этого фактора в таком случае будет около нуля.Гипотезы, основанные на данных маркетинговых исследований, запросах пользователей, результатах юзабилити тестов получат низкий уровень уверенности (от 1 до 3). Если же вы, расставляя приоритеты задачам, делаете выводы на основе длительных исследований поведения пользователей, результатов запуска MVP, A/B-тестов и других достоверных данных, уровень уверенности может быть средним (от 3 до 7). 
Источник: unsplash.comВообще говоря, есть много разных подходов для приоритизации задач, все зависит запросов и целей команды. Какие-то компании даже придумывают свои методы. Так, в Netflix используют DHM-подход, в котором гипотезы оценивают по трем критериям:
- D — delight;
- H — hard to copy;
- M — margin.
На практике это означает, что нужно задать ряд вопросов относительно каждой гипотезы. Например, принесет ли прибыль ввод этой фичи? Будут ли пользователи удовлетворены изменениями? Насколько сложно будет конкурентам скопировать этот функционал? Для того, чтобы Netflix начали тестировать гипотезу, она должна соответствовать как минимум двум критериям DHM-модели, а лучше — всем трем.
Источник: unsplash.comВ блоге Ducalis.io мы нашли классную схему, в которой можно выбрать фреймворк для приоритизации исходя из запросов конкретно вашей команды. Помимо уже известных ICE, RICE, DHM, есть и другие подходы: REAN метод (Reach, Engage, Activate, Nurture), приоритизация на основе North Star метрики, матрица усилий (Effort Matrix), AARRR скоринг и др. Альтернативный подходЕсли возвращаться к команде Drift, то Мэтт Билотти говорит, что отказ от ICE стал возможным благодаря поиску альтернатив. В этом ему помог Дариус Контрактор, который в течение четырех лет развивал Dropbox, руководил отделом роста в Facebook Messenger, а теперь работает Head of Growth в Airtable. Он рассказал Мэтту про подход EVELYN.
Шаблон EVELYN bit.ly/evelyn-airtableDrift вдохновились EVELYN и создали свою систему приоритизации. Суть в том, чтобы оценивать продуктовые гипотезы исходя из того, какую прибыль они могут принести компании. Для этого команда должна определить, что включает в себя весь путь пользователя и рассчитать юнит-экономику на каждом шаге воронки.Когда вы построили весь путь пользователя и рассчитали экономику продукта, у вас появится перечень метрик. Это может выглядеть следующим образом:UA — число привлеченных пользователейMarketing costs — затраты на маркетингC1 — конверсия в первую покупкуBuyers — количество покупателейAvP — средний чекARPC — средний доход на клиента (без учета маркетинговых затрат)ARPU — средний доход на одного пользователя без учета маркетинговых затратARPPU — доход с платящего пользователя за вычетом издержек CAC — стоимость привлечения клиента. CPA — стоимость одного привлеченного пользователя в начало воронки и др.Более подробно о юнит-экономике можно почитать в блоге Даниила Ханина. В этой статье автор дает объяснение метрикам, которые упоминаются выше, можете начать с нее. Специалисты Drift предлагают выбрать десять-двадцать метрик в денежном выражении, на которые вы можете влиять, внося изменения в продукт или маркетинг. Затем сформулируйте гипотезы — благодаря каким действиям вы хотите увеличить или уменьшить выбранную метрику. Чтобы рассчитать, сколько гипотеза может принести компании, нужны следующие показатели:— метрика, на которую вы хотите повлиять (в денежном выражении) (a);— во сколько раз эксперимент может увеличить эту метрику (b);— вероятность, что гипотеза сработает, в процентном выражении (c);— количество дней, которое необходимо для реализации гипотезы (d).Вот так выглядит формула:Value per Day = (a * b * c) / d.
Из презентации Мэтта Билотти на Epic Growth SEASONSНапример, метрика влияния — ARPU, или средний доход с пользователя, составляет $1. Вы должны определить, во сколько раз эксперимент увеличит вашу метрику. Например, вы предполагаете, что ARPU станет не $1, а $20. Значит, opportunity size будет равен двадцати. Предположим, вы уверены в успехе на 70%. Значит умножайте на 0,7. Если на реализацию идеи вам понадобится два дня, то полученное произведение цифр нужно разделить на два. Итого получаем: Value per Day = ($1*20*0,7)/2 = $7. Таким образом, Value per Day метрика отражает, сколько дохода фича может сгенерировать за N потраченных на ее реализацию рабочих дней. Так как в нашем примере Value per Day составил семь долларов, а эксперимент занял два дня, ежемесячно фича будет генерировать доход в четырнадцать долларов ($7*2) до тех пор, пока метрика влияния не изменятся (в ходе новых экспериментов, например). 
Источник: unsplash.comПосле того, как вы получите значения Value per Day для всех гипотез, вам будет легче определиться с тем, за реализацию какой из них взяться в первую очередь. Так вы будете меньше времени тратить на обсуждение мнений и легче доносить ценность своих идей до коллег и руководителей. Если сделать документ с гипотезами открытым, любой человек в компании сможет внести свои идеи или посмотреть список задач в порядке приоритета. Так, у всех членов команды будет понимание того, какие гипотезы находятся в процессе тестирования и какой результат получен по уже проведенным экспериментам. Работа станет более предсказуемой.Полезные источники по темеВыступление Мэтта на Epic Growth SEASONSФреймворки по приоритизации задачЕще один список фреймворков для управления продуктамиПервоисточник RICE фреймворка в блоге IntercomDHM подход к приоритизации гипотез от Netflix Блог Даниила Ханина о юнит-экономике
===========
Источник:
habr.com
===========
Похожие новости:
- [Управление разработкой, Управление проектами] Почему инженеры не могут оценить время разработки (перевод)
- [Развитие стартапа, Законодательство в IT, Бизнес-модели] Налоговая выдаст ЭЦП бесплатно для ИП и юрлиц
- [Венчурные инвестиции, Развитие стартапа, Финансы в IT, IT-компании] Новости IT и стартапов: продолжается охота на Трампа, правда о китайском рейтинге
- [ERP-системы, CRM-системы, Управление разработкой, Управление проектами, Будущее здесь] Digital-трансформация завода: CRM для ERP, роботизация БП и оживление железа, ЛК, чат-боты и dream team (ч. 1)
- [Разработка игр, Управление проектами, Игры и игровые приставки, IT-компании] Бывшие и настоящие разработчики рассказали о процессе создания Cyberpunk 2077. Игру начали делать только в 2016 году
- [Управление проектами] Как я стал PMP, не выпив ни одного кофе
- [Развитие стартапа, Краудсорсинг, Интервью] Истории основателей: Грейс Гэри, основательница Watsi (YC W13) (перевод)
- [Тестирование IT-систем, Agile, Управление продуктом, Софт] На ком лежит ответственность за качество программного обеспечения? (перевод)
- [Развитие стартапа, Карьера в IT-индустрии] 20 месяцев, 2000 часов работы, 200 000 евро убытков: история об упорстве и невозвратных затратах (перевод)
- [Венчурные инвестиции, Развитие стартапа] Y Combinator: Как организовать совет директоров для стартапа и рулить им (перевод)
Теги для поиска: #_upravlenie_proektami (Управление проектами), #_growth_hacking, #_razvitie_startapa (Развитие стартапа), #_upravlenie_produktom (Управление продуктом), #_prioritizatsija_zadach (приоритизация задач), #_upravlenie_produktom (управление продуктом), #_prodaktmenedzhment (продакт-менеджмент), #_produktovyj_groushaking (продуктовый гроусхакинг), #_rost_produktov (рост продуктов), #_junitekonomika (юнит-экономика), #_upravlenie_proektami (
Управление проектами
), #_growth_hacking, #_razvitie_startapa (
Развитие стартапа
), #_upravlenie_produktom (
Управление продуктом
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 08:40
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
|
Дел у менеджеров по продукту всегда больше, чем ресурсов. Новые задачи приходят со всех сторон — от дизайнеров до маркетологов и CEO. Но если брать в работу все подряд, есть риск получить на выходе не то, что нужно для развития проекта, а то, что было «по фану» кому-то из коллег. Так, сооснователь KISSmetrics Хитен Ша признался, что его компания потеряла позиции на рынке именно из-за ошибок приоритизации. Как только у него появлялись новые идеи, подчиненные должны были бросить все и начать работу над ними. О вдумчивом распределении сил речь тогда не шла. Пока команда пыталась успеть за руководителем, конкуренты захватывали рынок и выпускали новые продукты.Расскажем, как не допустить такого развития событий с помощью простых методик для приоритизации гипотез. Вообще говоря, эту тему часто поднимают на профильных конференциях и семинарах. Так, Мэтт Билотти, менеджер продукта в Drift, интерактивной маркетинговой платформы, которая заняла шестое место в рейтинге самых быстрорастущих компаний по версии Deloitte, поделился на Epic Growth SEASONS своим взглядом на то, как можно приоритизировать гипотезы на основе юнит-экономики. Он объяснил, в чем преимущества подхода и как его можно использовать в работе.  Источник: unsplash.comМетод оценки задач ICE и его соседиНекоторые команды расставляют приоритеты продуктовым задачам и гипотезам с помощью балльной системы — оценивают их по нескольким критериям: степени влияния на продукт, потенциальной скорости реализации, степени уверенности в успехе гипотезы и др. Каждому фактору участники команды присваивают баллы — от одного до десяти — и находят среднее арифметическое. Допустим, если реализовать идею можно достаточно оперативно, критерий скорости реализации получит восемь-десять баллов. Итоговые показатели по всем гипотезам можно сравнить и определить приоритет.Такой метод оценки называется ICE — влияние (Impact), уверенность (Confidence), усилия (Effort). Он был придуман Шоном Эллисом, автором термина «Growth Hacking». Преимущество подхода — в его простоте: чтобы оценить задачу, достаточно присвоить значения от одного до десяти для каждого из факторов и вычислить ICE Score:ICE Score = Impact*Confidence*Effort.Недостаток метода — в его субъективности. Кто-то выполнит задачу за несколько часов, другие — потратят пару дней или неделю. Этот момент достаточно сложно оценить, поэтому команды, использующие метод оценки ICE, часто вязнут в обсуждениях и вкусовщине, а объективные показатели оставляют за бортом.В отличие от него, так называемый RICE — охват (Reach), влияние (Impact), уверенность в оценке (Confidence), трудозатраты (Effort) — более сбалансирован. RICE Score = (Reach*Impact*Confidence) / Effort.Чтобы оценить фактор охвата, нужно рассчитать количество пользователей, которому придется столкнуться с изменениями в продукте. Фактор влияния обычно отражает ценность, которую фича приносит продукту. Для количественного выражения влияния используют шкалу множественного выбора (это такая модель выбора, когда нужно принять одно решение, но выбрать между тремя и более вариантами):
 Источник: unsplash.comВообще говоря, есть много разных подходов для приоритизации задач, все зависит запросов и целей команды. Какие-то компании даже придумывают свои методы. Так, в Netflix используют DHM-подход, в котором гипотезы оценивают по трем критериям:
 Источник: unsplash.comВ блоге Ducalis.io мы нашли классную схему, в которой можно выбрать фреймворк для приоритизации исходя из запросов конкретно вашей команды. Помимо уже известных ICE, RICE, DHM, есть и другие подходы: REAN метод (Reach, Engage, Activate, Nurture), приоритизация на основе North Star метрики, матрица усилий (Effort Matrix), AARRR скоринг и др. Альтернативный подходЕсли возвращаться к команде Drift, то Мэтт Билотти говорит, что отказ от ICE стал возможным благодаря поиску альтернатив. В этом ему помог Дариус Контрактор, который в течение четырех лет развивал Dropbox, руководил отделом роста в Facebook Messenger, а теперь работает Head of Growth в Airtable. Он рассказал Мэтту про подход EVELYN.  Шаблон EVELYN bit.ly/evelyn-airtableDrift вдохновились EVELYN и создали свою систему приоритизации. Суть в том, чтобы оценивать продуктовые гипотезы исходя из того, какую прибыль они могут принести компании. Для этого команда должна определить, что включает в себя весь путь пользователя и рассчитать юнит-экономику на каждом шаге воронки.Когда вы построили весь путь пользователя и рассчитали экономику продукта, у вас появится перечень метрик. Это может выглядеть следующим образом:UA — число привлеченных пользователейMarketing costs — затраты на маркетингC1 — конверсия в первую покупкуBuyers — количество покупателейAvP — средний чекARPC — средний доход на клиента (без учета маркетинговых затрат)ARPU — средний доход на одного пользователя без учета маркетинговых затратARPPU — доход с платящего пользователя за вычетом издержек CAC — стоимость привлечения клиента. CPA — стоимость одного привлеченного пользователя в начало воронки и др.Более подробно о юнит-экономике можно почитать в блоге Даниила Ханина. В этой статье автор дает объяснение метрикам, которые упоминаются выше, можете начать с нее. Специалисты Drift предлагают выбрать десять-двадцать метрик в денежном выражении, на которые вы можете влиять, внося изменения в продукт или маркетинг. Затем сформулируйте гипотезы — благодаря каким действиям вы хотите увеличить или уменьшить выбранную метрику. Чтобы рассчитать, сколько гипотеза может принести компании, нужны следующие показатели:— метрика, на которую вы хотите повлиять (в денежном выражении) (a);— во сколько раз эксперимент может увеличить эту метрику (b);— вероятность, что гипотеза сработает, в процентном выражении (c);— количество дней, которое необходимо для реализации гипотезы (d).Вот так выглядит формула:Value per Day = (a * b * c) / d.  Из презентации Мэтта Билотти на Epic Growth SEASONSНапример, метрика влияния — ARPU, или средний доход с пользователя, составляет $1. Вы должны определить, во сколько раз эксперимент увеличит вашу метрику. Например, вы предполагаете, что ARPU станет не $1, а $20. Значит, opportunity size будет равен двадцати. Предположим, вы уверены в успехе на 70%. Значит умножайте на 0,7. Если на реализацию идеи вам понадобится два дня, то полученное произведение цифр нужно разделить на два. Итого получаем: Value per Day = ($1*20*0,7)/2 = $7. Таким образом, Value per Day метрика отражает, сколько дохода фича может сгенерировать за N потраченных на ее реализацию рабочих дней. Так как в нашем примере Value per Day составил семь долларов, а эксперимент занял два дня, ежемесячно фича будет генерировать доход в четырнадцать долларов ($7*2) до тех пор, пока метрика влияния не изменятся (в ходе новых экспериментов, например).  Источник: unsplash.comПосле того, как вы получите значения Value per Day для всех гипотез, вам будет легче определиться с тем, за реализацию какой из них взяться в первую очередь. Так вы будете меньше времени тратить на обсуждение мнений и легче доносить ценность своих идей до коллег и руководителей. Если сделать документ с гипотезами открытым, любой человек в компании сможет внести свои идеи или посмотреть список задач в порядке приоритета. Так, у всех членов команды будет понимание того, какие гипотезы находятся в процессе тестирования и какой результат получен по уже проведенным экспериментам. Работа станет более предсказуемой.Полезные источники по темеВыступление Мэтта на Epic Growth SEASONSФреймворки по приоритизации задачЕще один список фреймворков для управления продуктамиПервоисточник RICE фреймворка в блоге IntercomDHM подход к приоритизации гипотез от Netflix Блог Даниила Ханина о юнит-экономике =========== Источник: habr.com =========== Похожие новости:
Управление проектами ), #_growth_hacking, #_razvitie_startapa ( Развитие стартапа ), #_upravlenie_produktom ( Управление продуктом ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 08:40
Часовой пояс: UTC + 5