Комментарии 5
Хороший подход, спасибо за статью!
// вести весь бэклог в notion - идеально, жаль что они ушли из РФ, приходится обходиться экселями с миро..
А как вы growth-задачи на таком подходе вообще можете отловить? Как выстроена работа не по фичам, а по платящей аудитории и из потребности не на основе отзывов, а на основе того же jtbd, например? Или это описана работа support-team с классическим канбаном, все же продукт зрелый, а в growth не заморачиваетесь почти вообще или он вынесен в отдельный стрим со своими процессами и подходами к исследованиям?
Хорошее замечание про growth.
Я столкнулся с тем, что такой подход к бэклогу "скошен" в пользу текущего продукта. Не так много кейсов поступало, которые показывали бы нужду в новом продукте или идеи новых механик в текущих.
Сейчас работа по гипотезам роста идет отдельно. Каждый цикл долгосрочного планирования (полугодие) формируем гипотезы в 3 шага: сбор → оценка → отсев.
Критерии для оценки:
объем потенциального рынка клиентов
темпы подключения новых клиентов
(для текущих продуктов) влияние на средний чек / (для новых продуктов) новый MRR
сложность разработки
сколько ждать эффект после разработки
уверенность
Отсеиваем то, что мало помогает в достижении целей + прикидываем необходимую разработку и сколько мы готовы тратить времени на проверку этих гипотез.
Хорошая статья про обучение PM работе с бэклогом.
Пару вопросов:
Выкатили новую фичу, но клиенты не используют, потому что хотели её под Новый год, а сейчас — июнь.
1.Как внедрение вашей системы приоритезации помогает решить эту проблему и внедрить новую фичу для крупного приносящего много денег клиента? Ведь охват будет низкий
Было: Выбирали задачу и тратили неделю продакт-менеджера на подбор и актуализацию клиентских кейсов
2.Может быть есть статистика сколько сейчас времени тратят продакт-менеджеры на триаж и оценку?
Чтобы ориентироваться по кейсам, стал складывать их в папки по схожим или одинаковым задачам клиентов.
3.Кто сейчас занимается сортировкой кейсов по папкам?
И одно уточнение по поводу показателя Уверенность (Confidence), он характеризует не уверенность в наличии проблемы, а уверенность в остальных показателях системы RICE.
- У вас отлично расписаны метрики внутри Impact, наличие показателей по этим метрикам и подтверждает Уверенность во Влиянии.
- Наличие похожих реальных проблем показывает Уверенность в Охвате, и позволяет не опираться только на "чуйку".
- Можно отказаться от оценки Усилий при груминге продуктового бэклога, но странно отказываться от оценки перед моментом принятия обязательств и переносом в бэклог разработки.
Представьте что у вас есть одна фича с весом 300 и делать вы ее будете 4 месяца, и есть четыре фичи с весом 200 каждая, и делать их вы будете так же 4 месяца.
Как внедрение вашей системы приоритезации помогает решить эту проблему и внедрить новую фичу для крупного приносящего много денег клиента? Ведь охват будет низкий
Как я понял, ситуация — есть крупный клиент с довольно уникальным кейсом, надо что-то решать. Да, в бэклоге такой кейс не всплывет наверх автоматически, но решение все равно за продакт менеджером (веса лишь помогают быстрее ориентироваться):
если кейс в вижене, импакт очевиден, то на ручном приводе планируем
иначе (не в вижене или сомнительный импакт) — либо предлагаем workaround, либо мотивированно отказываем
Может быть есть статистика сколько сейчас времени тратят продакт-менеджеры на триаж и оценку?
У продуктовой команды 1ч слот для триажа каждую неделю. На нем и кейсы триажат, и группируют по проблемам (это к третьему вопросу).
И раз в две недели PBR на 1ч, где актуализируют и планируют продуктовые изменения в разработку.
Спасибо за уточнение про Confidence, я почему-то воспринимал ее как "уверенность в пользе решения проблемы". По интересному совпадению в этом бэклоге рост уверенности завязан на импакт (за каждый закрытый клиентский кейс) и на охват (за каждого клиента, который самостоятельно пытался решить свой кейс).
И про Effort. На этапе поиска решений уже прикидываем усилия для их реализации, привлекая разработку.
Структурировали бэклог, теперь внедряем 80% разработок вместо 20%