대부분의 제품 로드맵은 작성하고 한 분기도 지나지 않아 버려집니다. 팀의 규율이 부족해서가 아니라, 로드맵이 잘못된 토대 위에 만들어졌기 때문입니다. 고정된 날짜, 기능 목록, 이해관계자의 바람을 계획인 양 포장한 것이 그 토대입니다. 기능 개발이 더 오래 걸리거나, 고객의 니즈가 바뀌거나, 경쟁사가 움직이는 식으로 현실이 필연적으로 계획에서 벗어나면 로드맵은 허구가 되고, 팀은 더 이상 로드맵을 들여다보지 않습니다.
사람들이 실제로 따르는 로드맵은 제품 전략으로 포장한 간트 차트가 아닙니다. 어떤 순서로 문제를 해결할지에 대한 팀의 현재 최선의 생각을 담은 살아 있는 문서이며, 무엇이 확실하고 무엇이 불확실한지 솔직하게 드러내도록 구성됩니다.
로드맵을 설계하기 전에 그 목적을 분명히 해 둘 필요가 있습니다. 로드맵은 세 가지 일을 합니다. 방향을 전달하고(어디로 가며 왜 가는가), 우선순위를 강제하고(모든 것을 할 수는 없으니 무엇이 먼저인가), 정렬의 기반을 만듭니다(엔지니어링, 디자인, 영업, 지원이 모두 같은 목표를 향해 일하도록).
로드맵은 출시 날짜를 보장하지 않습니다. 특정 기능을 확약하지도 않습니다. 지속적인 탐색(discovery)의 필요성을 대체하지도 않습니다. 이해관계자가 로드맵을 약속으로 받아들인다면 그것은 프로세스의 문제이지, 문서에 거짓 정밀함을 담아야 할 이유가 아닙니다.
대부분의 팀에 가장 오래 유지되는 로드맵 형식은 세 단계 시간 단위 모델입니다. 불확실성에 솔직한 구조입니다. "지금"의 항목은 확정된 것, "다음"의 항목은 계획되었지만 고정되지 않은 것, "나중"의 항목은 방향은 맞지만 더 배우면서 바뀔 수 있는 것입니다.
각 항목이 무엇인지뿐 아니라 왜 거기 있는지도 담겨 있다는 점에 주목하세요. 근거 없는 로드맵은 그저 목록입니다. 팀원들이 각 항목이 선택된 이유를 이해하면 상황이 바뀔 때 더 나은 결정을 내릴 수 있고, 고객이 목록에 없는 것을 요청할 때도 더 생산적인 대화를 나눌 수 있습니다.
기능 기반 로드맵("X를 만들고, Y를 만들고, Z를 만든다")은 위험한 역학을 만듭니다. 팀은 기능을 출시하고 끝났다고 말하지만, 그 기능이 움직이기로 했던 지표는 움직이지 않을 수 있습니다. 기능은 전달되었지만 문제는 해결되지 않은 것입니다.
성과 기반 로드맵은 각 항목을 목표로 다시 정의합니다. "신규 사용자가 첫 가치를 얻기까지 걸리는 시간을 4일에서 24시간 미만으로 줄인다." 그러면 팀은 그 성과를 어떻게 달성할지 스스로 정하고, 필요하면 다시 정할 수 있습니다. 이 구조는 같은 성과에 도달하는 더 나은 방법을 발견했을 때 기능의 우선순위를 낮추기도 훨씬 쉽게 해 줍니다.
로드맵은 제품 매니저가 책임집니다. 내용, 업데이트, 이해관계자와의 소통에 책임을 진다는 뜻입니다. 하지만 책임이 혼자 쓴다는 뜻은 아닙니다. 가장 좋은 로드맵은 엔지니어링(실현 가능성과 공수), 디자인(사용자 경험에 미치는 영향), 고객 접점 팀(시장 신호)의 의견을 받아 함께 만듭니다.
PM이 경계해야 할 것은 위원회식으로 로드맵을 설계하는 것입니다. 이해관계자는 의견을 낼 수 있지만, 개별 항목에 거부권을 가져서는 안 됩니다. PM은 의견을 종합해 결정을 내립니다. 그 결정에 이르는 과정이 신뢰받는다면 결과물도 신뢰받습니다.
"지금" 열은 스프린트마다 검토해야 합니다. "다음" 열은 분기가 시작될 때, 또는 중요한 새 근거가 들어올 때마다(주요 고객이 이탈했을 때, 경쟁사가 관련 제품을 출시했을 때, 탐색 스프린트에서 뜻밖의 발견이 나왔을 때) 검토해야 합니다. "나중" 열은 분기에 한 번 다시 보면 됩니다. 다듬기 위해서가 아니라 방향성 베팅이 여전히 타당한지 확인하기 위해서입니다.
목표는 민망할 정도로 낡지는 않되, 불안을 일으킬 만큼 자주 바뀌지도 않는 로드맵입니다. 대부분의 팀은 업데이트가 부족한 쪽으로 기웁니다. 로드맵이 6개월 전의 결정을 반영하고 있고, 마지막으로 언제 바뀌었는지 아무도 정확히 모릅니다.
로드맵은 팀이 신뢰할 때, 그리고 신뢰할 때만 지켜집니다. 그 신뢰는 세 가지에서 나옵니다. 각 항목의 근거가 눈에 보이고 타당할 것, 팀이 로드맵을 건네받는 데 그치지 않고 만드는 과정에 참여했을 것, 그리고 상황이 바뀌면 PM이 원래 계획이 아직 유효한 척하지 않고 신속하게 업데이트할 것입니다.
협상 도구로 취급되거나 경영진을 만족시키려고 만든 로드맵은 팀 차원에서는 무시되고 이해관계자 차원에서는 반감을 삽니다. 진짜 고민, 실제 트레이드오프, 솔직한 불확실성을 담은 로드맵은 사람들이 스스로 찾는 도구가 됩니다. 결정을 내리는 데 실제로 도움이 되기 때문입니다.