제품 로드맵 템플릿, 복사해서 채울 필드 여섯 가지

제품 로드맵 템플릿은 한 행이 항목 하나이고, 각 열이 계속 채워 두겠다고 약속한 필드인 짧은 표다. 대부분의 작은 팀에 잘 맞는 버전은 여섯 개 필드로 이루어진다. 결과, 요청한 사람, 상태, 담당자, 확신도, 검토일이다. 내려받는 템플릿에서 흔히 보이는 스윔레인, 스토리 포인트, 분기 열 같은 나머지는 선택 사항이며, 로드맵이 갱신되지 않게 되는 이유가 되는 경우가 많다.

제품 로드맵 템플릿에는 무엇이 들어가야 하는가

읽는 사람이 결정을 내리는 데 쓰는 필드만 넣고, 누가 읽는지 말할 수 있을 때만 필드를 추가하라. 결과는 그 행이 존재하는 이유다. 출처는 고객이 자신의 요청을 그 안에서 찾을 수 있게 해 준다. 상태는 작업이 진행 중인지 알려 준다. 담당자는 물어볼 사람이다. 확신도는 예상이 약속으로 읽히는 것을 막고, 검토일은 행이 낡아 가는 것을 막는다.

팀이 원한다면 추가할 만한 것이 두 가지 있다. 표 옆에 두는 “하지 않을 일” 목록은 무엇을 왜 하지 않기로 했는지 기록해서 분기마다 같은 논쟁을 반복하지 않게 해 준다. “마지막 수정” 열은 행을 언제 고쳤는지 기록해서, 읽는 사람이 최신 로드맵과 버려진 로드맵을 구분할 수 있게 한다.

첫 버전에서는 뺄 필드가 있다. 검토일 외의 날짜, 공수 추정, 스토리 포인트, 매출 예측이다. 이런 것은 계획 문서에 속한다. 거기서는 아무도 그것을 약속으로 읽지 않으니 자유롭게 바뀔 수 있다.

채워진 제품 로드맵 템플릿은 어떻게 생겼는가

가상의 할 일 앱을 제품으로 삼아 채운 표다. 항목은 모두 지어낸 것이고, 상태 열은 값을 세 가지만 쓴다.

두 행이 핵심을 보여 준다. “모바일 오프라인 모드”는 담당자가 없고 확신도가 낮은데, “고민하고 있다”를 정직하게 말하는 방식이다. “마감일 일괄 편집”은 지우지 않고 종료로 두었기 때문에, 요청했던 고객이 그 항목이 어디로 갔는지 여전히 찾을 수 있다.

순수한 텍스트를 선호한다면 같은 표를 저장소의 Markdown 파일로 두어도 된다. 작업 옆에서 버전 관리가 된다.

| Outcome | Source | Status | Owner | Confidence |
|---|---|---|---|---|
| Keep the last filter | 14 requests | Building | Dana | Committed |
| Company SSO sign-in | 9 requests | Planned | Marcus | Forecast |

템플릿은 어떤 형식을 써야 하는가

항목이 열 개 이하이고 읽는 사람이 세부 내용을 원한다면 표를 써라. 방향을 자주 바꾸고 날짜를 해명하고 싶지 않다면 Now, Next, Later의 세 열을 써라. Now/Next/Later 레이아웃은 Atlassian의 제품 로드맵 안내서에 타임라인형, 주제 기반 레이아웃과 함께 설명되어 있다.

위의 표와 세 열짜리 보드는 같은 데이터를 담는다. 로드맵 안에서 일하는 사람에게는 표가 낫고, 흘끗 보기만 하는 사람에게는 보드가 낫다. 제품 로드맵 예시는 현실적인 항목과 함께 여섯 가지 형식을 보여 주고 각각이 어떻게 실패하는지 설명하므로, 필드를 정한 뒤에 레이아웃을 고를 수 있다.

추측하지 않고 템플릿을 채우려면

