one-team-one-roadmap 통합 설계하기(Design a one-team-one-roadmap consolidation)

Shadow roadmap은 제품 조직의 조용한 세금이다

영업은 약속을 했고, CS는 기대치를 쌓아 두었고, 마케팅은 출시 일정을 정했고, 제품팀은 그들과 다른 roadmap을 갖고 있을 때, 조직은 사실상 다섯 개의 shadow roadmap으로 움직입니다. 그리고 그 충돌은 고객 escalations, 망가진 출시, 서로를 탓하는 post-mortem으로 표면화됩니다. 하나의 artifact, 하나의 ownership model, 하나의 truth source로 통합하는 작업은 product ops 리더가 할 수 있는 가장 레버리지 높은 개입 중 하나입니다.

이 프롬프트의 작동 방식

이 프롬프트는 product roadmap만이 유일한 roadmap인 척하지 않고, 오늘 실제로 존재하는 모든 shadow roadmap(sales sheet, CS log, marketing calendar, engineering backlog)을 먼저 드러내는 데서 시작합니다. 그다음 diff matrix를 통해 통합이 해결해야 할 세 가지 실패 모드를 표시합니다. Phantom commitment(외부에 약속했지만 product roadmap에는 없음), timing conflict(같은 항목에 날짜가 다름), ownership conflict(두 팀이 같은 일을 자신이 주도한다고 생각함)입니다.

병합된 roadmap은 now / next / later / not doing의 네 컬럼 구조를 사용하고, confidence level까지 붙여 무엇이 확정이고 무엇이 방향성인지 이해관계자가 구분할 수 있게 합니다. 비타협 규칙("sales와 CS는 이 roadmap에 없는 것을 약속할 수 없다")은 통합이 한 분기 안에 다시 다섯 개의 shadow sheet로 분해되지 않게 하는 governance 계층입니다.

언제 사용할까

• Sales가 product roadmap에 없는 기능을 이미 약속했을 때
• CS escalation마다 제품팀 누구도 소유하지 않는 약속 날짜가 등장할 때
• 준비되지 않은 기능을 marketing이 출시하려 할 때
• 새 제품 리더가 roadmap fragmentation이 명확한 조직을 인수받았을 때
• 이사회나 CEO가 왜 회사에 우선순위가 네 가지씩 있는 것처럼 보이냐고 물을 때

흔한 함정

• Google Doc 하나로 통합하고 떠나는 것. 주간 sync, 변경 승인, 공개된 not-doing 목록 같은 governance 계층이 있어야 통합이 유지됩니다.
• 이메일로 갈등을 해결하려는 것. Sales와 product 사이의 갈등은 양쪽 리드가 함께 있는 회의에서 해결해야지, 아무 결정도 내려지지 않는 async thread에서 해결되지 않습니다.
• "not doing" 목록을 내부에만 두는 것. 목록이 공개되거나 관련 이해관계자와 공유되지 않으면, sales는 이미 죽인 항목도 계속 약속합니다.

참고 자료

• The Product Strategy Stack — Reforge
• Product Strategy Overview — Silicon Valley Product Group
• OKRs — Atlassian
• The Linear Method — Linear