Роадмаппинг здорового человека
Roadmaps should be lists of questions, not lists of features.
Парадоксальную вещь напишу. Если вы время от времени думаете: “а запишу-ка я себе заново вот самые срочные доработки/улучшения в продукте, которые вот нужно сделать совсем в следующем спринте”, и у вас получится список на 6 месяцев — значит, все хорошо. Ну в самом деле. Это значит, что вы думаете о вечном (зачеркнуто) о важном, и знаете чего от вас ждут пользователи/бизнес. И главное, у вас есть простор для полезных упражнений по приоритезации. Ограничения ресурсов есть везде — будь вы стартап, энтерпрайз с миллионами долларов дохода, или Google.
Буквально в середине этой недели у меня наконец-то закончился очередной забег “быстро-быстро фиксим все, что мешает нашим самым крупным клиентами и за что нам стыдно”, возник легкий вакуум, и в четверг-пятницу нам удалось немного позаниматься важными делами — благо канун нового года стимулирует к итогам и планированию.
Одна из самых полезных вещей, которые быстро можно сделать (кроме сортировки по принципу business value vs. оценка времени на разработку, конечно) — это:
- Взять свой роадмап на период (квартал, полгода, год, просто набор самых важных фич которые вам “очень нужно” произвести)
- Убрать из него таймлайн и любые привязки ко времени (комитменты, запросы от клиентов, обещания стейкхолдерам..)
- По каждому эпику/истории/фиче задать себе один из двух вопросов (на выбор, с чем вам в данный момент комфортнее работать):
- Зачем мы это делаем? Как это облегчит жизнь нашему пользователю? (клиенту, сейлзам, CSM, — но первично все же юзеру)
- Если мы реализуем эту фичу в самом офигезно идеальном виде, как мы об этом узнаем? (подсказка: метрики).
Поскольку с “зачем” нам все же проще (специфика, в которую здесь вдаваться не буду), мы по каждому эпику написали список метрик, по которым мы явно можем отследить влияние (impact) нашей работы на жизнь живых пользователей. Например, уменьшится количество инцидентов/обращений по этому блоку функционала, увеличится количество создаваемых сущностей в этом разделе, снизится время на онбординг новых пользователей, снизятся затраты на поддержку вот этой фичи, увеличится доход с вот этого типа лицензий и т.д. У вас это могут быть метрики, характерные вашему продукту и бизнесу.
Самое главное — они легко рождаются в процессе таких размышлений. Сам процесс выглядит незатейливо: если у вас есть продуктовая команда, возьмите список фич и каждый отдельно выпишите по ним на стикеры свои метрики/признаки. Потом сравните ваши идеи, объедините их в кластеры, обсудите. Итоги впишите в документ (Confluence, GoogleDoc..). Пользуйтесь.
Что интересно — на первый взгляд это мало связано с приоритетами, но на самом деле связь прямая. Как только вы думаете о метриках, вы автоматически начинаете думать о пользовательском поведении и его изменении в результате вашей работы. Это очень тонкий момент, и очень продуктивный способ начать думать именно в таком ключе (не говоря уже о том, что вы получаете субпродукт в виде метрик, по которым можете впоследствии отслеживать эффективность/целесообразность внедрения функционала и улучшений (все же вы могли ошибаться, и это тоже бывает: build-measure-learn цикл никто не отменял).
Как только вы начинаете думать о поведении пользователей, вы можете увидеть новые способы удовлетворить их потребности, или же несколько фич в вашем бэклоге, направленные на решение одной и той же проблемы. В последнем случае вы можете от чего-то отказаться, или напротив — объединить несколько эпиков в один и сэкономить на оверхэдах в виде кик-офф презентаций, сдаче эпиков по Definition of Done, нагрузочному тестированию и т.п. Последний вариант звучит не очень lean, но вы можете быть уже далеко позади стадии поиска product-market fit, и искать способы оптимизации затрат в условиях высокого спроса, растущего рынка и быстрых зубастых конкурентов.
Пост, который меня вдохновил вспомнить об этом полезном занятии как раз перед каникулами: здесь. Все это не является исчерпывающим списком техник или перечнем факторов, которые нужно принять во внимание при планировании роадмапа. Тем не менее, на мой взгляд, метрики, привязанные к изменению поведения пользователя — одна из наиболее полезных вещей, которая должна быть в работе у РО/РМ всегда (елси вы делаете продукт, за который несете долгосрочную ответственность, а не разовый проект).
Желаю вам продуктивного подведения итогов и разумного взвешенного планирования — с вашими пользователями в уме ;)
(ссылки на другие материалы по разработке продуктов я собираю здесь: https://t.me/productdev)