이미 가진 요청에서 시작하고 결과는 마지막에 써라. 열려 있는 요청을 설명하는 문제별로 묶어 개수를 세고, 그 개수를 출처 열에 넣는다. 출처가 없는 행은 의견이다. 의견도 허용되지만 의견으로 보여야 한다.

그다음 고객에게 설명할 수 있는 규칙으로 행의 순위를 정한다. 기능 요청 우선순위는 점수 매기는 방법과 추천 수만으로는 왜 오판하게 되는지를 다룬다. 행의 순서는 “무엇이 먼저인가”에 대한 답이고, 상태 열은 “지금 무슨 일이 일어나고 있는가”에 대한 답이다.

확신도는 정직하게 써라. 확정은 그 기간 안에 출시하지 못하면 팀이 놀랄 만한 행이다. 예상은 무언가 바뀌지 않는 한 그대로 가는 계획이다. 탐색 중은 약속이 전혀 없다는 뜻이며, 탐색 중인 행을 고객에게 보여 주는 로드맵이라면 그 단어가 무슨 뜻인지 밝혀야 한다.

템플릿은 얼마나 자주 갱신해야 하는가

항목의 상태가 바뀔 때마다 갱신하고, 검토일마다 모든 행을 살펴라. 갱신이 별도의 잡무가 되면 로드맵은 낡는다. 그러니 작업이 이미 있는 곳에 두어라. 이슈 트래커가 단일 진실 공급원이라면 라벨이 상태 열을 움직이게 할 수 있고, 아무도 다시 입력하지 않는다. 공개 로드맵이 정직하게 유지되는 방법은 Changeloop이 쓰는, 라벨 하나가 열 하나에 대응하는 구성을 보여 준다.

행이 출시되면 요청한 사람들에게 알려라. 어떤 템플릿 필드도 대신해 줄 수 없는 부분이며, 출처 열을 남겨 두는 이유이기도 하다. 고객 피드백 루프는 요청에서 공지까지의 전체 경로를 설명한다.

템플릿을 공개해도 되는가

고객이 자신의 요청이 전해졌다는 것을 보게 하고 싶다면 축소한 버전을 공개하라. 공개용 템플릿은 결과와 상태를 남기고, 담당자와 확신도와 검토일은 뺀다. 영업 통화에서 옹호할 수 없는 항목도 뺀다. 최신 상태로 유지되는 짧은 목록이 조용해진 긴 목록보다 신뢰에 더 도움이 된다. ProdPad의 템플릿 페이지는 한 공급업체가 자신들의 템플릿을 어떻게 구성하는지 보여 준다.

FAQ

제품 로드맵 템플릿이란 무엇인가? 결과, 상태, 담당자, 확신도처럼 로드맵 항목마다 고정된 필드를 갖춘, 다시 쓸 수 있는 표나 보드다. 복사해서 항목마다 한 행씩 채우고 계속 갱신한다.

제품 로드맵에는 어떤 열이 있어야 하는가? 최소한 결과, 상태, 담당자다. 항목이 몇 개를 넘으면 요청의 출처, 확신도, 검토일을 추가하라.

제품 로드맵에 날짜를 넣어야 하는가? 대부분의 팀에는 검토일만 있으면 된다. 달력의 날짜는 영업과 고객이 인용하는 약속이 되므로, 확신도 라벨과 Now, Next, Later 같은 기간으로 대신하라.

로드맵을 스프레드시트나 Markdown 파일로 관리해도 되는가? 된다. 함께 편집하는 팀에는 스프레드시트가, 버전 관리를 원하는 팀에는 저장소의 Markdown 표가 맞다. 갱신이 별도의 잡무가 되지 않도록 작업이 이미 추적되는 곳을 골라라.

이 글의 기술적 내용은 독립적으로 검토되지 않았습니다. 잘못된 부분이 있으면 알려 주세요. 바로잡겠습니다.

changeloop 관련 페이지: 개발자 문서, changelog 예시