Приоритизация: пример из практики
#productdo_опыт
Владимир на связи. Буквально на прошлой неделе мне надо было выбрать, с каких из 30 экспериментов по улучшению рекомендаций для пользователей начать. В задачках по этой теме часто встречаются уже проработанные ответы (“эксперимент A принесет нам +20% кликов" и тд). Но в реальной жизни - мы этих цифр заранее не знаем. А выбирать все равно надо - за это нам, продактам, и платят 🙂
Шаг 1. Мы выделили 10 экспериментов используя “насмотренность”. Да, это неидеально, но нахождение ответов иногда занимает больше времени, чем сам эксперимент. Так что 20 сразу оставили на потом.
Шаг 2. Для оставшихся 10 сформулировали простую RICE табличку:
Reach: сколько пользователей увидят изменения
Impact: какая наша оценка ценности этого для пользователей и бизнеса
Confidence: насколько все “просто”
Effort: сколько это кодить
На основе этого посчитали RICE score = Reach x Impact x Confidence / Effort и приоритизировали запуски.
Идеально ли это? Вообще нет - мы могли ошибиться в оценках. Более того, чем сложнее проект - тем меньше цифры становятся адекватными. Например, если вы мне скажете, что “оценка Effort для сервиса отзывов в компании онлайн-такси равна 3/10” без дополнительных объяснений, я вам не поверю, потому что вы не оценили сложность бизнес-логики, архитектуру, требования к трафику, зависимости и тд).
Такой “настоящей” оценке мы учим на курсе “Tech для продакта”.
Но, для простых фич/экспериментов эта немудреная RICE-математика работает отлично.
Если сталкивались, расскажите, как вы приоритизируете список из 30 идей?
#productdo_опыт
Владимир на связи. Буквально на прошлой неделе мне надо было выбрать, с каких из 30 экспериментов по улучшению рекомендаций для пользователей начать. В задачках по этой теме часто встречаются уже проработанные ответы (“эксперимент A принесет нам +20% кликов" и тд). Но в реальной жизни - мы этих цифр заранее не знаем. А выбирать все равно надо - за это нам, продактам, и платят 🙂
Шаг 1. Мы выделили 10 экспериментов используя “насмотренность”. Да, это неидеально, но нахождение ответов иногда занимает больше времени, чем сам эксперимент. Так что 20 сразу оставили на потом.
Шаг 2. Для оставшихся 10 сформулировали простую RICE табличку:
Reach: сколько пользователей увидят изменения
Impact: какая наша оценка ценности этого для пользователей и бизнеса
Confidence: насколько все “просто”
Effort: сколько это кодить
На основе этого посчитали RICE score = Reach x Impact x Confidence / Effort и приоритизировали запуски.
Идеально ли это? Вообще нет - мы могли ошибиться в оценках. Более того, чем сложнее проект - тем меньше цифры становятся адекватными. Например, если вы мне скажете, что “оценка Effort для сервиса отзывов в компании онлайн-такси равна 3/10” без дополнительных объяснений, я вам не поверю, потому что вы не оценили сложность бизнес-логики, архитектуру, требования к трафику, зависимости и тд).
Такой “настоящей” оценке мы учим на курсе “Tech для продакта”.
Но, для простых фич/экспериментов эта немудреная RICE-математика работает отлично.
Если сталкивались, расскажите, как вы приоритизируете список из 30 идей?