성과 기반 로드맵

Outcome-based Roadmap

산출물

만들 기능의 이름 대신 달성할 결과를 숫자로 적어 두고, 거기 닿는 방법은 팀에 열어 두는 로드맵 형식입니다.

등장 배경

로드맵 칸에 기능 이름을 적으면 분기가 끝났을 때 판정할 수 있는 것이 하나뿐입니다. 만들었는지 아닌지입니다. 다섯 칸을 모두 냈다면 그 분기는 성공으로 기록되고, 그것으로 무엇이 달라졌는지는 아무도 묻지 않습니다.

페이지덱이 지난 분기에 그렇게 끝냈습니다. 달력 위에 일정을 못 박는 타임라인 로드맵에 다섯 항목이 적혀 있었고 다 나갔습니다. 발표 자리에서 규원이 "그래서 뭐가 나아졌죠" 하고 물었을 때 아무도 답하지 못했습니다. 가입 30일 뒤에 남아 있는 팀의 비율은 분기 시작과 똑같은 30퍼센트였습니다.

순서가 뒤집혀 있었던 것입니다. 만들 것을 먼저 정하고 그것이 어디에 좋은지를 나중에 갖다 붙였으니, 도중에 더 싸게 같은 결과를 내는 방법이 보여도 칸을 바꿀 근거가 없었습니다. 성과 기반 로드맵은 칸에 결과를 적고 방법을 비워 두는 형식입니다. 남아 있는 팀 비율을 30퍼센트에서 38퍼센트로 옮기는 것이 칸의 내용이 되고, 거기 닿는 수단은 분기 안에서 바뀔 수 있게 둡니다.

구성 항목

칸 하나는 기능 이름이 아니라 숫자 한 줄로 시작하고, 그 아래에 그 숫자에 닿기 위한 정보 네 가지가 붙습니다.

  1. 성과 문장 — 현재값과 목표값과 시점을 한 문장에 담습니다. "리텐션 개선" 은 성과 문장이 아니고, "남아 있는 팀 비율을 4분기 말까지 30퍼센트에서 38퍼센트로" 는 성과 문장입니다. 리텐션은 쓰던 사용자가 계속 돌아오는 정도입니다.
  2. 이 숫자를 고른 이유 — 회사의 대표 지표와 이 칸이 어떻게 이어지는지 적습니다. 북극성 지표가 주간 문서 편집자 수라면, 남아 있는 팀 비율이 그 앞단이라는 설명이 여기 들어갑니다.
  3. 가설 목록 — 그 숫자를 올릴 수단 후보를 두세 개 적고, 약속이 아니라는 표시를 함께 답니다. 첫 주 안내 흐름을 다시 만드는 안과 팀 초대를 쉽게 하는 안을 나란히 적어 두면 하나가 빠져도 칸 전체가 흔들리지 않습니다.
  4. 확인 방법과 중간 기준점 — 숫자를 어디서 읽을지와 분기 중간에 무엇이 되어 있어야 하는지입니다. 마일스톤은 진척을 확인하려고 중간에 박아 두는 기준점인데, 여기서는 날짜가 아니라 상태로 적습니다. 8월 말까지 첫 주 안내 흐름이 신규 팀 절반에 노출된 상태가 그런 예입니다.
  5. 담당과 확신도 — 이 칸을 들고 있는 사람과, 목표값에 닿을 가능성을 높음·중간·낮음으로 적습니다.

칸을 만들기 전에 확인할 조건이 하나 있습니다. 그 숫자를 팀이 스스로 움직일 수 있어야 합니다. 리텐션이 열 갈래 요인에 걸려 있고 그중 둘만 제품 팀 손에 있다면, 그 칸은 책임 소재를 흐리는 쪽으로만 작동합니다. 가격을 올려 숫자가 내려간 분기에도 칸을 들고 있는 사람이 설명을 해야 합니다.

작성자와 독자

프로덕트 매니저가 쓰고 분기마다 숫자를 다시 읽어 갱신합니다. 프로덕트 매니저는 무엇을 왜 만들지 정하고 출시까지 책임지는 역할입니다. 갱신할 때 고치는 것은 가설 목록이고 성과 문장은 분기 중간에 바꾸지 않습니다. 숫자가 안 움직인다고 목표값을 내리면 이 형식의 유일한 장치가 사라집니다.

