Большинство roadmaps продукта заброшены в пределах квартала от того как они написаны. Не потому что команды недисциплинированы, но потому что roadmap был построен на неправильных основаниях: фиксированные даты, списки функций, и желания stakeholders упакованные как план. Когда реальность неизбежно отличается — функция занимает дольше, потребность клиента меняется, конкурент двигается — roadmap становится выдумкой, и команды прекращают смотреть на него.
Roadmap который люди действительно следуют — не Gantt диаграмма одетая как стратегия продукта. Это живой документ который представляет текущее лучшее мышление команды о порядке в котором проблемы должны быть решены, структурирован быть честным о что известно и что нет.
Перед разработкой roadmap, стоит быть ясным о его целях. Roadmap делает три вещи: он коммуницирует направление (где мы идём и почему), он вынуждает приоритизацию (мы не можем делать всё, поэтому что идёт первым), и он создаёт основание для выравнивания (так что инженерия, дизайн, продажи, и поддержка все работают в направлении те же целей).
Roadmap не гарантирует даты доставки. Он не берёт на себя специфические функции. И он не заменяет потребность для текущего открытия. Если stakeholders обращаются с roadmap как обещание, это проблема процесса — не причина строить ложную точность в документе.
Самый долговечный формат roadmap для большинства команд — модель трёх горизонтов. Это честно об неопределённости: элементы в "Сейчас" взяты на себя, элементы в "Далее" спланированы но не заблокированы, и элементы в "Позже" направленно истинны но подлежат изменению по мере вы учитесь больше.
Заметьте что каждый элемент включает не просто что это, но почему это там. Roadmap без рациональности — просто список. Когда члены команды понимают почему каждый элемент был выбран, они могут делать лучшие решения когда вещи меняются — и они могут иметь более продуктивные разговоры когда клиент просит что-то что не на списке.
Roadmaps основанные на функциях ("построить X, построить Y, построить Z") создают опасную динамику: команда доставляет функции и вызывает завершённое, даже если функции не двигают метрики которые они должны были двигать. Функция была доставлена; проблема не была решена.
Roadmaps основанные на результатах переоформляют каждый элемент как цель: "Сократить время-к-первой-ценности для новых пользователей с 4 дней до менее 24 часов." Команда может затем решить — и переиспользовать — как достичь того результата. Эта структура также делает намного более лёгким деприоритизировать функцию когда вы открываете лучший способ достичь того же результата.
Менеджер продукта — владелец roadmap. Это означает что они ответственны за его содержание, его обновления, и его коммуникацию к stakeholders. Но владение не означает только авторство — лучшие roadmaps построены совместно, с входом от инженерии (на осуществимости и усилии), дизайна (на значениях пользовательского опыта), и команды обращённые к клиентам (на сигнале рынка).
Что ПМ должна сопротивляться — разработка roadmap посредством комитета. Stakeholders могут предоставить вход; они не должны иметь власть вето над отдельными элементами. ПМ синтезирует вход и делает звонки. Если процесс для достижения тех звонков доверен, продукции будут быть также.
Колонка Сейчас должна быть пересмотрена каждый спринт. Колонка Далее должна быть пересмотрена в начале каждого квартала, или когда бы значительное новое доказательство не прибыло (главный клиент churn, конкурент запускает что-нибудь релевантное, спринт открытия производит удивительный находку). Колонка Позже нужна переиспользование один раз в квартал — не рафинировать это, но подтвердить что направленные ставки всё ещё делают смысл.
Цель — roadmap который никогда не свеж достаточно быть позорным, но не обновляться настолько часто что создаёт беспокойство. Большинство команд ошибка к под-обновлению — roadmap отражает решения сделанные шесть месяцев назад и никто совершенно не знает когда это последнее время изменилось.
Roadmap будет следуем если — и только если — команда ему доверяет. То доверие происходит из трёх вещей: рациональность для каждого элемента видима и звучит, команда была вовлечена в строение это вместо того чтобы быть вручённый, и ПМ обновляет это пунктуально когда обстоятельства меняются вместо того чтобы претворить оригинальный план всё ещё держит.
Roadmap который обрабатывается как инструмент переговоров, или как документ произведённый удовлетворить executives, будет проигнорирован на уровне команды и обижен на уровне stakeholder. Roadmap который отражает подлинное мышление, реальные trade-offs, и честную неопределённость будет становиться инструментом люди достигают — потому что он действительно им помогает решить.