Как менеджеру продукта понять, какие фичи действительно стоит разрабатывать, а какие — нет? Большинство сталкиваются с одной и той же ловушкой: приоритизация ради приоритизации.

Мы все знаем про ICE, RICE, MoSCoW и другие аббревиатуры. Они знакомы, кажутся логичными, но на практике часто не работают. Фичи с высокими баллами не «взлетают», а критичные доработки проходят мимо — просто потому, что в формулу не попали нужные параметры. В итоге дорожная карта выглядит формальной, а доверие бизнеса к решениям менеджера продукта падает.

В докладе посмотрим, как в Bothelp полностью изменили этот подход к приоритизации: теперь все начинается не с оценок. Ключевым фактором при приоритизации стала группировка фич по их сути и по сегменту пользователей, который их запрашивает. Такой подход позволил закрыть критические ограничения для крупных пользователей и выстроить логику продуктовых решений, которая отражает реальные цели бизнеса.

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

После доклада вы сможете выстроить собственную систему приоритизации:

• Начинать с целей, сегментировать фичи по типу функционала и пользователя.
• Использовать оценки как вспомогательный инструмент, а не главный критерий.

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

Кому будет полезно:

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