Impact–Frequency Matrix: приоритизация backlog по данным

Backlog может выглядеть data-driven и всё равно состоять из анекдотов. Десять запросов от одного крупного клиента превращаются в «high frequency». Серьёзная ошибка маленького сегмента теряется. Затем кто-то ставит в таблицу 8 и 9 — и мнение получает десятичные знаки.

Impact–Frequency Matrix полезна, когда не даёт этому случиться. Это карта проблем для triage:

• frequency — как часто возникает проблема, у кого и за какой период;
• impact — какие последствия она создаёт для пользователя или бизнеса;
• confidence — насколько надёжен evidence.

Матрица не выбирает решение. Она показывает, где следующий час discovery, вероятнее всего, окупится.

Начинайте с проблемы, а не с feature request

«Добавить уведомления в Slack» — решение. «Владельцы проектов слишком поздно замечают пропущенные дедлайны» — проблема. Если поставить на матрицу решение, исчезнут альтернативы: alert внутри продукта, daily digest, escalation rules или более ясный экран дедлайнов.

Записывайте кандидата в одном формате:

[cohort] не может [job] в ситуации [context], что приводит к [наблюдаемое последствие].

Пример:

Администраторы пространств с 20+ активными проектами поздно замечают overdue work,
из-за чего вручную проверяют статусы и пропускают передачи работы клиентам.

Такое утверждение можно проверить через analytics и research. Если вместо него остаётся размытый запрос, верните элемент в discovery, а не присваивайте уверенный score. Измеримый PRD должен сохранить ту же связь проблемы, outcome и evidence.

Определите обе оси до скоринга

Команды спорят о точках, потому что молча используют разные denominators. До просмотра backlog зафиксируйте определения для всего decision set.

Frequency требует denominator и периода

Выберите единицу, подходящую продукту:

• доля затронутых активных аккаунтов за месяц;
• пользователи, столкнувшиеся с проблемой за неделю;
• неудачные попытки на тысячу транзакций;
• support conversations на сто активных клиентов;
• часы прерываний engineering-команды за sprint.

Сырых ticket counts почти всегда недостаточно. Они переоценивают клиентов, которые пишут в support, и не видят молчаливые отказы. Сопоставляйте поведение с interviews, tickets, search logs, sales notes или churn reasons, но не складывайте разные единицы.

Откалибруйте rubric под свой traffic. Например:

Это пример, а не стандарт. B2B-продукту с 40 enterprise-аккаунтами и consumer app с миллионами сессий нужны разные границы.

Impact требует конкретного outcome

Impact — не «насколько нам нравится идея». Сначала назовите последствие:

• задачу нельзя завершить;
• можно потерять деньги или данные;
• растёт время выполнения job;
• меняются activation, retention, conversion или expansion;
• требуется вмешательство support или operations;
• возникает contractual, security или accessibility risk.

Вместо выдуманного точного lift используйте rubric последствий:

Оценивайте текущую проблему, а не желаемый эффект фичи. Корреляция между использованием функции и retention — evidence, но не доказательство, что расширение функции вызовет рост retention. Causal claim по возможности проверяйте экспериментом. В плейбуке экспериментов разобраны sample size, guardrails и decision rules.

Храните confidence отдельно

Не умножайте слабые данные в точный на вид общий score. Показывайте confidence рядом с точкой:

• high: репрезентативные behavioral или financial data и подтверждающий qualitative evidence;
• medium: один надёжный quantitative source или несколько согласованных qualitative sources;
• low: малая выборка, proxy metric, устаревшие данные или открытое разногласие.

Low confidence не означает low priority. Потенциально тяжёлая, но плохо изученная проблема должна попасть в discovery. Следующим действием может быть interview, instrumentation, разбор logs или маленький test — не production build.

Рабочая таблица должна хранить provenance:

Без evidence column матрица становится ещё одним ритуалом голосования.

Правильно читайте четыре квадранта

                         HIGH IMPACT
                              │
       срочно исследовать     │  проверить и действовать
          low frequency      │     high frequency
                              │
LOW FREQUENCY ────────────────┼──────────────── HIGH FREQUENCY
                              │
        наблюдать / убрать    │  снять повторяющееся трение
                              │
                          LOW IMPACT

High impact, high frequency: проверить и действовать

Эти проблемы требуют немедленного внимания, но не автоматического обещания фичи. Проверьте evidence, сегменты и минимальное безопасное вмешательство. Заранее задайте outcome test.

High impact, low frequency: срочно исследовать

