Приоритизация гипотез: как выбрать, что делать прямо сейчас, а что — никогда
Это третья статья из цикла материалов про базу по работе с гипотезами, который я готовила для внутреннего обучения команды продактов OTUS. Ранее я писала про продуктовое мышление и генерацию сильных продуктовых гипотез. Здесь разберемся, как расставить приоритеты, используя популярные фреймворки для оценки и приоритизации гипотез в продуктовом бэклоге.
Зачем нужна приоритизация?
Вы с командой провели мозговой штурм, собрали данные и сформулировали два десятка обоснованных гипотез. Бэклог гипотез полон. Эйфория сменяется паникой: с чего начать? Ресурсы команды ограничены, а проверить всё сразу невозможно.
Именно здесь на сцену выходит приоритизация — искусство принятия взвешенных решений о том, какие гипотезы тестировать в первую очередь, чтобы максимизировать ценность для пользователя и бизнеса.
Зачем нужна приоритизация? Три главные причины:
- Ограниченность ресурсов: Время, люди, деньги — всё это конечно. Приоритизация помогает направить эти ресурсы на ключевые активности.
- Фокус и скорость: Команда, которая знает, над чем работать дальше, тратит меньше времени на споры и переключения контекста. Это ускоряет цикл работы над улучшением продукта.
- Борьба с парадоксом выбора: Когда вариантов слишком много, легко впасть в ступор. Структурированные фреймворки приоритизации снимают этот стресс, предлагая понятный алгоритм выбора.
Методы приоритизации гипотез
Не существует единственно верного «лучшего» фреймворка или методологии. Есть инструменты, которые лучше подходят для разных контекстов. Давайте разберем самые популярные.
1. Value vs Effort (Польза vs Усилия)
Гипотезы размещаются на плоскости с двумя осями: «Польза/Ценность» (Value) по вертикали и «Усилия/Стоимость» (Effort) по горизонтали. Команда коллективно оценивает каждую гипотезу и помещает ее в один из четырех квадрантов:
- Quick Wins (Быстрые/легкие победы): большая польза, низкая стоимость. Делать в первую очередь!
- Big Bets (Крупные ставки): большая польза, большая стоимость. Требуют тщательного планирования.
- Maybes (Возможно): небольшая польза, низкая стоимость. Можно сделать, когда есть свободные ресурсы.
- Time Sinks (Пожиратели времени): небольшая польза, высокая стоимость. Избегать.
Плюсы: Очень наглядно, быстро, не требует сложных расчетов.
Минусы: Субъективен. «Ценность» и «Усилия» как правило определяются на глазок.
Когда использовать: Для первоначальной, грубой сортировки большого количества гипотез или в условиях крайней неопределенности.
2. RICE
RICE — один из самых популярных фреймворков для приоритизации гипотез, потому что он заставляет думать о ключевых факторах количественно.
Формула: RICE Score = (Reach × Impact × Confidence) / Effort
- Reach (Охват) – сколько пользователей затронет гипотеза за определенный период? Измеряется в количестве людей/событий в месяц. Пример: 5000 пользователей в месяц.
- Impact (Влияние) – насколько сильно гипотеза повлияет на каждого пользователя? Часто используется шкала от 0.25 (минимальное) до 3 (огромное), где 3 = Массивное влияние, 2 = Высокое, 1 = Среднее, 0.5 = Низкое, 0.25 = Минимальное.
- Confidence (Уверенность) – насколько вы уверены в своих оценках Reach и Impact? Выражается в процентах. 100% = Высокая уверенность (есть данные), 80% = Средняя, 50% = Низкая (только догадка).
- Effort (Усилия) – сложность реализации, сколько «человеко-месяцев» или «человеко-недель» потребует проверка гипотезы? Оценивается всей командой (продакт, дизайн, разработка). Пример: 2 человеко-месяца.
Пример расчета:
- Гипотеза: «Добавить ссылку на чат-поддержку в личный кабинет». (здесь даю сокращенную версию гипотезы, допустим, что она обоснована ранее)
- Reach: 10 000 пользователей/мес увидят ссылку.
- Impact: Оценим в 1 балл (среднее влияние, так как не все будут кликать).
- Confidence: 80% (есть данные из поддержки).
- Effort: 1 человеко-месяц.
- RICE Score = (10,000 × 1 × 0.8) / 1 = 8,000
Плюсы: Структурированный, количественный метод, снижает субъективность, учитывает уверенность.
Минусы: Требует больше времени на оценку, оценки все равно могут быть спекулятивными.
Когда использовать: Когда у вас есть достаточно данных для хотя бы примерной количественной оценки, и вы хотите минимизировать влияние личных мнений. Можно использовать на финальной стадии, когда есть уже несколько отобранных ранее гипотез (в сочетании с Value vs Effort, например)
3. ICE (упрощенная версия RICE)
Формула: ICE Score = Impact × Confidence × Ease
- Impact (Влияние) – насколько гипотеза повлияет на ключевую метрику? (Шкала 1-10).
- Confidence (Уверенность) – насколько вы уверены в успехе? (Шкала 1-10).
- Ease (Легкость) – насколько легко/быстро проверить? (Шкала 1-10, где 10 — очень легко).
Плюсы: Очень быстрый, прост для понимания.
Минусы: Еще более субъективен, чем RICE. «Ease» — менее точная метрика, чем «Effort».
Когда использовать: Для первоначального, быстрого ранжирования гипотез, когда нет времени на детальные оценки RICE.
4. MoSCoW
Гипотезы распределяются по четырем категориям:
- MUST (Должны быть) – критически важно
- SHOULD (Стоило бы) – важны, но не критичны. Сильно влияют на ценность, но релиз возможен и без них.
- COULD (Могли бы) – желательны, но не существенны. Делаются, если останутся ресурсы.
- WON'T (Не будут) –не входят в текущий цикл.
Плюсы: Отлично подходит для коммуникации с бизнесом, синхронизации с ожиданиями стейкхолдеров и управления ими.
Минусы: Часто приводит к тому, что в категорию «MUST» попадает слишком много гипотез.
Когда использовать: В основном для планирования спринтов или крупных релизов, когда нужно четко обозначить scope для стейкхолдеров.
Совет: Не бойтесь экспериментировать. Вы можете использовать один из популярных методов скоринга гипотез, миксовать их или разработать собственную систему. Нет смысла использовать фреймворк ради фреймворка, сохраняйте гибкость. Учитывайте ваш контекст и масштабы.
Типичные ошибки при приоритизации
- HiPPO (Highest Paid Person's Opinion) – решение принимает тот, у кого самая высокая должность, а не данные.
- Шумиха (Hype-driven Development)ь – «А вот у конкурентов есть!» или «Это сейчас в тренде!» без оценки реальной ценности для ваших пользователей.
- Ошибка «это же всего 5 минут» – маленькие, бессмысленные задачи и “улучшения” постоянно пробиваются в работу, фрагментируя внимание команды и не принося реальной ценности.
- Аналитический паралич или перфекционизм в оценке – команда зацикливается на идеальной системе оценок и бесконечно уточняет баллы, вместо того чтобы запустить эксперимент и получить реальные данные. Методы оценки гипотез должны помочь вам в принятии решений, а не стать самоценностью и отдельным проектом.
- Отсутствие пересмотра – приоритеты, установленные раз в квартал, устаревают. Бэклог гипотез и приоритеты должны пересматриваться регулярно (например, раз в 2 недели).
Ключевой вывод: Приоритизация — это не поиск единственно верного ответа, а создание прозрачного и обоснованного процесса принятия решений. Лучшая гипотеза — не та, что набрала самый высокий балл, а та, проверка которой быстрее всего научит вас чему-то важному о ваших пользователях и вашем продукте.
В следующей статье разберем простой и мощный метод для тестирования продуктовых гипотез и непрерывного улучшения продукта на основе данных:
Это финальная статья из цикла материалов про базу по работе с гипотезами, который я готовила для внутреннего обучения команды продактов OTUS. Ранее я писала про продуктовое мышление, генерацию сильных продуктовых гипотез и популярные фреймворки для оценки и приоритизации гипотез . Здесь разберемся, как это все работает вместе в итеративном цикле ра…
Буду рада вопросам, комментариям и конструктивной критике!
Про автора:
Я Даша, product manager в онлайн-школе дизайна Contented с неплохим таким бэкграундом в web dev, маркетинге, FinTech и EdTech проектах. Обожаю тему growth hacking'а, CRO и оптимизации UX/CX.