Искусство отказа: как продакт-менеджеру решать, что не стоит делать

Распространённая ловушка невозвратных затрат

На каждом планировании спринта кто-то предлагает функцию, которую «хотят пользователи». Выглядит разумно, технически выполнимо, конкуренты уже сделали. Функция попадает в бэклог, через несколько циклов выходит, и в день релиза DAU не меняется. Когда спрашивают, зачем это делали, PM не может чётко объяснить.

Это не единичный случай. В своей работе и наблюдая за другими командами, я заметил: большинство продуктов умирает не от недостатка функций, а от их переизбытка — и никто не решается сказать «нет».

Слово «нет» сильно недооценено в приоритизации. У нас есть модели RICE, WSJF или Kano для выбора того, что делать, но почти нет чек-листа для систематического обоснования отказа.

Почему так трудно отказаться?

Три психологических искажения:

Ошибка невозвратных затрат: Уже вложено обсуждение, дизайн, разработка. Остановиться кажется расточительством. Но прошлые затраты не должны влиять на будущие решения.
Подтверждающее искажение: Кто-то в команде верит, что функция принесёт рост, и вы неосознанно ищете подтверждающие данные, игнорируя противоположные сигналы.
FOMO (страх упустить): У конкурентов есть, у нас нет. Это вызывает тревогу. Но конкурентный анализ отвечает лишь на вопрос «что делают другие», а не «должны ли мы делать это».

Чек-лист отказа

Я разработал простой трёхступенчатый фильтр. Для каждой кандидатной функции F ответьте на вопросы. Если хотя бы на одном этапе ответ «нет», рекомендую отказаться или отложить до появления дополнительных данных.

Первый этап: Основная проблема

Решает ли F прямо текущую неудовлетворённую потребность пользователей?

Судить нужно не по тому, что пользователи говорят, а по тому, что они делают. Если поведенческие данные показывают, что большинство застревает на критическом шаге, и F убирает это узкое место — проход. Если F лишь «было бы неплохо» или решает редкий сценарий (например, <5% жалоб) — отказ.

Пример (гипотетический): Вы делаете AI-инструмент для написания английских писем. Пользователи просят «больше шаблонов». Но аналитика показывает, что большинство сразу удаляет содержимое шаблона и пишут с нуля. Это означает, что реальная потребность — персонализация, а не количество шаблонов. Добавление шаблонов — неверное решение; стоит улучшить модель для генерации в стиле пользователя.

Второй этап: Альтернативная стоимость

Если мы сделаем F, что мы не сделаем?

Ресурсы ограничены. Команда из четырёх разработчиков может выпускать лишь две средние функции за спринт. Выбор F означает отказ от кандидатов G и H. Спросите себя: имеет ли G или H явно более высокую ожидаемую ценность? Если ожидаемая ценность F незначительно выше средней по другим кандидатам — отказ.

Используйте упрощённую оценку: Ценность = (количество затронутых пользователей × серьёзность проблемы) / (стоимость реализации + стоимость поддержки). Если F набирает меньше среднего по бэклогу — отказ.

Третий этап: Отложимость

Если мы не сделаем F сейчас, уйдут ли пользователи через три месяца?

Это самый неочевидный этап. Многие функции, даже без них, не заставят пользователей уйти сразу. Они повозмущаются, но если основная ценность продукта остаётся, они останутся — пока нет лучшей альтернативы. Умение принимать отложенное удовлетворение — признак зрелости продакт-менеджера.

Как внедрить отказ в практику

Одного чек-листа недостаточно; нужно согласие команды. Рекомендую добавить в еженедельное продуктовое ревью регулярный пункт: «Голосование за отказ». Любой может выдвинуть текущую задачу из бэклога или существующую функцию с аргументацией для отказа. Команда обсуждает, и если простое большинство согласно, задача официально удаляется из роадмапа или помечается как «без активной разработки».

На практике большинство отменённых функций никто не вспоминает. Сэкономленное время можно потратить на то, что действительно меняет поведение пользователей.

Граничные условия

Этот чек-лист не適用яется к:

Требованиям соответствия (закон/регуляторика)
Исправлениям безопасности
Техническому долгу, угрожающему стабильности системы

В этих случаях действовать нужно независимо от результатов чек-листа.

Заключение

Суть приоритизации — не выбор того, что делать, а выбор того, чего не делать. Научиться сознательно отказываться требует больше смелости, чем научиться выбирать, — потому что отказ означает признание, что прежние предположения могли быть неверны, и освобождение места для более ценного.

В следующий раз, когда столкнётесь с «неплохой» функцией, не спешите ставить её в спринт. Прогоните через три этапа. Вы увидите, что большинство функций не пройдут проверку.

PaxLee