Как продакту приоритизировать решения: есть ли что-то кроме RICE?

Коротко
RICE — неплохой инструмент, но только для одного уровня решений: выбрать из нескольких идей под одну цель. В сильных продуктовых компаниях бэклог по баллам RICE не сортируют. Сначала решают, куда идти на уровне стратегии, а потом — какую проблему пользователя решать, и только потом сравнивают идеи. На каждом уровне свои инструменты.
Почему одного RICE мало
Что такое RICE
RICE придумал Шон Макбрайд в Intercom. Каждую идею оценивают по четырём параметрам:
| Параметр | Что значит | Как оценивают |
|---|---|---|
| Reach | Сколько людей затронет за период | Например, клиентов в квартал. Лучше из реальных данных |
| Impact | Насколько сильно повлияет на каждого | Шкала: 3 — огромное, 2 — высокое, 1 — среднее, 0,5 — низкое, 0,25 — минимальное |
| Confidence | Насколько мы уверены в оценках | 100% — высокая, 80% — средняя, 50% — низкая. Ниже 50% — «полная авантюра» |
| Effort | Сколько работы | Человеко-месяцы продакта, дизайна и разработки |
Балл = Reach × Impact × Confidence / Effort
Пример. Фильтр по рейтингу в каталоге: затронет 40 000 пользователей в квартал, влияние среднее (1), уверенность 80%, работы на 2 человеко-месяца. Балл: 40 000 × 1 × 0,8 / 2 = 16 000.
Где RICE ломается
Сам Макбрайд предупреждает, что RICE — не жёсткое правило: проект с низким баллом может идти первым, если от него зависят другие или без него не продать продукт ключевым клиентам. На практике проблем больше.
1. Impact почти всегда угадывают. В Microsoft лишь около трети хорошо спроектированных экспериментов улучшали целевую метрику. Остальные не давали эффекта или вредили. В Bing доля успешных была ещё ниже. Если две трети идей не работают, то оценка «влияние высокое» в среднем ошибочна.
2. Confidence ставят на глаз. Обычно это «ну, я где-то на 80% уверен». Итамар Гилад, бывший продакт Google, называет такие числа взятыми «из воздуха».
3. Перемножение даёт ложную точность. Балл 16 000 выглядит как факт, но это произведение четырёх догадок. Чуть другая оценка Impact — и середина списка перемешивается.
4. RICE любит мелочь. Маленький Effort в знаменателе раздувает балл. В итоге команда делает десятки мелких улучшений и не берётся за то, что меняет продукт.
5. RICE не видит стратегию. Он сравнивает идеи между собой, но не отвечает, зачем нам вообще эта цель. Идея с отличным баллом может работать на метрику, которая сейчас не главная.
6. RICE не учитывает время. Фича под сезон или регуляторку, которая через три месяца станет бесполезной, получит тот же балл, что и фича, которую можно сделать когда угодно.
Главная мысль: приоритизация — это не формула, а умение говорить «нет». Формула помогает сравнить варианты, но решение принимает команда.
Приоритизация на четырёх уровнях
Почти вся путаница с фреймворками возникает из-за того, что их применяют не на том уровне. Удобно делить решения так:
| Уровень | Вопрос | Горизонт | Инструменты |
|---|---|---|---|
| 1. Стратегия | Куда играем, какая цель главная | Год, полгода | DHM и GEM (Netflix), Working Backwards и OP1 (Amazon), OKR (Google), ставки DIBB (Spotify) |
| 2. Проблемы | Какую боль пользователя решаем | Квартал | Дерево возможностей, Opportunity Scoring, модель Кано |
| 3. Решения | Какую идею делаем первой | Недели, спринты | RICE, ICE + шкала уверенности, Cost of Delay, ценность / сложность, MoSCoW |
| 4. Свои дела | На что продакт тратит время | День, неделя | LNO, мышление через упущенную выгоду, обратимость решений |
Дальше — по уровням.
Уровень 1. Стратегия: куда играем
Netflix: DHM и GEM
Гибсон Биддл, бывший VP of Product в Netflix, описывает продуктовую стратегию как набор гипотез о том, как радовать клиентов (Delight) способами, которые сложно скопировать (Hard to copy) и которые улучшают маржу (Margin-enhancing). Это модель DHM. Идея, которая не попадает ни в один из трёх пунктов, — первый кандидат на «нет».
Для приоритизации Биддл использует GEM: Growth, Engagement, Monetization — рост, вовлечённость, монетизация. Команда жёстко ранжирует три направления: что сейчас первое, второе, третье. Когда появился Disney+, Netflix пересматривал этот порядок и оставил рост на первом месте.
Ещё одна идея Netflix — прокси-метрики. Главная метрика вовлечённости, удержание, меняется медленно. Поэтому под каждую стратегию выбирают быструю прокси-метрику, которую можно двигать в тестах. Биддл признаётся, что споры о правильной прокси-метрике иногда шли от трёх до девяти месяцев: ошибка здесь дорогая.
Что взять себе: перед тем как считать RICE, назови, какая из трёх целей — рост, вовлечённость или деньги — сейчас главная. Идеи под второстепенную цель не сравнивай с идеями под главную.
Amazon: OP1 и Working Backwards
Дважды в год каждая команда Amazon пишет шестистраничный документ — OP1 летом и OP2 зимой. В OP1 команда отвечает: что сделали относительно плана, каких результатов достигнем при тех же ресурсах и что нужно, чтобы вырасти в 10 раз. Документы сводятся вверх по уровням, руководство распределяет ресурсы. По итогам команда может получить полное финансирование — или быть расформирована.
Отдельные инициативы проходят через Working Backwards: до разработки пишут пресс-релиз и FAQ (PR/FAQ) так, будто продукт уже запущен. Если не получается внятно объяснить, зачем это клиенту, идею отсекают ещё на бумаге — это самая дешёвая приоритизация.
Что взять себе: прежде чем ставить идею в бэклог, напиши один абзац «пресс-релиза» для пользователя. Если абзац не пишется, проблема не в приоритете, а в идее.
Google: OKR с двумя типами целей
В Google цели делят на два типа:
- Обязательные — их нужно выполнить на 100%. Это фундамент: стабильность, регуляторка, обещания клиентам.
- Амбициозные — заведомо сложные, выполнение на 70% считается хорошим результатом.
Это помогает приоритизировать: сначала ресурсы на обязательное, потом — на амбициозное. И никто не путает «не успели амбициозную цель» с провалом.
Spotify: DIBB и доска ставок
В Spotify инициативы оформляли через цепочку Data → Insight → Belief → Bet: данные → вывод из них → убеждение (гипотеза) → ставка (что делаем и как поймём, что сработало). Крупные ставки компании висели на общей канбан-доске, и это заставляло выбирать: всё сразу на доску не помещается. Любой сотрудник мог оспорить ставку, если приносил новые данные.
Сам формат хорош тем, что отделяет факты от веры. В обсуждении сразу видно, где у нас данные, а где — убеждение, которое ещё нужно проверить.
Уровень 2. Проблемы: какую боль решаем
Дерево возможностей
Тереза Торрес предлагает строить дерево возможностей и решений (Opportunity Solution Tree):
Цель продукта (метрика)
├── Возможность А: «не могу найти нужный товар»
│ ├── Решение 1: фильтр по рейтингу
│ └── Решение 2: умный поиск
└── Возможность Б: «боюсь, что товар окажется плохим»
├── Решение 3: отзывы с фото
└── Решение 4: бесплатный возврат
Ключевая идея: сначала выбирают возможность, потом решение. Сравнивать «фильтр по рейтингу» и «бесплатный возврат» в одном списке — ошибка: они решают разные проблемы. Сначала решаем, какая боль сейчас важнее, а уже внутри неё сравниваем решения.
Возможности берут из регулярных интервью с пользователями, а не из головы.
Opportunity Scoring
Метод Тони Ульвика. Пользователей просят оценить по 10-балльной шкале две вещи для каждой задачи: насколько она важна и насколько они довольны тем, как она решается сейчас.
Возможность = важность + max(важность − удовлетворённость, 0)
Важная и плохо решённая задача получает высокий балл. Важная, но уже хорошо решённая — низкий: там вкладываться бессмысленно.
Пример: «понять, сколько стоит доставка» — важность 9, удовлетворённость 4. Балл: 9 + 5 = 14. Это сильная возможность.
Модель Кано
Делит свойства продукта на типы:
| Тип | Пример для доставки | Что делать |
|---|---|---|
| Базовые — без них недовольны, с ними не рады | Заказ приезжает целым | Обязательно сделать, но не переинвестировать |
| Линейные — чем больше, тем лучше | Скорость доставки | Улучшать, пока окупается |
| Восторг — не ждут, но радуются | Курьер оставил открытку | Отличие от конкурентов |
| Безразличные | Анимация на экране оплаты | Не делать |
Кано полезен, чтобы не тратить квартал на «восторги», когда сломана база. Важно: восторги со временем становятся базой — то, что удивляло три года назад, сегодня ожидают по умолчанию.
Уровень 3. Решения: что делаем первым
Здесь RICE на своём месте. Но у него есть альтернативы и важные дополнения.
ICE и шкала уверенности
ICE (Impact, Confidence, Ease) — упрощённый RICE, его популяризировал Шон Эллис для гроус-команд. Каждый параметр — от 1 до 10, баллы перемножают или складывают. Быстро и подходит для десятков гроус-гипотез в неделю.
Главная слабость ICE и RICE — Confidence. Итамар Гилад, долго работавший продактом в Google, предложил шкалу уверенности (Confidence Meter): уверенность зависит не от ощущения, а от типа доказательств.
| Что есть | Уверенность |
|---|---|
| Собственное мнение, «это тренд», мнение коллег, голос самого высокооплачиваемого в комнате | Почти ноль |
| Пара клиентов просили | Низкая |
| Проверили оценки и план с разработкой | Немного выше |
| Рыночные данные, опрос | Средняя |
| Тест прототипа, интервью | Выше средней |
| Реальное использование MVP, результаты A/B-теста | Высокая |
Гилад показывает, что идея может упасть по уверенности после MVP: в его примере у чат-бота уверенность выросла после опроса, а потом резко упала, когда им почти не стали пользоваться.
Что взять себе: когда ставишь Confidence, называй доказательство, а не процент. «80%, потому что 6 из 8 человек на юзабилити-тесте нашли фильтр» звучит совсем иначе, чем «80%, потому что я так чувствую».
Cost of Delay и CD3
Метод из лин-разработки (Дон Рейнертсен, Black Swan Farming). Вместо абстрактного Impact считают стоимость задержки — сколько денег мы теряем каждую неделю, пока фича не запущена.
CD3 = стоимость задержки / длительность
Пример:
| Фича | Теряем в неделю | Делать | CD3 |
|---|---|---|---|
| А | 1 млн ₽ | 4 недели | 0,25 |
| Б | 300 тыс. ₽ | 1 неделя | 0,3 |
| В | 2 млн ₽ | 10 недель | 0,2 |
Порядок: Б → А → В. Короткую фичу с хорошей отдачей выгоднее сделать первой — она начнёт приносить деньги, пока делаются остальные.
Метод особенно хорош там, где у ценности есть срок годности: сезон, требования регулятора, окно перед запуском конкурента. В фреймворке SAFe его упрощённая версия называется WSJF (Weighted Shortest Job First).
Компания Maersk Line применила Cost of Delay на портфеле в 100 млн долларов: главный эффект был не в формуле, а в том, что экономические компромиссы стали видны всем участникам решения.
Ценность / сложность
Матрица 2×2: ценность по вертикали, сложность по горизонтали.
| Простое | Сложное | |
|---|---|---|
| Ценное | Быстрые победы — делать сейчас | Крупные ставки — планировать |
| Неценное | Мелочи — делать, если есть время | Ловушки — не делать |
Хороша для воркшопа с командой за 30 минут. Плоха как единственный инструмент: «ценность» в ней обычно не объяснена.
MoSCoW
Must have, Should have, Could have, Won't have. Метод не для выбора между идеями, а для нарезки скоупа одной фичи или релиза: что обязательно в первой версии, а что пойдёт потом. Главная ценность — категория Won't: она фиксирует, от чего отказались.
Ловушка: всё быстро становится Must. Правило: Must — это то, без чего релиз не имеет смысла или нарушает закон.
Уровень 4. Свои дела: на что тратит время продакт
LNO
Шрейас Доши, бывший продакт Stripe, Twitter и Google, делит задачи продакта на три типа:
- Leverage — рычаг, задачи, которые дают десятикратный эффект: стратегия, ключевое решение, важный документ. Сюда — максимум сил.
- Neutral — нейтральные, нужно сделать нормально, но без перфекционизма.
- Overhead — накладные: координация, оформление, статусы. Сделать как получится, а лучше — устранить.
Его совет: «Сознательно делай некоторые задачи плохо». Если всё делать идеально, на рычаги не останется времени.
Упущенная выгода вместо ROI
Ещё одна мысль Доши. Мышление через ROI спрашивает: «Окупится ли эта задача?» Маленькая задача почти всегда окупается — и ты двигаешься по сантиметру. Мышление через упущенную выгоду спрашивает: «Это лучшее, на что сейчас можно потратить время?» Оно заставляет искать варианты с гораздо большей отдачей.
Это прямой ответ на проблему RICE с мелочью: высокий балл у маленькой задачи не значит, что её нужно делать.
Обратимые и необратимые решения
Джефф Безос в письме акционерам Amazon за 2015 год разделил решения на два типа:
- Необратимые («дверь в одну сторону») — их принимают методично, медленно, с консультациями.
- Обратимые («дверь в обе стороны») — их большинство, и их должны быстро принимать отдельные люди или небольшие группы.
В письме за 2016 год он добавил: большинство решений стоит принимать, когда есть примерно 70% нужной информации.
Что взять себе: перед приоритизацией спроси, обратимо ли решение. Обратимое — не нужно трёх недель обсуждений и идеального RICE, проще запустить A/B-тест. Необратимое — смену цены, миграцию, отказ от рынка — разбирай подробно.
Как это выглядит в бигтехах на самом деле
Если обобщить практики Amazon, Google, Netflix, Microsoft, Spotify и Figma, видны общие черты:
| Принцип | Как это проявляется |
|---|---|
| Сначала стратегия, потом бэклог | Netflix ранжирует рост, вовлечённость и деньги. Amazon распределяет ресурсы через OP1 |
| Цель задаёт руководство, путь — команда | Figma: лидеры раз в год задают приоритеты компании, команды сами выбирают, как к ним идти |
| Решения — это ставки, а не обещания | Spotify: Data → Insight → Belief → Bet. Ставку можно оспорить новыми данными |
| Доказательства важнее мнений | Microsoft: большинство идей не работает, поэтому проверяют тестами. Гилад: уверенность растёт только от доказательств |
| Дешёвая проверка до дорогой разработки | Amazon: PR/FAQ на бумаге. Прототипы и MVP до полной реализации |
| Скорость зависит от обратимости | Amazon: обратимые решения принимаются быстро и небольшими группами |
| Фокус — значит говорить «нет» | Ограниченная доска ставок у Spotify. Жёсткое ранжирование вместо списка из десяти «высоких приоритетов» |
| Пересмотр по ритму | Figma: год, полгода и корректировка в середине. Amazon: OP1 и OP2 |
Ни в одном из этих примеров нет «отсортировали бэклог по RICE и пошли делать». Формулы используют внутри одной цели — чтобы сравнить конкретные решения и объяснить выбор стейкхолдерам.
Практический процесс: от цели до бэклога
- Зафиксируй одну главную цель на период. Например: «растим конверсию в первый заказ». Не три цели с равным весом, а одну главную.
- Собери проблемы пользователей, которые мешают этой цели: интервью, аналитика воронки, обращения в поддержку.
- Выбери одну-две главные проблемы. Помогут Opportunity Scoring или размер потерь в воронке: где больше всего людей отваливается и почему.
- Придумай несколько решений на каждую проблему. Не одно — минимум три, чтобы было из чего выбирать.
- Оцени решения грубо. RICE или ICE, но Confidence — по типу доказательства. Если у ценности есть срок — добавь стоимость задержки.
- Раздели по обратимости. Обратимое и дешёвое — сразу в тест. Необратимое и дорогое — сначала дешёвая проверка: прототип, фейковая дверь, ручной сервис вместо автоматизации.
- Обсуди с командой и жёстко ранжируй. Без ничьих: первое, второе, третье. Баллы — повод для разговора, а не замена ему.
- Зафиксируй, от чего отказались и почему. Это экономит месяцы на повторных спорах.
- Пересматривай по расписанию. Раз в квартал — проблемы, раз в спринт — решения. И сразу после каждого значимого результата теста.
Типичные ошибки
| Ошибка | Как правильно |
|---|---|
| Сравнивать в одном списке идеи под разные цели | Сначала выбрать цель, потом сравнивать идеи внутри неё |
| Сравнивать решения разных проблем | Сначала выбрать проблему, потом решение |
| Ставить Confidence «на ощущение» | Называть доказательство: опрос, прототип, тест |
| Верить баллу как факту | Баллы — для обсуждения. Разница в 10% ничего не значит |
| Набрать мелочей с высоким баллом | Спрашивать: это лучший вариант использования времени? |
| Обсуждать неделями обратимое решение | Запустить тест: он дешевле обсуждения |
| Десять задач с приоритетом «высокий» | Жёсткое ранжирование: одно первое, одно второе |
| Делать то, что попросил самый громкий стейкхолдер | Показать, как его запрос соотносится с целью и другими идеями |
| Не пересматривать приоритеты | Пересматривать по ритму и после новых данных |
Как отвечать на собеседовании
На вопрос «Как ты приоритизируешь?» слабый ответ — «по RICE». Сильный показывает уровни:
«Начинаю не с бэклога, а с цели. Сначала договариваемся, какая метрика сейчас главная — рост, вовлечённость или деньги. Дальше смотрю, какие проблемы пользователей больше всего мешают этой цели: по воронке, интервью, обращениям в поддержку. Выбираю одну-две.
Под каждую проблему накидываем несколько решений и оцениваем грубо — по RICE или ICE. Но уверенность ставлю по доказательствам: мнение команды — низкая, тест прототипа — выше, результат A/B — высокая. Если у фичи есть срок годности, добавляю стоимость задержки.
Дальше смотрю на обратимость: дешёвое и обратимое сразу отправляю в A/B, дорогое и необратимое сначала проверяю дёшево. И в конце жёстко ранжирую вместе с командой: баллы — повод для разговора, а не решение. Обязательно фиксирую, от чего отказались и почему».
Если просят пример — назови одну реальную историю, где ты отказался от идеи с высоким баллом или громким заказчиком, и объясни, почему. Это сильнее любого фреймворка.
Шпаргалка
| Инструмент | Уровень | Когда брать | Главный минус |
|---|---|---|---|
| DHM | Стратегия | Проверить, ведёт ли идея к стратегии | Абстрактен без метрик |
| GEM | Стратегия | Выбрать главную цель на период | Требует жёсткого решения руководства |
| PR/FAQ | Стратегия, крупные идеи | Отсеять идею до разработки | Долго для мелких задач |
| OKR | Стратегия | Задать цели и отделить обязательное от амбициозного | Превращается в бюрократию |
| DIBB | Стратегия | Оформить ставку и отделить факты от гипотез | Нужна культура, где можно спорить |
| Дерево возможностей | Проблемы | Выбрать проблему, а потом решение | Нужны регулярные интервью |
| Opportunity Scoring | Проблемы | Найти важные и плохо решённые задачи | Нужен опрос, качество зависит от вопросов |
| Кано | Проблемы | Отличить базу от восторгов | Категории меняются со временем |
| RICE | Решения | Сравнить идеи под одну цель | Догадки в Impact и Confidence, любит мелочь |
| ICE + шкала уверенности | Решения | Быстро разобрать много гроус-гипотез | Грубая оценка |
| Cost of Delay / CD3 | Решения | У ценности есть срок | Сложно оценить потери в деньгах |
| Ценность / сложность | Решения | Быстрый воркшоп с командой | Ценность не объяснена |
| MoSCoW | Скоуп | Нарезать первую версию | Всё становится Must |
| LNO | Свои дела | Распределить время продакта | Субъективно |
| Одно- и двусторонние двери | Любой | Решить, сколько времени тратить на решение | Не говорит, что именно выбрать |
Источники
- Intercom — RICE: Simple prioritization for product managers
- Gibson Biddle — Intro to Product Strategy
- INMA — Netflix exec gives 4 frameworks for product success (DHM, GEM, SMT)
- Lenny's Newsletter — Gibson Biddle on the DHM product strategy
- Itamar Gilad — The tool that will help you choose better product ideas (Confidence Meter)
- Mind the Product — From opinion-based to evidence-guided product development, Itamar Gilad
- Black Swan Farming — Cost of Delay
- Black Swan Farming — WSJF
- Black Swan Farming — Experience report: Maersk Line
- Farnam Street — Reversible and irreversible decisions (Bezos)
- NOBL — What we can learn from Amazon's planning process (OP1/OP2)
- Model Thinkers — Amazon's Working Backwards
- whatmatters.com — Google's OKR Playbook
- Model Thinkers — Spotify DIBB framework
- Lenny's Newsletter — How Figma builds product
- Aakash Gupta — LNO framework for product managers
- Shreyas Doshi — ROI vs opportunity cost thinking (thread)
- Lenny's Podcast — Shreyas Doshi
- Jens-Fabian Goetzmann — The problem with prioritization frameworks
- Kohavi et al. — success rate of experiments at Microsoft (обзор)
- Bing Blogs — Large Scale Experimentation at Bing
- Mind the Product — Critical thinking for product teams, Teresa Torres
Застрял на этом этапе?
Разберём резюме, собес или стратегию поиска один на один.