Редкое не означает неважное. Удаление аккаунта, повреждение платежа, access-control failure и accessibility blocker могут попасть сюда. Safety, security, legal и contractual issues проходят по отдельным severity rules, а не по обычной roadmap math.

Low impact, high frequency: снять повторяющееся трение

Частое трение накапливается. Ищите небольшое исправление copy, defaults, workflow, documentation или reliability. Не называйте задачу quick win, пока engineering не проверил effort и blast radius.

Low impact, low frequency: наблюдать или убрать

Сохраните evidence и review trigger, затем удалите задачу из активного backlog. Trigger может быть порогом frequency, появлением нового стратегического сегмента или повторным support pattern. Бесконечный icebox — не decision log.

Добавьте gates, которых нет на матрице

Перед коммитом capacity проверьте:

1. Strategic fit: относится ли проблема к целевому segment и текущему outcome?
2. Effort: сколько стоит минимальное вмешательство для product, design, engineering, operations и support?
3. Dependencies: должна ли сначала завершиться другая система или migration?
4. Risk: что может сломаться и насколько изменение обратимо?
5. Opportunity cost: какой уже профинансированный outcome сдвинется?
6. Learning value: может ли дешёвый test сначала убрать uncertainty?

Поэтому матрица дополняет, а не «побеждает» другие методы. Исходный RICE framework добавляет reach, confidence и effort. WSJF фокусируется на cost of delay и job size. MoSCoW помогает договориться о scope timebox. Выбирайте инструмент под конкретный trade-off. В нашем гайде по RICE показано, как сохранять source evidence, а не выдавать оценку LLM за измерение.

Где AI помогает — и где должен остановиться

LLM полезны в рутинной работе вокруг prioritization:

• нормализовать labels из support, interviews и sales notes;
• предложить дубликаты problem statements для ручной проверки;
• извлечь цитаты вместе с record IDs;
• кратко показать противоречия между источниками;
• отметить отсутствующие denominator, dates, cohorts и outcome definitions;
• собрать decision brief из уже утверждённых scores.

Но LLM не создаёт evidence. Не просите модель вывести frequency из общих знаний или предсказать metric lift по описанию фичи. Результат будет аккуратно оформлен, но не станет надёжной приоритизацией.

Безопасный промпт явно задаёт границу:

Ты готовишь evidence для product triage. Используй только записи ниже.

Для каждой предполагаемой проблемы:
1. Перепиши её как cohort + job + situation + observable consequence.
2. Перечисли supporting record IDs и contradictory record IDs.
3. Считай frequency только при наличии denominator и time window.
4. Не оценивай impact самостоятельно. Сопоставь явные последствия с нашей rubric.
5. Верни missing_data, если evidence не поддерживает score.
6. Не объединяй security, legal, accessibility и contractual issues в clusters.

Верни JSON с полями:
problem, cohort, window, evidence_ids, counterevidence_ids,
frequency_value, impact_evidence, confidence, missing_data.

Records:
{redacted_records}
Rubric:
{team_rubric}

До импорта результата проверьте cited records. Удалите персональные данные до отправки материала любой модели и соблюдайте approved data boundary организации. Хороший context engineering не исправит biased или unauthorized input.

Пример без выдуманной точности

Допустим, у project tool за одинаковые последние 28 дней наблюдались три проблемы:

Матрица не говорит «сначала строить Slack notifications». Она предлагает:

• исследовать deadline awareness и проверить минимальное вмешательство;
• убрать font issue из активного backlog с review trigger;
• провести SSO mapping через incident и access-control severity, несмотря на низкую frequency.

Это лучше сортировки feature names по сумме, которую придумала LLM.

Проведите review за 45 минут

1. До встречи: один owner готовит problem statements, rubric и evidence links. AI может сгруппировать записи, но человек проверяет каждый cluster.
2. Первые 10 минут: подтвердите cohort, window, target outcome и exception rules.
3. Следующие 15 минут: разместите items с high или medium confidence. Помечайте disputed evidence, а не усредняйте разногласие.
4. Следующие 10 минут: назначьте discovery action для low-confidence, high-impact items.
5. Последние 10 минут: примените strategy, effort, dependency и risk gates. Запишите решение, owner и дату устаревания evidence.

Возвращайтесь к матрице по подходящему продукту cadence или при срабатывании trigger. После release сравните наблюдаемый outcome с hypothesis. Цель не в том, чтобы доказать правоту scoring model. Цель — улучшить следующее решение.

Главное правило

Impact × Frequency должна показывать evidence, а не прятать judgment. Если точку нельзя проследить до cohort, периода, outcome и source records, это не data-driven решение. Это мнение, которому нарисовали координаты.