TL;DR
- ICE и RICE нужны, чтобы команда выбирала гипотезы не по громкости голоса, а по ожидаемому эффекту, уверенности и затратам.
- ICE быстрее: Impact, Confidence, Ease. Подходит для недельных growth-спринтов и маркетинговых тестов.
- RICE точнее: Reach, Impact, Confidence, Effort. Подходит для продуктового roadmap и задач, где важен охват.
- Скоринг не дает абсолютной истины. Он помогает структурировать спор и быстро выбрать следующий тест.
- Главная ловушка - подгонять баллы под любимую идею. Поэтому правила оценки должны быть понятны до обсуждения.
Зачем нужна приоритизация
У growth-команды всегда больше идей, чем времени. Переписать лендинг, поменять цену, добавить квиз, запустить email-цепочку, подключить ретаргетинг, сделать реферальную механику, передать офлайн-конверсии, поменять скрипт продаж - все звучит полезно. Но команда не может делать все сразу.
Если приоритизации нет, решения принимаются по статусу, интуиции или срочности. Побеждает идея руководителя, последняя жалоба клиента или самый красивый дизайн. ICE и RICE не убирают экспертность, но заставляют ее разложить на понятные компоненты.
ICE: быстрый скоринг для роста
ICE состоит из трех оценок:
- Impact: насколько сильно идея может повлиять на целевую метрику.
- Confidence: насколько мы уверены, что эффект действительно будет.
- Ease: насколько быстро и дешево это проверить.
Формула обычно простая:
ICE = (Impact + Confidence + Ease) / 3
Оценивайте по шкале от 1 до 10. Например, "заменить заголовок на первом экране" может иметь Impact 6, Confidence 7, Ease 9. Средний ICE = 7,3. "Пересобрать личный кабинет" может иметь Impact 9, Confidence 4, Ease 2. Средний ICE = 5. В коротком growth-спринте первый тест почти всегда разумнее.
RICE: когда важен охват
RICE добавляет Reach - сколько пользователей или сделок затронет изменение. Формула:
RICE = (Reach * Impact * Confidence) / Effort
Она полезна, когда идеи сильно отличаются по охвату. Например, улучшение onboarding может затронуть всех новых пользователей, а новая интеграция - только маленький B2B-сегмент. Иногда маленькая идея с широким reach выигрывает у большой, но нишевой задачи.
Как не обмануть себя баллами
Скоринг легко превратить в театр. Команда сначала выбирает любимую идею, а потом ставит ей высокие баллы. Чтобы этого не было, договоритесь о правилах.
Impact должен быть привязан к метрике. Не "кажется важно", а "может поднять CR в заявку", "может снизить churn", "может увеличить оплату в первые 24 часа". Confidence должен опираться на данные: аналитика, интервью, повторяющиеся жалобы, результаты похожих тестов, конкурентные паттерны. Ease или Effort должны учитывать все затраты: дизайн, разработку, аналитику, legal, согласования, поддержку.
Полезная практика - калибровать оценки после теста. Если команда постоянно ставит Confidence 8, а подтверждаются 2 гипотезы из 10, значит шкала уверенности завышена.
Пример для локального бизнеса
У образовательного проекта есть 4 идеи:
| Гипотеза | Impact | Confidence | Ease | ICE |
|---|---|---|---|---|
| Вынести рассрочку в первый экран | 7 | 8 | 9 | 8.0 |
| Сделать квиз вместо формы | 8 | 6 | 5 | 6.3 |
| Запустить реферальную программу | 9 | 4 | 4 | 5.7 |
| Пересобрать личный кабинет | 9 | 3 | 2 | 4.7 |
Самая "большая" идея - личный кабинет. Но ближайший тест - рассрочка на первом экране. Он быстрее, дешевле и основан на частом возражении пользователей. Это не значит, что кабинет не нужен. Это значит, что он не должен съесть спринт, пока есть более дешевые проверки.
Как внедрить процесс
- Соберите backlog в одном месте: Notion, Airtable, Google Sheets, Linear, Jira - инструмент не важен.
- Каждая гипотеза должна иметь owner, целевую метрику и краткое объяснение причины.
- Раз в неделю проводите скоринг. Не дольше 45-60 минут.
- Выбирайте ограниченное количество тестов. Лучше 3 доведенных эксперимента, чем 12 незакрытых.
- После завершения обновляйте Confidence-память команды: что подтвердилось, что нет, какие сегменты сработали.
- Не бойтесь вручную переупорядочить список, если есть стратегическая причина. Но причину нужно записать.
Частые ошибки
Первая ошибка - сравнивать сырые идеи. "Улучшить retention" нельзя оценить. "Добавить напоминание в WhatsApp на D2 для тех, кто не завершил урок" уже можно.
Вторая ошибка - оценивать effort только разработкой. Иногда самое дорогое - не код, а контент, согласование с юристами, поддержка или риск сломать продажи.
Третья ошибка - ставить все гипотезы на одну доску без стратегии. Скоринг должен работать внутри выбранной цели. Если цель месяца - activation, не надо сравнивать onboarding-тесты с идеями для PR.
Видео
Что почитать в первоисточниках
- Intercom: RICE prioritization framework
- Growth Method: ICE Framework
Главный совет
Скоринг нужен не для того, чтобы доказать правоту. Он нужен, чтобы команда быстрее договорилась, что проверить следующим, и дешевле ошиблась.