Глава 7: Приоритизация и принятие решений
Приоритизация
Как выбрать, что делать в первую очередь?
1) Начни с результата, а не со списка задач
Как именно формулировать результат, подробно обсуждалось в предыдущей главе.
Краткий чек-лист результата:
Какой показатель изменится? На сколько? К какому сроку?
Почему именно этот показатель двигает бизнес?
Какие метрики не должны просесть (например, NPS, отказы, Retention)?
2) Собери несколько вариантов, а не один
Думай наборами: лучше провести A/B/C-тест, а не оказаться в ситуации «делать/не делать». Это снижает риск влюбиться в единственную идею. К полезным источникам вариантов относятся Opportunity Solution Tree (карта возможностей и решений) и обратная декомпозиция воронки (где «застревают» пользователи?). Под воронкой понимается основной сценарий продукта, над которым ты работаешь.
3) Оцени потенциал, уверенность и усилия
Быстрый фильтр до детальной оценки:
Потенциал влияния на целевую метрику.
Уверенность (доказательства: данные, эксперименты, экспертиза).
Усилия (время / команда / зависимости / риск).
Задача с высоким потенциалом и уверенностью и умеренными усилиями почти всегда является кандидатом в «первую очередь».
Такой подход к оценке и приоритизации называется ICE. Чтобы получить итоговую оценку гипотезы, нужно перемножить оценки по каждому критерию между собой.
4) Проверь последовательность и зависимости
Если фича Б «разблокирует» три другие инициативы — возможно, именно она первая, даже если её собственное влияние среднее. Планируй так, чтобы минимизировать критический путь.
5) Сократи неопределённость
Если уверенность низкая — поставь на первое место исследование или эксперимент, который за 1–2 недели даст решающее знание («убедимся, что гипотеза живая»). Это может сэкономить месяцы разработки.
Что делать первым: Первая задача — та, что с наилучшим ожидаемым вкладом в ключевую метрику с учётом зависимостей и стоимости задержки, и которую ты можешь начать прямо сейчас.
Почему нельзя делать всё?
Смена контекста. Переключение между контекстами убивает скорость и качество. Размазанная по задачам команда = слабый результат везде. Старайся не терять фокус и заниматься чем-то одним.
Стоимость задержки (Cost of Delay). Всё важное не сделаешь одновременно. То, что начнёшь позже, принесёт ценность позже — а иногда и вовсе потеряет смысл. Нужно стараться сокращать Time to Market (время от начала работ до доступности пользователям) для каждой отдельной задачи.
Поздняя обратная связь. Размытый фокус = слабая обратная связь. Когда задачи растянуты, цикл «идея → результат → выводы» удлиняется. В результате можно не сделать правильных выводов и упустить важное.
Технический и организационный долг. «Параллельный прогресс» без приоритетов умножает долги и зависимые блокировки. В процессе работы какие-то части продукта успевают устареть или измениться, что усложняет дальнейшую работу над задачей. Особенно если это что-то большое.
Вывод: делать всё — значит ничего не доводить до бизнес-эффекта. Твоя сила — в сфокусированном потоке ценности для пользователя. Старайся максимально быстро доставлять ценность и фокусироваться на задачах с максимальной ценностью.
Как приоритизировать направления?
Речь о «а куда вообще идти» — конверсия в платежи или удержание, B2B-интеграции или техническая оптимизация и т.д. Важным кажется всё, а сделать за раз можем только что-то одно. Как быть?
1) Привяжи направления к стратегии
У бизнеса есть какие-то ожидания на квартал или год. И так как задача менеджера продукта, фактически, заключается в обслуживании интересов бизнеса, релизы и развитие продукта нужно строить, исходя из бизнес-стратегии.
Верхний уровень: доля рынка, LTV, маржинальность, позиционирование. Что из этого важнее в рамках стратегии? Вот самым важным и нужно заниматься;
Ключевая метрика: какие входные метрики помогают нарастить ключевую метрику сейчас (активация, частота, разнообразие использования, UGC, supply/demand-баланс и т. п.).
2) Оцени потенциальный эффект
Для оценки эффекта существуют разные фреймворки, суть которых сводится к оценке разных критериев по каждой задаче и вычислению итоговых очков. Подробнее о популярных фреймворках для приоритизации поговорим ниже.
3) Распредели нагрузку (capacity allocation)
Заранее договорись о «рамках бэклога»: например, 70/20/10.
70% — работа над ключевым сценарием / воронкой (рост, удержание, монетизация);
20% — рост вширь (новые сегменты / каналы);
10% — пробуем новое (эксперименты и исследования).
Так ты приоритизируешь направления до появления задач, не споря каждый спринт, «что важнее — рост аудитории или платёжная инфраструктура», а также покажешь стейкхолдерам, на что направлен твой фокус.
4) Определи конкретные цели и «критические вопросы» по каждому направлению
Не «улучшить удержание», а «+3 п. п. D30 ретеншена в сегменте новых пользователей в Q4; ключевой вопрос — где основной отток: onboarding или 1-й ключевой сценарий?».
Будь конкретен и обозначай сроки — план работ сам начнёт вырисовываться. Дедлайн — самый работающий фреймворк для приоритизации задач.
5) Пересматривай планы и стратегию
Нужно понимать, что стратегия не прибита гвоздями и может меняться в процессе. Обстоятельства быстро меняются, и то, что казалось важным в прошлом квартале, вдруг может оказаться полной ерундой.
Раз в квартал пересматривай стратегию и планы; раз в 2–4 недели пересматривай инициативы в рамках направлений по актуальным данным. Иногда самое мудрое решение — бросить начатое на середине, чем пытаться довести до конца.
Периоды для пересмотра могут быть любыми. Главное, чтобы стратегия отражала реальную ситуацию на рынке и в команде.
Какие фреймворки помогают приоритизировать задачи?
MoSCoW
Простой фреймворк распределения задач. Обычно используется на ранних этапах, когда видение продукта ещё чётко не сформулировано и непонятно, какой функционал должен входить в MVP.
Состоит из:
Must have. Критические требования, без которых нельзя обойтись;
Should have. Важные задачи следующей очереди. Без них больно, но можно прожить;
Could have. Можно сделать, если останется время или ресурсы. Вещи, без которых можно обойтись, но прикольно сделать;
Won’t have. Задачи, которые пока не планируется делать. Могут быть потенциально полезны, но на текущем этапе продукта не нужны.
Плюсы: помогает быстро создать общие ожидания.
Риски: слишком много задач в «Must have», отсутствие количественной ценности, и легко превращается в спор мнений.
Совет: перед разметкой зафиксируй жёсткие ограничения (дедлайн, ожидаемый результат) и метрики успеха; «Must have» — это задачи, которые реально критичны для достижения цели/срока. Подробнее.
ICE
Используется для быстрого отсева гипотез.
Формула:
ICE = Impact × Confidence × Effort
Где:
Impact — ожидаемый эффект на ключевую метрику (оценка от 1 до 10);
Confidence — уверенность в Impact (данные / тесты / экспертиза; оценка от 0,1 до 1, где 1 — это 100% уверенность);
Effort — человеко-недели / сложность (чем меньше, тем выше ICE-score).
Риски: не учитывает охват аудитории (Reach), Impact «на глаз», оценки актуальны только в момент их проставления.
Совет: периодически переоценивай весь список гипотез, так как в процессе работы будет появляться контекст, влияющий на скоринг.
RICE
Чаще всего используется при формировании дорожных карт, квартальных планов и для сравнения фич разного масштаба.
Формула:
RICE = (Reach × Impact × Confidence) / Effort
Где:
Reach — скольких пользователей коснётся за период (шт. / % / сессии);
Impact — влияние на поведение / метрики (0,25 / 0,5 / 1 / 2 / 3, где 3 — это коэффициент максимального влияния);
Confidence — уверенность 0–100% (или 0,1–1);
Effort — человеко-недели / месяцы.
Риски: двойной учёт (Impact и Reach об одном и том же), оценки необъективны.
Совет: привяжи охват (Reach) к надёжному источнику, конкретно опиши, какая оценка Impact чему соответствует, с примерами.
Модель Kano
Что: классификация атрибутов ценности: Обязательные (Must-be), Ожидаемые (Performance), Восхищающие (Delighters), Нейтральные (Indifferent) и Негативные (Reverse).
Используется при упаковке ценности для пользователя. Например: на этапе проектирования MVP, на этапе определения стратегии маркетинга или при редизайне продукта.
Фреймворк помогает понять, почему «вау-фичи» не заменяют «базовую гигиену».
Риски: требуются корректные опросы и интервью; категории смещаются со временем (Delighter → Must), долго и дорого.
Совет: пересматривай классификацию раз в 6–12 мес., соотноси с метриками успеха. Подробнее о модели Kano.
На мой взгляд, подход устарел, и лучше использовать полный фреймворк JTBD, который включает в себя приоритизацию ценности в виде дерева / графа работ.
Оценка возможностей (Opportunity Scoring)
Фреймворк помогает найти точки роста на основе обратной связи от пользователей продукта. Пользователи оценивают важность и удовлетворённость по сценариям / JTBD. Возможности рождаются там, где высокая важность и низкая удовлетворённость. Эти сценарии нужно оптимизировать в первую очередь, так как они дадут максимальный эффект.
Когда: выбор направлений улучшений в существующем продукте.
Плюсы: явно показывает «дыры» в опыте.
Риски: неверная выборка, неподходящие формулировки вопросов, отрыв от метрик дохода.
Совет: связывай «дыры» с поведенческими данными (аналитика / воронки), валидируй сегментами. Подробнее.
Принятие решений
Как принимать решения, когда есть несколько сильных альтернатив?
Шаг 0. Обратимость решения и возможные риски
Прежде чем принимать решение о том, какой путь выбрать, нужно определить, какой вариант можно будет безболезненно «откатить». Тут всё просто. Если что-то можно попробовать без последствий и потом вернуть всё как было, то нужно это пробовать.
Дальше нужно оценить «радиус поражения» в случае ошибки. Чем больше риски и последствия, тем тщательнее нужно расписать план релиза и возврата.
Как видишь, даже имея на руках сильные варианты, нельзя быть на 100% уверенным в правильности выбора.
Шаг 1. Чёткая формулировка задачи
Конкретно определи цель, критерии успеха и ограничения. Выбирай только то решение, которое максимально соответствует поставленной формулировке.
Шаг 2. Критерии для сравнения
Сравни решения между собой, чтобы точнее определить лучший вариант. Например:
Ожидаемое влияние на ключевую метрику или цель квартала;
Скорость получения результата (за сколько недель получим надёжный сигнал об успехе или неудаче);
Стоимость / усилия (как финансовые, так и человеческие ресурсы);
Возможные риски разного рода;
Соответствие долгосрочной стратегии.
Эти критерии помогут детальнее понять сильные и слабые стороны каждой гипотезы.
Шаг 3. Скоринг
Используй фреймворки для приоритизации. Например, RICE. Или, используя список критериев выше, оцени каждую гипотезу по пунктам, например по пятибалльной шкале. Сложи получившиеся баллы и приоритизируй гипотезы по получившимся очкам.
Шаг 4. Когда всё еще ничья
К этому шагу редко бывают сомнения в самом лучшем решении из списка гипотез, но если вдруг определиться так и не получается, то можно начать задавать себе абстрактные вопросы, которые могут помочь определиться.
Какая альтернатива создаёт больше будущих опций / знаний? Какое решение более масштабируемое?
Если через год окажется, что мы ошиблись — о каком невыбранном варианте ты пожалеешь сильнее?
Представь, что решение провалилось. Почему? Что бы ты изменил сейчас?
Когда применять AARRR-анализ?
Pirate Metrics, или AARRR (Acquisition — привлечение → Activation — активация → Retention — удержание → Revenue — выручка → Referral — рекомендация), — стандартная воронка, подходящая под большинство продуктов. Позволяет определить зоны роста.
Иногда букв «A» бывает три. Это Awareness (осведомлённость) — самый верх воронки. Говорит о знании бренда/продукта. Пользователи знают, что вы, как решение, существуете.
Применяй AARRR, когда:
Диагностируешь стагнацию/просадку: где именно «падает» рост — в привлечении, активации или удержании? Разбивай продукт на стримы (они же направления) и смотри, в каком самые большие потери. Обычно принято начинать с верха воронки;
Выстраиваешь метрики на стадии поиска Product-Market Fit (PMF, соответствие рынку): надо просто и одинаково назвать этапы и посчитать базовые конверсии, чтобы определить, насколько продукт интересен пользователям. Если отваливаются на самом верху воронки, то либо интерес крайне низкий, либо что-то сломалось на лендинге (и так бывает);
Проектируешь эксперименты: каждая гипотеза должна чётко бить в конкретную ступень воронки. Так проще группировать гипотезы и определять приоритеты;
Распределяешь зоны ответственности: маркетинг, продукт, аналитика, поддержка чётко должны понимать, на какую часть воронки они влияют.
Как считать, чтобы не обмануться:
Разбивай пользователей на когорты, а не бери средние значения;
Определи ключевые действия и, соответственно, метрики для каждого шага воронки: что такое Activation (первый «value moment», осознание ценности), что считаем Retention (D1/D7/WAU-retention);
Привяжись к деньгам: Retention без Revenue часто даёт ложный оптимизм. Задача бизнеса — максимизировать прибыль. Если Retention растёт, а денег нет, то толку от высокого удержания никакого;
Определи «красные линии» или «сторожевые» метрики: процент отказов, время ответа, скорость загрузки, количество жалоб и т. д. — чтобы не выжигать продукт. Зарабатывать — это хорошо, но совсем выдаивать продукт недальновидно.
Альтернатива:
Пиратская воронка линейна, что не всегда даёт правильное представление о пользовательском пути. Для некоторых сфер лучше оперировать не воронками, а циклами (социальные сети, UGC-площадки, маркетплейсы). Причём не одним циклом, а сразу несколькими. В качестве альтернативы AARRR можно попробовать Growth Loops. Или вообще комбинировать оба подхода. AARRR покажет «где течёт», циклы — «как/почему растёт».
Прозрачность решений
Как документировать и объяснять свои решения команде и стейкхолдерам?
1. Начинай с контекста
Прежде чем говорить, что нужно сделать, расскажи, почему.
Пример: «Мы выбрали запуск фичи A, потому что она решает ключевую боль сегмента X. Мы сравнивали её с фичей B, но у последней ниже ожидаемый эффект по метрике Retention D1. Решение опирается на результаты опроса и эксперимент Y.»
В идеале в каждой задаче или эпике стоит описывать контекст. Это полезно не только для команды, но и для тебя. Через какое-то время ты и сам забудешь, почему было принято именно такое решение и почему тогда это было правильным вариантом.
2. Описывай контекст понятным и доступным
Нет нужды в сложных шаблонах и подробных объяснениях — чаще всего достаточно короткой структурированной заметки: небольшой абзац со всей важной информацией.
Контекст: зачем принимается решение, какими были цели (бизнес-, пользовательские), на чём основано решение (данные, инсайты, ограничения);
Альтернативы: какие альтернативы рассматривались и почему были отброшены;
Выбор: что и почему выбрано;
Планы: в какую сторону планируется развивать решение.
Можно вести такие записи в Notion, Confluence или даже в Slack-тредах. Главное — чтобы они были доступны всем участникам команды в любой момент.
3. Общайся на одном языке
С командой — объясняй логику решений через призму ценности для пользователя и целей продукта. Это мотивирует команду и даёт понять «зачем». Важно доносить цели и мотивацию своих решений.
Со стейкхолдерами — подчёркивай бизнес-обоснование, выгоду и связь с целями бизнеса. Это выстраивает доверие. Ты не просто создаёшь видимость работы, а решаешь бизнес-задачи.
Как держать команду в фокусе?
1. Повторяй цели
Рассказывай и напоминай о целях. Даже когда кажется, что все уже знают. Тебе несложно повторить. Делай это столько раз, сколько требуется. Фокус не держится автоматически. Его нужно регулярно обновлять. Начинай спринты, созвоны, обсуждения с напоминания о краткосрочных целях. И хотя бы раз в квартал говори о долгосрочных планах продукта и компании.
Регулярное проговаривание цели помогает отсекать шум и синхронизирует мышление команды.
2. Работай с «почему», а не только с «что»
Когда команда понимает, почему делается та или иная фича, она может самостоятельно принимать более точные решения в деталях реализации. Это добавляет осознанности и снижает зависимость от тебя как от единственного источника истины.
Все попытки согласовывать с тобой каждую мелочь нужно пресекать. Не поощряй такое поведение команды. Ничем хорошим это не кончится.
3. Визуализируй прогресс
Доски целей, дашборды, просто слайды и даже таблицы — любая наглядность помогает держать внимание. Особенно если ты связываешь текущие задачи с целевой метрикой.
Например: «Вот график retention. После запуска новой онбординговой фичи он подрос на 2 п. п. Двигаемся в верном направлении».
Как проверять, что решение было верным?
1. Не делай фичи ради фич
Правильное решение принимается задолго до непосредственного решения. Звучит как дурость, но важно понимать, что так называемый «фичизм» — это плохой паттерн. Ты не должен «делать фичу X». Должно быть: «фича X увеличит Retention на +3 п. п. среди сегмента Y за 2 недели после релиза».
Ты не можешь принять правильное решение по определению, если ты не решал какую-то конкретную задачу. Формируй ожидаемый результат и оценивай решения по соответствию фактического результата ожидаемому.
2. Перепроверяй решения
У каждого решения должен быть «контрольный рубеж». Хотя бы раз после внедрения нового функционала или изменения старого нужно убедиться, что метрики не изменились, всё работает, как и задумано, и пользователям всё ещё удобно это решение. Продукт живёт в вечно меняющемся контексте. И решения, которые месяц назад были верными, в новом контексте могут оказаться ошибочными.
Критерии перепроверки могут быть абсолютно любые. Например:
через 2 недели после релиза;
после накопления 1000 MAU;
при достижении определённой фазы проекта.
Без точки пересмотра можно легко попасть в ловушку самоуспокоенности: «ну, мы же сделали».
3. Говори об ошибках открыто
Если решение оказалось неверным — важно не искать виноватых, а зафиксировать, что мы узнали. Делай выводы, а не ищи оправдания.
Пример:
«Мы ожидали рост метрики, но получили падение. Анализ показал, что новая фича перегрузила первый экран. Учтём это при следующих итерациях.»
Прозрачное обсуждение промахов делает команду и продукт сильнее. Главное — создавать безопасную среду для таких разговоров.
Итог седьмой главы
Цели должны быть чётко сформулированы: метрика, сегмент, срок и ключевой вопрос, на который ищем ответ.
Никогда не держись за одну идею — думай наборами альтернатив. Это снижает риск ошибочного выбора.
При слабой уверенности приоритизируй исследования и эксперименты.
Делать всё одновременно — значит терять фокус, замедляться и получать позднюю обратную связь.
Направления развития нужно приоритизировать от стратегии бизнеса, а не от шума в бэклоге.
Стратегия и приоритеты обязаны пересматриваться регулярно — фиксироваться на устаревшем плане опаснее, чем менять курс.
При выборе между сильными вариантами сначала оценивай обратимость решения и «радиус поражения».
Любое решение должно быть прозрачно задокументировано: контекст → альтернативы → выбор → дальнейшие планы.
Команда держит фокус не сама по себе — его нужно постоянно проговаривать и визуализировать.
Сильный продакт объясняет «почему», а не микроменеджерит «что».
Фича без гипотезы — ошибка по определению. Сначала ожидаемый эффект, потом реализация.
Ошибки — это полезно, если их фиксировать и обсуждать открыто, а не замалчивать.
То же самое в формате тг-канала. Сначала будет выходить там отдельным постами по чуть-чуть, потом здесь большой статьей.
