Фреймворки приоритизации на собесе продакт-менеджера
Зачем PM фреймворки приоритизации
Главная проблема PM — не недостаток идей, а излишек. Команда видит 30 фич, которые «хорошо бы сделать». Времени и инженеров хватит на 3. Кого выбрать? Фреймворк приоритизации — структурированный способ ответить.
На собесе продакт-менеджера фреймворки приходят в двух форматах: (а) как часть кейса — «у тебя 10 фич в бэклоге, как приоритизируешь»; (б) как теоретический вопрос — «расскажи про RICE и когда его применять». Важно: интервьюер ценит не названия, а понимание, когда фреймворк подходит, а когда нет.
Главные фреймворки
RICE
Reach × Impact × Confidence / Effort.
- Reach — сколько юзеров затрагивает фича за период (квартал)
- Impact — насколько сильно повлияет на ключевую метрику (1 = минимум, 3 = максимум, или шкала 0.25 / 0.5 / 1 / 2 / 3)
- Confidence — уверенность в оценках (100% / 80% / 50%)
- Effort — трудозатраты в person-months
Подходит для: большого бэклога с разнородными фичами. Требует количественной оценки — поэтому надо иметь хоть какие-то данные. Не подходит, когда нет понимания reach и impact.
Подробнее — RICE для PM.
ICE
Impact × Confidence × Ease.
Упрощённая версия RICE. Подходит для быстрого ранжирования внутри команды. Каждый параметр — 1-10. Финальный score = произведение.
Подходит для: маленьких бэклогов, hackathon-сессий, быстрой приоритизации идей. Subjective оценки — это и плюс (быстро), и минус (можно манипулировать).
Подробнее — ICE-фреймворк для PM.
MoSCoW
Must / Should / Could / Won't.
- Must — обязательные требования (release blocker)
- Should — важные, но не критичные
- Could — желательно
- Won't — не в этом релизе
Подходит для: фиксированного дедлайна и понимания скоупа MVP. Помогает структурировать переговоры с stakeholder-ами: «вот must, остальное — should/could, давайте обсуждать».
Kano-модель
Классифицирует фичи по влиянию на удовлетворение пользователя:
- Basic (must-have) — обязательные, отсутствие злит, наличие воспринимается как должное
- Performance — линейная зависимость: больше = лучше
- Delighters — неожиданные, повышают удовлетворение нелинейно
Подходит для: понимания, какие фичи решают «гигиену», а какие создают «вау». На собесе помогает объяснить, почему не все фичи равноценны.
Подробнее — Kano-модель для PM.
Eisenhower matrix
Срочно/важно vs не срочно/не важно. Четыре квадранта.
Подходит для: личной приоритизации задач PM (не продуктовых фич). Не для бэклога — для собственного календаря.
Как выбрать фреймворк под ситуацию
| Ситуация | Подходит |
|---|---|
| Большой бэклог 30+ фич, разные impact | RICE |
| Команда генерит 10 идей, нужно быстро ранжировать | ICE |
| Релиз через 6 недель, надо решить MVP | MoSCoW |
| Не понимаем, какая ценность для пользователя | Kano |
| Спрашивают «как ты планируешь свою неделю» | Eisenhower |
На собесе будут давать пограничные ситуации. Например: «у тебя 20 фич, релиз через 3 месяца, команда новая». Здесь подойдут RICE (для оценки фич) + MoSCoW (для скоупа MVP) одновременно.
Шаблон ответа на собесе
Вопрос: «Как ты приоритизируешь бэклог?»
Слабый ответ: «Использую RICE». Точка.
Сильный ответ:
- «Зависит от ситуации, но базово опираюсь на RICE для среднего бэклога».
- «Сначала уточняю контекст: какая цель команды на квартал, есть ли фиксированные дедлайны, какие фичи уже даны как обязательные».
- «Для каждой фичи в бэклоге собираю reach (по аналитике или прикидке), impact (через данные A/B или мнения экспертов), confidence (если данных мало — снижаю), effort (с инженером)».
- «Считаю RICE-score, ранжирую. Топ-5 ставлю в roadmap».
- «Обсуждаю с командой: иногда subjective ranking важнее формального score — особенно для делайтер-фичей по Kano».
- «Раз в месяц пересматриваю — данные меняются, оценки обновляются».
Частые ошибки
Применять один фреймворк ко всему. RICE для всего — упрощение. Для MVP-релиза нужен MoSCoW, для делайтеров — Kano.
Зубрить названия без понимания. «Я использую RICE». «Почему не ICE?» Должен быть ответ с trade-off-ами.
Игнорировать confidence. RICE-score без честной оценки confidence легко манипулируется в пользу любимых фичей.
Применять формально без здравого смысла. Если фича по RICE-score 0.5, но необходима по compliance — она в must независимо от score.
Не обсуждать с командой. PM не считает score в вакууме. Дизайнер и инженеры влияют на impact и effort.
Шаблон оценки одной фичи (для practice)
| Параметр | Значение | Обоснование |
|---|---|---|
| Reach | 30000 юзеров в квартал | По данным около 25% активных юзеров |
| Impact | 1.5 | По экспертной оценке — средний эффект на conversion |
| Confidence | 80% | Есть данные предыдущего A/B аналогичной фичи |
| Effort | 6 person-weeks | По оценке инженерного руководителя |
| RICE | 30000 × 1.5 × 0.8 / 6 = 6000 |
Сравнивай только RICE-score между фичами одного roadmap-цикла.
FAQ
Какой фреймворк универсальный?
Универсального нет. RICE — самый гибкий для больших бэклогов. ICE — самый быстрый. Kano — лучший для понимания ценности. MoSCoW — для дедлайнов.
Что если данных для RICE нет?
Используй ICE (более subjective, не нужны точные данные). Или собирай данные итеративно: первый RICE — на прикидках, после A/B — обновляешь.
Можно ли комбинировать фреймворки?
Да. Часто RICE + Kano: RICE для общего ранжирования, Kano для понимания, какие фичи попадают в «делайтеры» и нужны несмотря на низкий RICE.
Как презентовать RICE stakeholder-ам?
Показывай не финальные числа, а логику. «Эта фича выше потому что reach 30K, а у этой 5K». Числа без логики — манипуляция.
Что важнее на собесе — название фреймворка или логика выбора?
Логика выбора. «Применяю RICE» — слабо. «В этой ситуации применил бы RICE, потому что [причины]» — сильно.