Impact × Frequency Matrix: метод AI-приоритизации, который заменил споры на sprint planning
Что такое Impact × Frequency Matrix?
Impact × Frequency Matrix — это фреймворк приоритизации продуктового backlog, который оценивает задачи по двум измеримым осям: насколько сильно фича влияет на целевую метрику (impact) и как часто пользователи сталкиваются с потребностью (frequency). Задачи распределяются по четырём квадрантам — Do First, Strategic, Quick Wins и Ignore — что даёт однозначные правила действий без субъективных дискуссий.
TL;DR
- -RICE, MoSCoW и WSJF не работают на практике, потому что все три метода опираются на субъективные экспертные оценки, а не на измеренные данные.
- -Матрица оценивает каждую задачу backlog по impact (ожидаемый прирост метрики) и frequency (доля затронутых пользователей) на основе аналитики продукта, support-тикетов и истории A/B-тестов.
- -AI заменяет planning poker: передайте LLM данные, и он вернёт оцененный, отсортированный backlog с квадрантами и уровнями уверенности.
- -Минимальный порог для полезного AI-скоринга — не менее двух источников данных на задачу; промпты с пустыми полями возвращают уверенно звучащий шум.
- -Через три месяца отслеживайте время на приоритизацию, точность предсказаний и velocity, чтобы подтвердить эффективность метода.
Продуктовые команды теряют много времени на sprint planning, споря о приоритетах. RICE, WSJF, MoSCoW генерируют субъективные оценки, которые зависят от громкости голоса участника, а не от данных. Эта проблема растёт снизу-вверх - когда PRD пишутся без измеримых критериев успеха, у спора о приоритетах нет якоря.
Impact × Frequency Matrix решает задачу иначе. Две оси: насколько сильно фича влияет на результат (impact) и как часто пользователи сталкиваются с проблемой или используют функциональность (frequency). AI оценивает оба параметра на основе данных, а не мнений. Результат — четыре квадранта с однозначными правилами действий.
Почему RICE и MoSCoW не работают на практике
RICE требует оценки четырёх параметров: Reach, Impact, Confidence, Effort. Три из четырёх субъективны. Impact оценивается по шкале 0.25–3, где разница между “medium” и “high” определяется интуицией оценивающего. Confidence превращается в способ продавить решение: уверен в своей фиче — ставь 100%, не уверен в чужой — 50%. (RICE-оценка с AI снижает этот bias за счёт подачи оценок из данных аналитики - но субъективность на границах остаётся.)
MoSCoW делит задачи на Must/Should/Could/Won’t. На практике большинство задач оказываются в Must, потому что каждый стейкхолдер считает свой запрос критичным. Фреймворк не даёт инструмента для разрешения конфликтов внутри категории.
WSJF (Weighted Shortest Job First) из SAFe использует “Cost of Delay” — параметр, который команды оценивают по шкале Фибоначчи на planning poker. Три человека показывают 8, два — 3, один — 21. Среднее арифметическое не делает оценку точнее.
Общая проблема: все три метода опираются на экспертные оценки без привязки к данным. Impact × Frequency Matrix заменяет мнения измерениями.
Две оси матрицы: что измеряем
Frequency: как часто возникает потребность
Frequency отвечает на вопрос: какой процент пользователей сталкивается с проблемой или использует функциональность в единицу времени?
Источники данных для Frequency:
- Аналитика продукта. Количество сессий, в которых пользователь выполняет действие или наталкивается на ограничение. Mixpanel, Amplitude, PostHog дают точные цифры.
- Support-тикеты. Количество обращений по теме за месяц. Zendesk, Intercom, Linear хранят историю.
- Поисковые запросы. Что пользователи ищут внутри продукта и не находят. Algolia, внутренний поиск.
- Опросы и интервью. Качественные данные для новых фич, у которых нет количественных метрик.
Шкала Frequency (1–10):
| Балл | Описание | Пример |
|---|---|---|
| 1–2 | Менее 1% пользователей в месяц | Экспорт данных в XML |
| 3–4 | 1–10% пользователей в месяц | Настройка кастомных уведомлений |
| 5–6 | 10–30% пользователей еженедельно | Фильтрация по дате в отчётах |
| 7–8 | 30–60% пользователей ежедневно | Поиск по каталогу |
| 9–10 | 60%+ пользователей в каждой сессии | Загрузка главного экрана |
Impact: насколько сильно влияет на результат
Impact измеряет, как сильно решение проблемы или добавление фичи сдвигает целевую метрику. Не “насколько это важно по ощущениям”, а “какой прирост метрики ожидаем”.
Источники данных для Impact:
- A/B-тесты аналогичных фич. Исторические данные о том, какой прирост давали похожие изменения. (Полный workflow A/B-теста - sample sizing, MDE, guardrail-метрики - в плейбуке экспериментов.)
- Конкурентный анализ. Если конкурент внедрил аналогичную функцию, какой эффект наблюдался (публичные данные, обзоры).
- Корреляционный анализ. Пользователи, у которых решена эта проблема, показывают retention на X% выше.
- Размер потерь. Сколько пользователей уходят из-за отсутствия фичи (churn-анализ).
Шкала Impact (1–10):
| Балл | Описание | Пример |
|---|---|---|
| 1–2 | Косметическое улучшение, <1% прирост метрики | Смена иконки |
| 3–4 | Заметное улучшение UX, 1–5% прирост | Автосохранение черновиков |
| 5–6 | Существенный прирост, 5–15% | Новый тип отчётов |
| 7–8 | Значительный прирост, 15–30% | Интеграция с ключевым сервисом |
| 9–10 | Трансформационный, 30%+ прирост | Новая модель монетизации |
Четыре квадранта: правила действий
High Impact (7-10)
│
┌────────────────┼────────────────┐
│ │ │
│ STRATEGIC │ DO FIRST │
│ │ │
│ Планировать │ Делать сейчас │
│ на следующий │ Максимальный │
│ квартал │ ROI │
│ │ │
Low ├────────────────┼────────────────┤ High
Freq │ │ │ Freq
(1-4) │ IGNORE │ QUICK WINS │ (5-10)
│ │ │
│ Отложить или │ Автоматизи- │
│ удалить из │ ровать, │
│ backlog │ делегировать │
│ │ │
└────────────────┼────────────────┘
│
Low Impact (1-6)
DO FIRST (High Impact + High Frequency). Задачи, затрагивающие большинство пользователей и сильно влияющие на метрики. Брать в текущий спринт. Не обсуждать, а начинать.
STRATEGIC (High Impact + Low Frequency). Влияние сильное, но сталкиваются немногие. Это крупные фичи для определённого сегмента или инфраструктурные задачи. Планировать на следующий квартал, разбивать на этапы.
QUICK WINS (Low Impact + High Frequency). Маленькие улучшения, с которыми встречается большинство пользователей. Каждое по отдельности даёт минимальный прирост, но в сумме они формируют ощущение качества продукта. Делегировать junior-разработчикам, автоматизировать, брать как filler-задачи в спринт.
IGNORE (Low Impact + Low Frequency). Редкие проблемы с минимальным влиянием. Удалить из backlog или перенести в “icebox”. Каждые 6 месяцев пересматривать: если frequency выросла, задача перемещается в другой квадрант.
AI-скоринг: промпты для оценки Frequency и Impact
AI заменяет групповые оценки. Вместо planning poker с субъективными числами LLM получает данные и возвращает скоринг с обоснованием.
Промпт для оценки Frequency
Ты — продуктовый аналитик. Оцени frequency (частоту возникновения потребности)
для задачи из backlog.
## Задача
{task_title}
{task_description}
## Данные
- Активные пользователи в месяц (MAU): {mau}
- Support-тикеты по теме за последние 30 дней: {tickets_count}
- % сессий, в которых пользователь выполняет связанное действие: {session_percentage}
- Количество упоминаний в user interviews (из {total_interviews}): {mentions}
## Инструкция
1. Проанализируй каждый источник данных отдельно.
2. Определи frequency score от 1 до 10 по шкале:
- 1-2: <1% пользователей в месяц
- 3-4: 1-10% пользователей в месяц
- 5-6: 10-30% пользователей еженедельно
- 7-8: 30-60% пользователей ежедневно
- 9-10: 60%+ пользователей в каждой сессии
3. Верни JSON: {"score": N, "confidence": "high|medium|low", "reasoning": "..."}
Если данных недостаточно для уверенной оценки, поставь confidence: "low"
и укажи, какие данные нужно собрать.
Промпт для оценки Impact
Ты — продуктовый аналитик. Оцени impact (влияние на целевую метрику)
для задачи из backlog.
## Задача
{task_title}
{task_description}
## Целевая метрика
{target_metric} (например: 7-day retention, conversion to paid, NPS)
## Данные
- Текущее значение метрики: {current_value}
- Результаты A/B-тестов похожих фич: {ab_test_results}
- Churn-анализ: {churn_data} (% пользователей, упомянувших проблему в exit survey)
- Корреляция: пользователи с решённой проблемой показывают метрику {correlated_value}
## Инструкция
1. Проанализируй каждый источник данных.
2. Оцени ожидаемый прирост целевой метрики в процентах.
3. Определи impact score от 1 до 10 по шкале:
- 1-2: <1% прирост метрики
- 3-4: 1-5% прирост
- 5-6: 5-15% прирост
- 7-8: 15-30% прирост
- 9-10: 30%+ прирост
4. Верни JSON: {"score": N, "expected_lift": "X%", "confidence": "high|medium|low", "reasoning": "..."}
Промпт для batch-оценки всего backlog
Ты — продуктовый аналитик. Оцени impact и frequency для каждой задачи в backlog.
## Backlog
{tasks_json}
## Контекст продукта
- Продукт: {product_description}
- MAU: {mau}
- Целевая метрика: {target_metric}, текущее значение: {current_value}
- Основные сегменты пользователей: {segments}
## Для каждой задачи верни:
{
"task_id": "...",
"frequency": {"score": N, "confidence": "...", "reasoning": "..."},
"impact": {"score": N, "expected_lift": "X%", "confidence": "...", "reasoning": "..."},
"quadrant": "do_first|strategic|quick_win|ignore",
"priority_rank": N
}
## Правила
- Оценивай на основе предоставленных данных, не домысливай.
- При недостатке данных ставь confidence: "low".
- Сортируй по quadrant (do_first > strategic > quick_win > ignore),
внутри квадранта — по сумме scores.
Пример: backlog SaaS-продукта для управления проектами
Backlog из 8 задач. Данные: MAU 12 000, целевая метрика — 30-day retention (текущее значение 34%).
| # | Задача | Frequency | Impact | Квадрант |
|---|---|---|---|---|
| 1 | Уведомления о дедлайнах в Slack | 8 | 7 | DO FIRST |
| 2 | Gantt-диаграмма для проектов | 4 | 8 | STRATEGIC |
| 3 | Drag-and-drop сортировка задач | 9 | 4 | QUICK WIN |
| 4 | Экспорт в PDF | 2 | 3 | IGNORE |
| 5 | Автоматическое распределение задач по загрузке | 6 | 9 | DO FIRST |
| 6 | Кастомные поля в задачах | 7 | 6 | QUICK WIN |
| 7 | Интеграция с Jira (импорт) | 3 | 8 | STRATEGIC |
| 8 | Тёмная тема | 6 | 2 | IGNORE |
Как AI оценил задачу #1: уведомления о дедлайнах в Slack
Входные данные для промпта:
- 847 support-тикетов за 30 дней с темой “пропущенный дедлайн”
- 72% сессий содержат проверку статуса задач вручную
- В exit survey 31% ушедших пользователей упомянули “не видел, что дедлайн прошёл”
- Внутренняя гипотеза: аналогичные интеграции уведомлений о дедлайнах в workflow-инструментах обычно дают +10-20% к task completion (общий отраслевой паттерн, не одна цитируемая метрика)
AI-ответ:
{
"task_id": "slack-deadline-notifications",
"frequency": {
"score": 8,
"confidence": "high",
"reasoning": "847 тикетов при 12K MAU = 7% пользователей обращаются в поддержку. 72% сессий с ручной проверкой статуса. Реальная frequency значительно выше — большинство пользователей не пишут в поддержку, а просто пропускают дедлайны."
},
"impact": {
"score": 7,
"confidence": "medium",
"reasoning": "31% churned users упомянули проблему. Отраслевой паттерн (10-20% прироста task completion от deadline notifications) коррелирует с retention. Ожидаемый прирост 30-day retention: 12-18%."
},
"quadrant": "do_first",
"priority_rank": 2
}
Как AI оценил задачу #8: тёмная тема
Входные данные:
- 23 запроса в feature request board за 6 месяцев
- Нет корреляции с retention или churn
- 0 упоминаний в exit survey
AI-ответ:
{
"task_id": "dark-theme",
"frequency": {
"score": 6,
"confidence": "low",
"reasoning": "23 запроса за 6 месяцев — малая выборка. Многие пользователи предпочитают тёмную тему, но не запрашивают её активно. Score 6 — компромисс между низким количеством запросов и предположением о скрытом спросе. Нужны данные опроса."
},
"impact": {
"score": 2,
"confidence": "high",
"reasoning": "Ноль корреляции с retention и churn. Косметическое изменение. Конкуренты с тёмной темой не показывают лучших метрик вовлечённости."
},
"quadrant": "ignore",
"priority_rank": 8
}
Автоматизация: скрипт для batch-скоринга
Полный pipeline для обработки backlog через AI. На вход: JSON с задачами и данными. На выход: отсортированный backlog с квадрантами.
import json
from openai import OpenAI
client = OpenAI()
def score_backlog(tasks: list[dict], context: dict) -> list[dict]:
"""Оценивает backlog через AI и распределяет по квадрантам."""
prompt = build_batch_prompt(tasks, context)
response = client.chat.completions.create(
model="gpt-5.4",
response_format={"type": "json_object"},
messages=[
{"role": "system", "content": "Ты — продуктовый аналитик. Отвечай только JSON."},
{"role": "user", "content": prompt}
],
temperature=0.2 # Низкая temperature для воспроизводимости
)
scored = json.loads(response.choices[0].message.content)
return assign_quadrants(scored["tasks"])
def assign_quadrants(tasks: list[dict]) -> list[dict]:
"""Присваивает квадрант на основе scores."""
for task in tasks:
f = task["frequency"]["score"]
i = task["impact"]["score"]
if f >= 5 and i >= 7:
task["quadrant"] = "do_first"
elif f < 5 and i >= 7:
task["quadrant"] = "strategic"
elif f >= 5 and i < 7:
task["quadrant"] = "quick_win"
else:
task["quadrant"] = "ignore"
# Сортировка: do_first → strategic → quick_win → ignore
order = {"do_first": 0, "strategic": 1, "quick_win": 2, "ignore": 3}
tasks.sort(key=lambda t: (
order[t["quadrant"]],
-(t["frequency"]["score"] + t["impact"]["score"])
))
return tasks
Визуализация матрицы
import matplotlib.pyplot as plt
import matplotlib.patches as patches
def plot_matrix(tasks: list[dict], output_path: str = "matrix.png"):
"""Визуализирует Impact × Frequency Matrix."""
fig, ax = plt.subplots(1, 1, figsize=(10, 10))
# Квадранты
colors = {
"do_first": "#22c55e20",
"strategic": "#3b82f620",
"quick_win": "#eab30820",
"ignore": "#ef444420"
}
ax.add_patch(patches.Rectangle((5, 7), 5, 3, facecolor=colors["do_first"]))
ax.add_patch(patches.Rectangle((1, 7), 4, 3, facecolor=colors["strategic"]))
ax.add_patch(patches.Rectangle((5, 1), 5, 6, facecolor=colors["quick_win"]))
ax.add_patch(patches.Rectangle((1, 1), 4, 6, facecolor=colors["ignore"]))
# Подписи квадрантов
ax.text(7.5, 9.5, "DO FIRST", ha="center", fontsize=12, fontweight="bold", color="#16a34a")
ax.text(3, 9.5, "STRATEGIC", ha="center", fontsize=12, fontweight="bold", color="#2563eb")
ax.text(7.5, 1.5, "QUICK WINS", ha="center", fontsize=12, fontweight="bold", color="#ca8a04")
ax.text(3, 1.5, "IGNORE", ha="center", fontsize=12, fontweight="bold", color="#dc2626")
# Задачи
for task in tasks:
f = task["frequency"]["score"]
i = task["impact"]["score"]
ax.plot(f, i, "o", markersize=12, color="#1e293b")
ax.annotate(
task["task_id"][:20],
(f, i),
textcoords="offset points",
xytext=(10, 5),
fontsize=8
)
ax.set_xlabel("Frequency", fontsize=14)
ax.set_ylabel("Impact", fontsize=14)
ax.set_xlim(1, 10)
ax.set_ylim(1, 10)
ax.set_title("Impact × Frequency Matrix", fontsize=16, fontweight="bold")
ax.grid(True, alpha=0.3)
plt.tight_layout()
plt.savefig(output_path, dpi=150, bbox_inches="tight")
Интеграция с sprint planning
Матрица не заменяет sprint planning. Она заменяет субъективную часть: споры о приоритетах.
Workflow
-
Перед planning. Product manager запускает batch-скоринг backlog. AI оценивает каждую задачу по двум осям. Результат — отсортированный список с квадрантами.
-
На planning. Команда видит матрицу. Обсуждение фокусируется на двух вопросах: “Согласны ли мы с оценками AI?” и “Сколько из DO FIRST влезает в спринт?”. Вместо долгих дебатов уходит 10 минут на валидацию.
-
Формирование спринта. Сначала задачи из DO FIRST (по убыванию суммы scores). Оставшийся capacity заполняется QUICK WINS. Одна STRATEGIC-задача на спринт для долгосрочного прогресса.
-
После спринта. Сравнение предсказаний AI с реальным эффектом. Фидбек улучшает будущие оценки: если AI систематически завышает impact для интеграций, добавляется корректирующий коэффициент.
Обработка несогласия с AI
AI ошибается. Протокол:
- Если команда не согласна с оценкой, участник предоставляет данные, которые AI не учёл. Промпт перезапускается с новыми данными.
- Если данных нет и несогласие основано на интуиции, фиксируется голосование. При расхождении с AI задача отмечается для ретроспективного анализа: через спринт проверяется, кто был ближе к реальности.
- После нескольких спринтов накапливается статистика точности AI vs. команды. По опыту, AI точнее в оценке frequency (данные объективны) и слабее — в impact (предсказать эффект сложнее).
Контекст для AI: что передавать в промпт
Качество скоринга зависит от качества контекста. Подробнее о формировании контекста для LLM: Context Engineering: полное руководство.
Минимальный контекст для адекватной оценки:
| Данные | Источник | Влияет на |
|---|---|---|
| MAU, DAU | Аналитика продукта | Frequency |
| Support-тикеты по теме | Zendesk, Intercom | Frequency |
| % сессий с действием | Mixpanel, Amplitude | Frequency |
| Exit survey ответы | Typeform, встроенный опрос | Impact |
| A/B-тесты похожих фич | Experimentation platform | Impact |
| Churn-данные | Аналитика, CRM | Impact |
| Конкурентный анализ | Публичные данные | Impact |
Без данных AI генерирует галлюцинации. Промпт с пустыми полями вернёт уверенные, но бессмысленные оценки. Правило: если для задачи нет данных хотя бы по двум источникам, сначала собрать данные, потом оценивать.
Граничные случаи
Задача с high frequency и пограничным impact (6–7). Запускать A/B-тест. Если подтвердится impact 7+, задача переходит в DO FIRST. Если нет, остаётся в QUICK WINS.
Новая фича без аналогов. Нет данных о frequency. Провести 5 user interviews с целевым вопросом: “Как часто вы сталкиваетесь с X?”. Результаты интервью передать в промпт как данные.
Техдолг. Frequency для техдолга считается иначе: не “как часто пользователь сталкивается”, а “как часто техдолг замедляет разработку”. Источник данных — время на workaround в каждом спринте. Impact — снижение velocity команды.
Зависимости между задачами. Если задача B зависит от задачи A, а B в DO FIRST, то A автоматически повышается. AI учитывает зависимости, если передать граф зависимостей в промпт.
Метрики эффективности метода
Через 3 месяца использования матрицы:
- Время на приоритизацию. Сравнить длительность обсуждения приоритетов до и после.
- Точность предсказаний. Какой процент задач из DO FIRST дал ожидаемый impact.
- Соотношение квадрантов в спринте. Здоровое распределение: 60% DO FIRST, 25% QUICK WINS, 15% STRATEGIC, 0% IGNORE.
- Velocity. Если метод работает, velocity растёт за счёт фокуса на задачах с максимальным ROI.
Ограничения
Матрица не учитывает стоимость реализации. Задача в DO FIRST может потребовать 3 месяца разработки. Для этого добавляется третье измерение — effort. Но на практике двумерная матрица покрывает большинство решений. Effort влияет на порядок внутри квадранта, а не на сам квадрант.
AI-скоринг не заменяет продуктовое мышление. Он заменяет субъективные оценки данными. Финальное решение остаётся за командой. Матрица даёт общий язык и точку отсчёта для обсуждения, а не автоматический ответ.
Нужна помощь с приоритизацией продукта? Я помогаю стартапам внедрять AI-решения и строить продукты — belov.works.
FAQ
Можно ли использовать Impact × Frequency Matrix параллельно с RICE, а не вместо него?
Да, и некоторые команды именно так и делают. Практичный подход: матрица для первичного разбора — быстро распределить 30+ задач backlog по квадрантам, а RICE применять только к задачам из Do First и Strategic, где дополнительная точность оценки Confidence и Effort действительно важна. Прогон полного RICE по каждой задаче, включая будущие IGNORE, — это именно та неэффективность, которую матрица устраняет.
Как оценить задачу, для которой данных о frequency ещё нет?
Проведите пять целевых пользовательских интервью с одним вопросом: «Как часто вы сталкиваетесь с X в своём рабочем процессе?» Передайте дословные ответы напрямую в промпт для оценки frequency. Установите confidence «low» и пометьте задачу для сбора данных. Матрица всё равно даст actionable квадрант; отметка низкой уверенности сигнализирует команде о необходимости валидации перед выделением ресурсов в спринте.
Как меняется точность модели по мере взросления продукта и изменения поведения пользователей?
Точность снижается. Activation-паттерны меняются при выходе новых фич, сезонность влияет на engagement-метрики. Решение — feedback loop: после каждого спринта фиксируйте, дали ли задачи из Do First ожидаемый impact. После 3–4 спринтов накопится достаточно данных для перекалибровки весов — особенно для impact, который сложнее предсказать, чем frequency. Команды, которые игнорируют этот шаг, обнаруживают, что их модель уверенно приоритизирует не то уже через квартал.