테마 기반 로드맵

로드맵 칸에 기능 이름을 적으면 그 이름이 밖에서 약속으로 읽힙니다. 안에서는 후보였던 것이 밖에서는 예정된 상품이 됩니다. 쓴 사람은 방향을 전달하려 했는데 읽은 사람은 목록을 받아 갑니다.

페이지덱이 고객에게 공개하는 로드맵에서 그 일이 생겼습니다. 이번 분기와 다음 분기 칸에 기능 이름 열두 개가 적혀 있었는데, 계약을 앞둔 고객이 그중 두 개를 짚어 계약서 부록에 넣어 달라고 했습니다. 수아가 난처해진 이유는 그 두 개가 나쁜 기능이어서가 아니라, 같은 문제를 더 싸게 푸는 방법이 나오면 갈아 끼울 항목이었기 때문입니다. 계약서에 들어가면 그 교체가 계약 위반이 됩니다.

문제는 칸의 크기였습니다. 기능 하나가 칸 하나를 차지하면 그 기능이 곧 계획이 되어 버립니다. 테마 기반 로드맵은 칸을 한 단계 크게 잡아 이 문제를 비켜 갑니다. "처음 쓰는 팀이 혼자서 자리 잡게 하기" 같은 묶음을 칸에 넣고, 그것을 어떻게 이룰지는 안에 후보로 둡니다. 방향은 그대로 전달되면서 개별 기능이 약속으로 굳지 않습니다. 날짜를 세 칸으로 바꾸는 나우-넥스트-레이터가 시간 축의 정밀도를 낮추는 방식이라면, 이쪽은 항목 축의 정밀도를 낮추는 방식입니다.

칸 하나는 주제 이름으로 시작하고, 그 아래에 다섯 가지가 붙습니다.

1. 테마 이름 — 기능 묶음의 이름이 아니라 사용자가 놓인 상태로 적습니다. "온보딩 개선" 은 우리 쪽 작업 이름이고, "처음 쓰는 팀이 혼자서 자리 잡게 하기" 는 밖에서 읽어도 뜻이 통합니다. 이름 하나로 이 형식의 절반이 정해집니다.
2. 풀려는 문제 — 이 묶음이 왜 이번 분기에 있는지 적습니다. "새로 만든 팀의 절반이 두 번째 문서를 만들기 전에 멈춘다" 처럼 관찰된 사실을 적으면 나중에 항목을 갈아 끼울 기준이 됩니다.
3. 후보 항목 — 이 테마를 이룰 수단을 두세 개 적고 후보라는 표시를 함께 답니다. 첫 문서 안내를 다시 만드는 안, 샘플 문서를 미리 넣어 주는 안, 초대 흐름을 줄이는 안을 나란히 두는 식입니다. 여기 적힌 것이 바뀌는 것은 정상입니다.
4. 됐다고 볼 기준 — 이 테마가 끝났다고 부를 조건을 한 줄로 적습니다. 두 번째 문서를 만드는 팀의 비율을 절반에서 70퍼센트로처럼 숫자와 시점이 있어야 분기 끝에 판정할 수 있습니다.
5. 시기 구간과 확신도 — 분기나 세 칸 가운데 하나로 자리를 표시하고, 이대로 될 가능성을 높음·중간·낮음으로 답니다. 확신도가 낮음인 테마를 영업이 계약서에 쓰지 않게 하는 것이 이 칸의 역할입니다.

담당과 지금 상태도 함께 답니다. 상태는 아직 안 봄, 살펴보는 중, 만드는 중 셋이면 충분합니다. 진척을 확인하는 중간 기준점인 마일스톤은 테마가 아니라 그 안의 항목에 답니다. 테마에 날짜를 박으면 칸을 크게 잡은 효과가 사라집니다.