읽는 쪽은 넷이고 각자 다른 줄을 봅니다.

  1. 만드는 팀은 가설 목록을 봅니다. 수단이 후보로 적혀 있으니 더 싼 방법을 제안할 자리가 생깁니다.
  2. 경영진은 성과 문장만 봅니다. 규원이 이사회 자료에 옮기는 것도 이 줄입니다. 기능 이름이 없어도 회사가 이번 분기에 무엇을 사려는지가 드러납니다.
  3. 세일즈와 고객 성공은 이 형식을 가장 불편해합니다. 고객이 묻는 것은 기능 이름인데 문서에는 숫자만 있습니다. 그래서 가설 목록 중 확신도가 높음인 항목만 대외적으로 언급하는 규칙을 함께 둡니다.
  4. 목표를 함께 쓰는 조직은 OKR과 겹치는지 봅니다. 목표와 그것을 확인할 핵심 결과로 나눠 관리하는 방식인데, 두 문서에 같은 숫자가 다른 값으로 적히는 일이 잦습니다.

읽는 쪽이 넷이라 이해관계자를 한 번 교육해야 굴러갑니다. 결과에 영향을 받거나 영향을 주는 사람들인데, 기능 목록을 기대하고 문서를 연 쪽은 숫자만 있는 칸을 계획 없음으로 읽습니다.

실무 용례

"이번 분기 칸은 기능이 아니라 숫자입니다. 30일 리텐션을 30에서 38로 올리는 게 목표예요."

무엇을 만들지는 열려 있고 무엇이 달라져야 하는지가 정해졌다는 뜻입니다.

"그 기능을 하겠다고 약속한 적은 없습니다. 숫자를 올리겠다고 했고 방법은 세 가지를 보고 있어요."

가설 목록에 있는 항목을 확정된 계획으로 읽지 말아 달라는 정정입니다.

"이 숫자는 우리가 못 움직여요. 절반이 가격 정책에 걸려 있는데요."

팀 손 밖의 요인이 커서 칸으로 삼기에 맞지 않다는 지적입니다.

페이지덱은 그 발표 이후로 이 형식을 한 칸에만 얹었습니다. 지현이 남아 있는 팀 비율을 성과 문장으로 적고 가설 세 개를 달았는데, 그중 첫 주 안내 흐름을 다시 만드는 안이 6주 만에 숫자를 34퍼센트까지 올렸습니다. 나머지 둘은 착수하지 않았고, 분기 끝에 그것을 지우는 일이 실패로 기록되지 않았습니다.

흔한 오해

만들 것을 정하지 않고 분기를 시작하는 형식이라고 보는 경우가 가장 많습니다. 칸에 기능 이름이 없으니 자연스러운 오해입니다. 실제로는 가설 목록이 붙어 있어서 시작 시점의 후보는 명확하고, 달라지는 것은 그 후보가 약속인지 아닌지뿐입니다. 이 오해를 그대로 두면 팀은 분기 첫 2주를 무엇을 할지 고르는 데 쓰고, 그 2주가 매 분기 반복됩니다.

숫자를 적어 두면 책임이 저절로 생긴다고 보는 것도 흔합니다. 목표값과 시점이 있으니 그렇게 보입니다. 하지만 책임은 통제와 짝을 이룰 때만 성립합니다. 팀이 움직일 수 없는 숫자를 칸에 적어 두면 분기 끝에 남는 것은 학습이 아니라 평가입니다.

자주 헷갈리는 용어

용어칸에 무엇을 적는가성과 기반 로드맵과의 차이
테마 기반 로드맵관련 있는 과제를 묶은 주제. "처음 쓰는 팀이 혼자서 자리 잡게 하기" 처럼 방향을 적습니다같은 일을 문제 쪽에서 묶고 숫자는 요구하지 않습니다. 도입 문턱이 낮고 기능 이름을 기대하는 상대에게 설명하기도 쉽지만, 분기 끝에 잘 됐는지 판정할 근거가 남지 않습니다. 테마 안에 성과 문장을 넣어 겹쳐 쓰는 팀도 많습니다

같이 보면 좋은 페이지

마지막 업데이트 2026-09-16