# Impact × Frequency Matrix: метод AI-приоритизации, который заменил споры на sprint planning

> Матрица impact×frequency с AI-скорингом для приоритизации backlog. Промпты, примеры, визуализация. Замена субъективных дебатов на данные.
> Author: Roman Belov · Published: 2026-05-21 · Source: https://futurecraft.pro/ru/blog/impact-frequency-matrix/

Продуктовые команды теряют много времени на sprint planning, споря о приоритетах. RICE, WSJF, MoSCoW генерируют субъективные оценки, которые зависят от громкости голоса участника, а не от данных. Эта проблема растёт снизу-вверх — когда [PRD пишутся без измеримых критериев успеха](/ru/blog/ai-powered-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](/ru/blog/rice-scoring-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-метрики — в [плейбуке экспериментов](/ru/blog/experimentation-playbook/).)
- **Конкурентный анализ.** Если конкурент внедрил аналогичную функцию, какой эффект наблюдался (публичные данные, обзоры).
- **Корреляционный анализ.** Пользователи, у которых решена эта проблема, показывают 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-ответ:

```json
{
  "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-ответ:

```json
{
  "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 с квадрантами.

```python
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
```

### Визуализация матрицы

```python
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

1. **Перед planning.** Product manager запускает batch-скоринг backlog. AI оценивает каждую задачу по двум осям. Результат — отсортированный список с квадрантами.

2. **На planning.** Команда видит матрицу. Обсуждение фокусируется на двух вопросах: "Согласны ли мы с оценками AI?" и "Сколько из DO FIRST влезает в спринт?". Вместо долгих дебатов уходит 10 минут на валидацию.

3. **Формирование спринта.** Сначала задачи из DO FIRST (по убыванию суммы scores). Оставшийся capacity заполняется QUICK WINS. Одна STRATEGIC-задача на спринт для долгосрочного прогресса.

4. **После спринта.** Сравнение предсказаний AI с реальным эффектом. Фидбек улучшает будущие оценки: если AI систематически завышает impact для интеграций, добавляется корректирующий коэффициент.

### Обработка несогласия с AI

AI ошибается. Протокол:

- Если команда не согласна с оценкой, участник предоставляет данные, которые AI не учёл. Промпт перезапускается с новыми данными.
- Если данных нет и несогласие основано на интуиции, фиксируется голосование. При расхождении с AI задача отмечается для ретроспективного анализа: через спринт проверяется, кто был ближе к реальности.
- После нескольких спринтов накапливается статистика точности AI vs. команды. По опыту, AI точнее в оценке frequency (данные объективны) и слабее — в impact (предсказать эффект сложнее).

## Контекст для AI: что передавать в промпт

Качество скоринга зависит от качества контекста. Подробнее о формировании контекста для LLM: [Context Engineering: полное руководство](/ru/blog/context-engineering-guide/).

Минимальный контекст для адекватной оценки:

| Данные | Источник | Влияет на |
|--------|----------|-----------|
| 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-скоринг не заменяет продуктовое мышление. Он заменяет субъективные оценки данными. Финальное решение остаётся за командой. Матрица даёт общий язык и точку отсчёта для обсуждения, а не автоматический ответ.

## 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. Команды, которые игнорируют этот шаг, обнаруживают, что их модель уверенно приоритизирует не то уже через квартал.

---

*Нужна помощь с приоритизацией продукта? Я помогаю стартапам внедрять AI-решения и строить продукты — [belov.works](https://belov.works).*