Дел у менеджеров по продукту всегда больше, чем ресурсов. Новые задачи приходят со всех сторон — от дизайнеров до маркетологов и CEO. Но если брать в работу все подряд, есть риск получить на выходе не то, что нужно для развития проекта, а то, что было «по фану» кому-то из коллег. Так, сооснователь KISSmetrics Хитен Ша признался, что его компания потеряла позиции на рынке именно из-за ошибок приоритизации. Как только у него появлялись новые идеи, подчиненные должны были бросить все и начать работу над ними. О вдумчивом распределении сил речь тогда не шла. Пока команда пыталась успеть за руководителем, конкуренты захватывали рынок и выпускали новые продукты.
Расскажем, как не допустить такого развития событий с помощью простых методик для приоритизации гипотез. Вообще говоря, эту тему часто поднимают на профильных конференциях и семинарах. Так, Мэтт Билотти, менеджер продукта в Drift, интерактивной маркетинговой платформы, которая заняла шестое место в рейтинге самых быстрорастущих компаний по версии Deloitte, поделился на Epic Growth SEASONS своим взглядом на то, как можно приоритизировать гипотезы на основе юнит-экономики. Он объяснил, в чем преимущества подхода и как его можно использовать в работе.
Метод оценки задач 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).
Вообще говоря, есть много разных подходов для приоритизации задач, все зависит запросов и целей команды. Какие-то компании даже придумывают свои методы. Так, в Netflix используют DHM-подход, в котором гипотезы оценивают по трем критериям:
D — delight;
H — hard to copy;
M — margin.
На практике это означает, что нужно задать ряд вопросов относительно каждой гипотезы. Например, принесет ли прибыль ввод этой фичи? Будут ли пользователи удовлетворены изменениями? Насколько сложно будет конкурентам скопировать этот функционал? Для того, чтобы Netflix начали тестировать гипотезу, она должна соответствовать как минимум двум критериям DHM-модели, а лучше — всем трем.
В блоге 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.
Drift вдохновились EVELYN и создали свою систему приоритизации. Суть в том, чтобы оценивать продуктовые гипотезы исходя из того, какую прибыль они могут принести компании. Для этого команда должна определить, что включает в себя весь путь пользователя и рассчитать юнит-экономику на каждом шаге воронки.
Когда вы построили весь путь пользователя и рассчитали экономику продукта, у вас появится перечень метрик. Это может выглядеть следующим образом:
UA — число привлеченных пользователей
Marketing costs — затраты на маркетинг
C1 — конверсия в первую покупку
Buyers — количество покупателей
AvP — средний чек
ARPC — средний доход на клиента (без учета маркетинговых затрат)
ARPU — средний доход на одного пользователя без учета маркетинговых затрат
ARPPU — доход с платящего пользователя за вычетом издержек
CAC — стоимость привлечения клиента.
CPA — стоимость одного привлеченного пользователя в начало воронки и др.
Более подробно о юнит-экономике можно почитать в блоге Даниила Ханина. В этой статье автор дает объяснение метрикам, которые упоминаются выше, можете начать с нее.
Специалисты Drift предлагают выбрать десять-двадцать метрик в денежном выражении, на которые вы можете влиять, внося изменения в продукт или маркетинг.
Затем сформулируйте гипотезы — благодаря каким действиям вы хотите увеличить или уменьшить выбранную метрику. Чтобы рассчитать, сколько гипотеза может принести компании, нужны следующие показатели:
— метрика, на которую вы хотите повлиять (в денежном выражении) (a);
— во сколько раз эксперимент может увеличить эту метрику (b);
— вероятность, что гипотеза сработает, в процентном выражении (c);
— количество дней, которое необходимо для реализации гипотезы (d).
Вот так выглядит формула:
Value per Day = (a * b * c) / d.
Например, метрика влияния — 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) до тех пор, пока метрика влияния не изменятся (в ходе новых экспериментов, например).
После того, как вы получите значения Value per Day для всех гипотез, вам будет легче определиться с тем, за реализацию какой из них взяться в первую очередь. Так вы будете меньше времени тратить на обсуждение мнений и легче доносить ценность своих идей до коллег и руководителей. Если сделать документ с гипотезами открытым, любой человек в компании сможет внести свои идеи или посмотреть список задач в порядке приоритета. Так, у всех членов команды будет понимание того, какие гипотезы находятся в процессе тестирования и какой результат получен по уже проведенным экспериментам. Работа станет более предсказуемой.
Полезные источники по теме
Выступление Мэтта на Epic Growth SEASONS
Фреймворки по приоритизации задачЕще один список фреймворков для управления продуктами
Первоисточник RICE фреймворка в блоге Intercom
DHM подход к приоритизации гипотез от Netflix
Блог Даниила Ханина о юнит-экономике
