Как внедрение вашей системы приоритезации помогает решить эту проблему и внедрить новую фичу для крупного приносящего много денег клиента? Ведь охват будет низкий
Как я понял, ситуация — есть крупный клиент с довольно уникальным кейсом, надо что-то решать. Да, в бэклоге такой кейс не всплывет наверх автоматически, но решение все равно за продакт менеджером (веса лишь помогают быстрее ориентироваться):
если кейс в вижене, импакт очевиден, то на ручном приводе планируем
иначе (не в вижене или сомнительный импакт) — либо предлагаем workaround, либо мотивированно отказываем
Может быть есть статистика сколько сейчас времени тратят продакт-менеджеры на триаж и оценку?
У продуктовой команды 1ч слот для триажа каждую неделю. На нем и кейсы триажат, и группируют по проблемам (это к третьему вопросу).
И раз в две недели PBR на 1ч, где актуализируют и планируют продуктовые изменения в разработку.
Спасибо за уточнение про Confidence, я почему-то воспринимал ее как "уверенность в пользе решения проблемы". По интересному совпадению в этом бэклоге рост уверенности завязан на импакт (за каждый закрытый клиентский кейс) и на охват (за каждого клиента, который самостоятельно пытался решить свой кейс).
И про Effort. На этапе поиска решений уже прикидываем усилия для их реализации, привлекая разработку.
Я столкнулся с тем, что такой подход к бэклогу "скошен" в пользу текущего продукта. Не так много кейсов поступало, которые показывали бы нужду в новом продукте или идеи новых механик в текущих.
Сейчас работа по гипотезам роста идет отдельно. Каждый цикл долгосрочного планирования (полугодие) формируем гипотезы в 3 шага: сбор → оценка → отсев.
Критерии для оценки:
объем потенциального рынка клиентов
темпы подключения новых клиентов
(для текущих продуктов) влияние на средний чек / (для новых продуктов) новый MRR
сложность разработки
сколько ждать эффект после разработки
уверенность
Отсеиваем то, что мало помогает в достижении целей + прикидываем необходимую разработку и сколько мы готовы тратить времени на проверку этих гипотез.
Как я понял, ситуация — есть крупный клиент с довольно уникальным кейсом, надо что-то решать. Да, в бэклоге такой кейс не всплывет наверх автоматически, но решение все равно за продакт менеджером (веса лишь помогают быстрее ориентироваться):
если кейс в вижене, импакт очевиден, то на ручном приводе планируем
иначе (не в вижене или сомнительный импакт) — либо предлагаем workaround, либо мотивированно отказываем
У продуктовой команды 1ч слот для триажа каждую неделю. На нем и кейсы триажат, и группируют по проблемам (это к третьему вопросу).
И раз в две недели PBR на 1ч, где актуализируют и планируют продуктовые изменения в разработку.
Спасибо за уточнение про Confidence, я почему-то воспринимал ее как "уверенность в пользе решения проблемы". По интересному совпадению в этом бэклоге рост уверенности завязан на импакт (за каждый закрытый клиентский кейс) и на охват (за каждого клиента, который самостоятельно пытался решить свой кейс).
И про Effort. На этапе поиска решений уже прикидываем усилия для их реализации, привлекая разработку.
Хорошее замечание про growth.
Я столкнулся с тем, что такой подход к бэклогу "скошен" в пользу текущего продукта. Не так много кейсов поступало, которые показывали бы нужду в новом продукте или идеи новых механик в текущих.
Сейчас работа по гипотезам роста идет отдельно. Каждый цикл долгосрочного планирования (полугодие) формируем гипотезы в 3 шага: сбор → оценка → отсев.
Критерии для оценки:
объем потенциального рынка клиентов
темпы подключения новых клиентов
(для текущих продуктов) влияние на средний чек / (для новых продуктов) новый MRR
сложность разработки
сколько ждать эффект после разработки
уверенность
Отсеиваем то, что мало помогает в достижении целей + прикидываем необходимую разработку и сколько мы готовы тратить времени на проверку этих гипотез.