한 분기에 테마는 셋을 넘기지 않습니다. 다섯 개를 올리면 어느 것도 끝나지 않은 채 분기가 지나가고, 그 표를 본 사람은 다음 분기부터 테마 이름을 읽지 않습니다.

프로덕트 매니저가 쓰고 분기에 한 번 테마를 다시 고릅니다. 프로덕트 매니저는 무엇을 왜 만들지 정하고 출시까지 책임지는 역할입니다. 분기 중간에 고치는 것은 후보 항목이고 테마 이름과 풀려는 문제는 그대로 둡니다. 테마가 매달 바뀌면 그것은 테마가 아니라 할 일 목록입니다.

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

1. 만드는 팀은 후보 항목을 봅니다. 수단이 후보로 적혀 있으니 조사 결과를 들고 와 항목을 바꿀 자리가 있습니다.
2. 디자인과 조사 쪽은 테마 이름을 조사 범위로 씁니다. 기능 하나를 검증하는 대신 그 테마 안에서 사람들이 어디서 막히는지를 보게 됩니다.
3. 경영진은 테마 이름과 됐다고 볼 기준만 봅니다. 규원이 이사회 자료에 옮기는 것도 이 두 줄입니다.
4. 세일즈와 고객 성공은 대외 공개판을 씁니다. 개별 기능 이름이 없으니 고객이 특정 항목을 계약서에 넣자는 대화 자체가 줄어듭니다.

밖으로 낼 때는 확신도가 낮음인 테마를 뺍니다. 확신이 가장 낮은 칸이 밖에서 가장 크게 오해됩니다.

"그건 테마 안의 후보예요. 이 테마를 그 기능으로 푼다고 정한 건 아닙니다."

칸에 적힌 항목이 확정 계획이 아니라는 정정입니다.

"테마 이름을 우리 작업 이름이 아니라 고객이 겪는 상태로 바꿔 주세요."

밖에서 읽어도 뜻이 통하는 이름으로 고치자는 요청입니다.

"이번 분기 테마가 다섯 개인데 팀이 둘이에요. 둘로 줄입시다."

동시에 움직일 수 있는 수를 넘겼으니 문서가 현실과 어긋났다는 지적입니다.

페이지덱은 그 계약 건 이후로 대외 공개판을 테마로 바꿨습니다. 지현이 세 칸에 있던 항목들을 테마 셋으로 묶었고, 첫 이름을 "처음 쓰는 팀이 혼자서 자리 잡게 하기" 로 적었습니다. 그 안에 후보 세 개가 들어갔습니다.

한 달 뒤 조사에서 첫 문서 안내보다 샘플 문서를 미리 넣어 주는 쪽이 효과가 크다고 나왔습니다. 테마 이름은 그대로 두고 안의 순서만 바꿨습니다. 수아는 고객에게 다시 설명하지 않았고, 규원의 이사회 자료도 고칠 것이 없었습니다.

기능 이름을 뭉개서 약속을 피하는 포장이라고 보는 경우가 가장 많습니다. 구체적인 것이 사라졌으니 영업 쪽에서 특히 그렇게 느낍니다. 하지만 안에는 후보 항목이 적혀 있어 팀이 무엇을 볼지는 남아 있습니다. 사라진 것은 그 항목을 밖에서 확정으로 읽을 여지뿐입니다. 이 오해를 그대로 두면 테마 안이 빈 문서가 나오고, 그때는 정말로 방향만 있고 계획이 없는 표가 됩니다.

테마로 묶으면 일정 관리가 필요 없어진다고 보는 것도 흔합니다. 날짜를 적는 칸이 눈에 안 보이니 그렇게 읽힙니다. 그런데 칸이 커진 것은 밖에 보여 주는 정밀도일 뿐이고, 안에서 만드는 항목에는 여전히 기준점이 필요합니다. 그대로 두면 분기 중간에 테마가 밀리고 있는지 아무도 모르고, 분기 끝에 세 테마가 모두 절반씩 진행된 상태로 남습니다.