Как составить product roadmap по отзывам клиентов

Как составить product roadmap, сводится к следующему: соберите то, о чём клиенты уже просили, сгруппируйте это по проблеме, стоящей за каждым запросом, ранжируйте группы по правилу, которое можете объяснить, решите, насколько вы уверены в каждой, и опубликуйте результат в формате, подходящем читателю. Порядок важен. Команды, которые начинают с раскладки и заполняют её идеями, получают документ, который выглядит законченным и не несёт доказательств. Команды, которые начинают с запросов, получают более короткий roadmap, где за каждой строкой есть причина.

С чего начать, когда составляете product roadmap?

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

Запросы редко приходят в пригодной форме. «Добавьте интеграцию со Slack» и «уведомляйте мою команду, когда задача меняется» могут оказаться одной потребностью. Поэтому следующий шаг это группировка, и поэтому стоит завести трекер, который объединяет дубликаты; как это делается, объясняет статья дублирующиеся запросы на функции. Помните и о том, что тикеты поддержки и запросы на функции несут сигналы разного рода, и roadmap, построенный только на одном из них, будет перекошен.

Как превратить запросы в пункты product roadmap?

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

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

Как решить, что делать первым?

Выберите одно правило оценки, запишите его и применяйте к каждому пункту. Чаще всего берут RICE, где оцениваются охват, влияние, уверенность и трудозатраты; первоисточник это статья Intercom о RICE. Столь же хорошо работает более простое правило, если вы можете его объяснить: число запросов, взвешенное по тому, активный ли платящий аккаунт просит, и делённое на грубую оценку трудозатрат.

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

Насколько вы уверены в каждом пункте?

Пометьте каждый пункт уровнем уверенности, прежде чем что-либо публиковать. Хватает простой шкалы из трёх значений: committed значит, что команда удивилась бы, не выпусти она это в заданном окне, forecast значит, что это план, если что-то не изменится, а exploring значит, что никакого обещания нет.

Этот единственный столбец предотвращает большую часть вреда от roadmap. Без него клиент читает пункт exploring как обязательство, отдел продаж его цитирует, и через квартал это превращается в жалобу. Эссе Марти Кагана об альтернативе roadmap излагает основной довод: список функций с датами это список догадок, выданных за планы, а лекарство в том, чтобы прямо говорить, что вам известно.

Какой формат выбрать для roadmap?

Раскладку выбирайте последней, исходя из читателя. Клиентам, которые спрашивают, услышали ли их, нужен короткий публичный вид. Руководству, которое спрашивает, зачем эта работа, нужны темы или результаты. Команде, которая ежемесячно меняет направление, хорошо подходит Now, Next и Later без дат. Статья примеры product roadmap показывает шесть форматов с реалистичными пунктами и то, как каждый из них ломается, а шаблон product roadmap даёт поля для копирования, когда вы определились.

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

Как не дать roadmap устареть?

Назначьте каждой строке дату пересмотра и держите roadmap там, где уже идёт работа. Roadmap, который обновляют вручную в отдельном инструменте, устаревает, потому что ничья повседневная работа его не включает. Если каждый столбец соответствует метке на задаче, roadmap меняется вместе с меткой.

Замыкайте петлю, когда пункт выпущен. Те, кто просил, должны об этом узнать, и обычное место для этого запись в changelog; весь путь описан в статье петля обратной связи клиента. Если вы решили что-то не делать, скажите и об этом. Ясный отказ полезен тому, кто просил, а формулировки разбирает статья отказать в запросе на функцию.

FAQ

Каковы шаги, чтобы составить product roadmap? Соберите запросы и данные, сгруппируйте их по проблеме, ранжируйте по записанному правилу, пометьте каждый пункт уровнем уверенности, выберите формат для читателя и назначьте дату пересмотра. Старт с доказательств делает roadmap коротким и защищаемым.

На чём должен основываться product roadmap? На запросах клиентов, темах из поддержки, данных об использовании и вашей стратегии, причём в порядке того, как часто их пропускают. Roadmap, за строками которого нет источника, это список желаний.

На какой срок должен рассчитываться product roadmap? Достаточно долгий, чтобы быть полезным, и достаточно короткий, чтобы в него верили. Для многих небольших команд это текущий квартал в деталях и один-два следующих в виде тем. Всё, что дальше, относится к разделу «later» без дат.

Кто должен участвовать в составлении product roadmap? Решает владелец продукта, инженеры проверяют осуществимость и трудозатраты, а поддержка и продажи приносят запросы и темы, которые они слышат. Клиенты видят результат в публичной версии, но не редактируют его.

Технические утверждения в этой статье не проходили независимую проверку. Если здесь что-то не так, сообщите нам, и мы исправим.

По теме на changeloop: Документация для разработчиков, Примеры changelog