대부분의 제품 로드맵은 작성 후 1/4분기 내에 버려집니다. 팀이 규율이 없어서가 아니라, 로드맵이 잘못된 기초 위에 구축되었기 때문입니다: 고정 날짜, 기능 목록, 이해관계자 희망이 계획처럼 포장된 것. 현실이 필연적으로 벗어날 때 — 기능이 더 오래 걸리거나, 고객 필요가 변경되거나, 경쟁사가 움직일 때 — 로드맵은 허구가 되고, 팀들은 그것을 보는 것을 중단합니다.
사람들이 실제로 따르는 로드맵은 전략으로 포장된 간트 차트가 아닙니다. 팀의 현재 최고의 생각을 나타내는 살아있는 문서입니다, 문제를 해결해야 할 순서에 대해, 알려진 것과 알려지지 않은 것에 대해 솔직하도록 구조화되어 있습니다.
로드맵을 설계하기 전에, 목적에 대해 명확히 하는 것이 좋습니다. 로드맵은 세 가지를 합니다: 방향을 전달합니다(우리는 어디로 가고 왜), 우선순위를 강제합니다(우리는 모든 것을 할 수 없으므로 무엇이 먼저인가), 그리고 정렬을 위한 기초를 만듭니다(그래서 엔지니어링, 디자인, 판매, 지원이 같은 목표를 향해 일합니다).
로드맵은 배포 날짜를 보장하지 않습니다. 특정 기능에 커밋하지 않습니다. 그리고 지속적인 발견의 필요성을 대체하지 않습니다. 이해관계자들이 로드맵을 약속으로 대하면, 이것은 프로세스 문제입니다 — 문서에 거짓 정밀도를 구축할 이유가 아닙니다.
대부분의 팀에 가장 지속 가능한 로드맵 형식은 3지평 모델입니다. 불확실성에 대해 솔직합니다: "지금"의 아이템들은 커밋되고, "다음"의 아이템들은 계획되지만 잠기지 않으며, "나중"의 아이템들은 방향지만 배우면서 변할 것입니다.
각 아이템이 무엇인지뿐만 아니라 왜 거기에 있는지를 포함한다는 점에 주목합니다. 논리 없는 로드맵은 단지 목록입니다. 팀 구성원들이 각 아이템이 선택된 이유를 이해하면, 상황이 변할 때 더 나은 결정을 내릴 수 있습니다 — 그리고 고객이 목록에 없는 것을 요청할 때 더 생산적인 대화를 할 수 있습니다.
기능 기반 로드맵("X를 구축하고, Y를 구축하고, Z를 구축하세요")은 위험한 동력을 만듭니다: 팀은 기능을 배포하고 완료라고 부르며, 기능이 이동하도록 되어 있던 메트릭을 이동하지 않았더라도. 기능이 배포되었습니다; 문제는 해결되지 않았습니다.
결과 기반 로드맵은 각 아이템을 목표로 재구성합니다: "신규 사용자를 위한 첫 번째 가치까지의 시간을 4일에서 24시간 미만으로 줄이세요." 팀은 그 결과를 달성할 방법을 결정할 수 있습니다 — 그리고 재검토합니다. 이 구조는 또한 해당 결과에 도달하는 더 나은 방법을 발견할 때 기능을 우선순위에서 제외하기 훨씬 더 쉽게 만듭니다.
제품 관리자는 로드맵을 소유합니다. 이는 그들이 내용, 업데이트 및 이해관계자에 대한 커뮤니케이션에 책임이 있다는 의미입니다. 하지만 소유권은 단독 저작을 의미하지 않습니다 — 최고의 로드맵은 협력적으로 구축되며, 엔지니어링(가능성 및 노력), 디자인(사용자 경험 영향), 고객 대면 팀(시장 신호)의 의견이 포함됩니다.
PM이 저항해야 할 것은 위원회에서 로드맵을 설계하는 것입니다. 이해관계자들은 의견을 제공할 수 있습니다; 그들은 개별 아이템에 대한 거부권을 가져서는 안 됩니다. PM이 의견을 종합하고 호출합니다. 그 호출에 도달하는 프로세스가 신뢰할 수 있으면, 결과도 마찬가지입니다.
"지금" 열은 매 스프린트를 검토해야 합니다. "다음" 열은 각 분기가 시작될 때 또는 중요한 새 증거가 도착할 때마다(주요 고객이 떠났거나, 경쟁사가 관련된 것을 시작했거나, 발견 스프린트가 놀라운 발견을 생성했을 때) 검토되어야 합니다. "나후" 열은 한 번에 한 번, 분기에 한 번 방문할 필요가 있습니다 — 그것을 정제하는 것이 아니라, 방향 베팅이 아직 의미가 있는지 확인합니다.
목표는 로드맵이 부끄러워할 정도로 낡지 않았지만 불안을 만들 정도로 자주 업데이트되지 않은 것입니다. 대부분의 팀은 업데이트 부족 — 로드맵이 6개월 전 결정을 반영하고 아무도 마지막으로 언제 변경되었는지 모릅니다.
로드맵은 팀이 그것을 신뢰할 때만 따를 것입니다. 이 신뢰는 세 가지에서 옵니다: 각 아이템의 근거가 보이고 건전합니다, 팀이 아이템을 건넸을 때가 아닌 구축에 관여했으며, PM이 원래 계획이 아직 유지된다고 가장하지 않고 상황이 변할 때 즉시 업데이트합니다.
협상 도구로 취급되거나 경영진을 만족시키기 위해 생성되는 로드맵은 팀 수준에서 무시되고 이해관계자 수준에서 거부됩니다. 진정한 사고, 실제 절충안, 정직한 불확실성을 반영하는 로드맵은 도구가 될 것입니다 — 사람들이 손을 뻗을 것입니다 — 사실 그들이 결정하는 것을 돕기 때문입니다.