Приоритизация фич ломается, когда команда сравнивает идеи, а не решения

Приоритизация фич ломается, когда команда сравнивает идеи, а не решения

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

Мини-чек-лист перед скорингом:
— есть подтверждённая пользовательская проблема;
— понятно, какую метрику двигаем;
— есть гипотеза, почему именно эта фича поможет;
— оценён минимальный скоуп, а не «идеальная версия».

Дальше сравнивайте не фичи, а ставки. Хорошая ставка отвечает на три вопроса: какой upside, какая уверенность, какая цена ошибки. Если impact высокий, но уверенность низкая — это не повод строить сразу, это повод на discovery или прототип.

Типовая ошибка — прятать политические решения в таблицу RICE. Скоринг помогает увидеть разницу, но не заменяет продуктовый выбор. Если фича нужна для enterprise-клиента, стратегии или снижения риска, так и пишите в rationale, не маскируйте это баллами.

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