제품 로드맵

만들 것의 순서를 정하는 일 자체는 로드맵이 없어도 돌아갑니다. 무엇을 먼저 할지 고르는 우선순위 결정은 팀 안에서 매주 일어나고, 그 결과는 앞으로 만들 후보를 순서대로 쌓아 둔 제품 백로그에 남습니다. 문제는 그 순서를 팀 밖에서는 아무도 볼 수 없다는 데 있습니다. 백로그는 항목이 수백 개고 용어도 안쪽 사람들 말투로 적혀 있어서, 영업이나 마케팅이 열어 봐도 이번 분기에 무엇이 나오는지 읽어내지 못합니다.

그러면 질문이 개별 대화로 흩어집니다. 페이지덱에서도 그랬습니다. 수아는 계약을 앞둔 기업 고객에게 권한을 세분화해 관리하는 기능이 3분기에 나온다고 말했는데, 지현은 그런 시점을 말한 적이 없었습니다. 현우는 그 기능을 앞세운 광고 문구를 준비하고 있었고, 태오는 회의에서 그 이야기를 처음 들었습니다. 같은 주에 규원은 투자자에게 다음 반년의 계획을 설명하면서 권한 관리를 아예 언급하지 않았습니다. 네 사람이 각자 다른 그림을 들고 회사 밖에 나가 있었던 셈입니다.

이런 상태는 조용히 굴러가다가 한 번에 터집니다. 고객은 들은 시점에 맞춰 도입 일정을 잡아 두었고, 마케팅은 소재 제작에 돈을 이미 썼고, 개발팀은 그 기능을 시작조차 하지 않았습니다. 어긋난 것을 발견한 시점에는 이미 되돌릴 수 없는 결정이 몇 개씩 붙어 있습니다. 이때 회사가 치르는 비용은 기능이 늦어진 것이 아니라 밖에 나간 말을 주워 담는 일입니다. 고객에게 다시 연락해 시점을 정정하고, 그 과정에서 계약 조건을 한 번 더 양보하게 됩니다.

제품 로드맵은 그 그림을 한 장으로 고정하자는 제안입니다. 팀이 무엇을 언제쯤 하려고 하는지를 바깥 사람이 읽을 수 있는 말로 적어 한곳에 두고, 다른 자리에서 다른 답이 나오면 그 문서를 근거로 맞춥니다. 적는 대상은 일정표가 아니라 지금 시점의 의도입니다. 이 구분이 흐려지는 순간 로드맵은 지키지 못할 약속의 목록이 됩니다.

제품 로드맵 아래 묶인 용어는 두 갈래입니다. 무엇을 축으로 놓고 그릴지를 정하는 형식이 넷, 어떤 형식을 고르든 안에 들어가는 구성 요소가 하나입니다.

형식 네 가지는 왼쪽부터 오른쪽으로 갈수록 날짜에서 멀어지고 목적에 가까워집니다.

1. 타임라인 로드맵 — 달력 위에 일정을 못 박는 형식입니다. 분기나 월 칸을 만들고 그 안에 만들 것의 이름을 넣습니다. 밖에서 읽기 가장 쉽고 다른 팀이 자기 일정을 맞추기도 편합니다. 대신 먼 칸의 날짜까지 확정된 약속으로 읽힌다는 문제를 늘 달고 다닙니다. 4분기 칸에 적힌 항목은 지금 아는 것이 가장 적은 항목인데도 1분기 칸과 같은 굵기로 보입니다. 그래서 이 형식은 이미 착수했거나 착수가 확정된 구간까지만 쓰고, 그 뒤는 비워 두거나 다른 형식으로 넘기는 팀이 많습니다.
2. 나우-넥스트-레이터 — 날짜 대신 시급도 세 칸으로 나눈 형식입니다. 지금 하는 것, 다음에 할 것, 나중에 볼 것으로만 구분합니다. 칸마다 확신의 정도가 다르다는 사실이 형태에 그대로 드러나서, 뒤쪽 칸을 두고 언제냐고 묻는 대화가 애초에 줄어듭니다. 대신 지금 칸이 비좁아야 값을 합니다. 지금 칸에 여덟 개가 들어가 있으면 세 칸으로 나눈 의미가 사라지고, 읽는 쪽은 그것을 다시 날짜순으로 상상하기 시작합니다.
3. 테마 기반 로드맵 — 관련 있는 과제를 주제로 묶어 보여 주는 형식입니다. 개별 기능 이름 대신 "처음 쓰는 팀이 혼자서 자리 잡게 하기" 같은 묶음을 칸에 넣고, 그 아래 항목은 만들면서 바뀔 수 있게 둡니다. 방향은 전달되면서 개별 기능이 약속으로 굳지 않습니다.
4. 성과 기반 로드맵 — 만들 것 대신 달성할 결과를 적는 형식입니다. "가입 30일 뒤 남아 있는 팀의 비율을 30퍼센트에서 38퍼센트로" 처럼 숫자와 시점을 적고, 거기 닿는 방법은 열어 둡니다. 가장 정직한 형식이지만 읽는 쪽에 기대는 바가 커서, 밖에서 기능 이름을 기대하는 상대에게는 대화가 한 번 더 필요합니다. 숫자를 스스로 움직일 수 있는 팀에서만 성립한다는 조건도 붙습니다. 리텐션이 열 갈래 요인에 걸려 있고 그중 둘만 제품 팀 손에 있다면, 결과를 적어 둔 칸이 책임 소재를 흐리는 쪽으로만 작동합니다.

구성 요소 갈래에는 마일스톤 하나가 있습니다. 진척을 확인하려고 중간에 박아 두는 기준점인데, 어느 형식을 골라도 이것 없이는 분기 중간에 계획이 밀리고 있는지 알 수 없습니다. 날짜만 적힌 마일스톤은 소용이 없습니다. "8월 말" 이 아니라 "8월 말까지 사내 팀 다섯 곳이 권한 설정을 직접 마치는 것" 처럼 그때 무엇이 되어 있어야 하는지를 함께 적어야 지났는지 안 지났는지를 판정할 수 있습니다.

형식을 골랐다면 그다음은 칸을 채우는 일입니다. 항목 하나에 아래 다섯 가지가 붙어 있어야 읽는 사람이 되묻지 않습니다.

1. 항목 이름과 해결하려는 문제 — 이름만 적으면 왜 하는지가 사라집니다. "권한 관리" 옆에 "관리자가 외부 협력사에게 특정 문서만 열어 줄 수 없다" 를 붙여 두면, 더 싸게 푸는 방법이 나왔을 때 항목을 바꿀 수 있습니다.
2. 시기 구간 — 분기든 세 칸 가운데 하나든, 이 항목이 놓인 자리입니다. 날짜 하나로 적지 않고 구간으로 적는 이유는 정밀도를 실제 아는 만큼만 표시하기 위해서입니다. 착수도 안 한 일에 9월 18일이라고 적어 두면 읽는 쪽은 그 하루를 믿고 자기 일정을 겁니다.
3. 목표와 확인 방법 — 이 항목이 끝났을 때 무엇이 달라져야 하는지와 그것을 어떤 숫자로 확인할지입니다. 없으면 만들었다는 사실만 남고 잘 됐는지는 아무도 판정하지 않습니다. 형식이 성과 기반이 아니어도 이 칸은 붙입니다. 기능 이름 옆에 작게 적히느냐 칸 전체를 차지하느냐의 차이일 뿐입니다.
4. 확신도 — 이 시기에 이대로 나올 가능성을 높음·중간·낮음 정도로 적습니다. 이 한 칸이 로드맵을 약속표로 읽는 오해를 가장 크게 줄여 줍니다. 4분기 항목에 낮음이 붙어 있으면 영업이 그것을 계약서에 쓰지 않습니다.
5. 담당과 현재 상태 — 누가 들고 있고 지금 어디까지 왔는지입니다. 상태가 비어 있으면 문서를 볼 때마다 사람들이 담당자에게 개별로 물어보게 되고, 로드맵을 만든 이유가 그 자리에서 사라집니다. 상태는 세 가지면 충분합니다. 아직 안 봄, 살펴보는 중, 만드는 중입니다. 이보다 잘게 나누면 갱신하는 사람이 지쳐서 결국 아무도 손대지 않는 칸이 됩니다.

"로드맵에 있으니까 3분기에는 나오는 거죠?"

문서를 날짜 약속으로 읽고 있다는 신호입니다. 여기서 답해야 할 것은 예 아니오가 아니라 그 항목의 확신도입니다.

"이번 분기는 날짜 대신 세 칸으로 갈게요. 칸에 월을 박으면 전부 확정으로 읽혀서요."

정보를 줄이려는 것이 아니라 확신의 정도를 형태로 드러내려고 형식을 바꾸겠다는 말입니다.

"이건 로드맵에 올릴 건가요, 백로그에만 둘까요?"

팀 밖 사람이 미리 알아야 하는 항목인지, 팀 안에서 순서만 매기면 되는 항목인지를 묻는 말입니다.

페이지덱에서는 분기가 시작되기 2주 전에 지현이 문서를 갱신합니다. 수아에게서 계약이 걸린 요청 목록을, 현우에게서 캠페인을 언제 걸 수 있는지를, 태오에게서 지금 손보지 않으면 다음 분기에 두 배로 드는 작업이 무엇인지를 받습니다. 규원은 투자자에게 설명할 큰 줄기가 이 문서와 같은지만 봅니다.

권한 관리 건이 어긋났던 다음 분기부터는 항목마다 확신도를 붙였습니다. 권한 관리는 다음 칸에 들어가고 확신도는 중간으로 적혔습니다. 수아는 그 표기를 보고 고객에게 시점 대신 "다음 분기에 착수 예정이고 확정되면 먼저 알려 드리겠다" 고 말했습니다. 현우는 소재 제작을 착수 확정 뒤로 미뤘습니다. 같은 항목이 같은 자리에 있어도, 얼마나 믿을 수 있는지가 함께 적혀 있으면 밖에서 하는 행동이 달라집니다.

갱신 주기를 정해 둔 것도 그때부터입니다. 분기에 한 번 크게 고치고 매달 한 번 상태만 손봅니다. 주기가 없으면 로드맵은 만든 주에만 맞고, 두 달 뒤에는 아무도 열지 않는 문서가 됩니다.

가장 흔한 오해는 로드맵을 일정 약속으로 읽는 것입니다. 달력 위에 놓여 있고 분기가 적혀 있으니 자연스러운 읽기입니다. 하지만 이 문서는 지금 아는 것을 바탕으로 세운 의도이고, 새로 알게 되는 것이 생기면 바뀌는 쪽이 정상입니다. 약속으로 굳으면 그다음이 더 나쁩니다. 담당자는 바꿔야 한다는 것을 알면서도 바꾸지 못하고, 결국 로드맵을 아무에게도 보여 주지 않는 쪽을 택합니다. 그러면 정보는 다시 개별 대화로 흩어지고, 로드맵이 없던 시절로 정확히 돌아갑니다. 바뀔 수 있다는 사실을 문서 안에 적어 두는 편이 낫고, 확신도 칸과 갱신 주기가 그 역할을 합니다. 그렇다고 전부 바뀔 수 있다고 적어 두면 반대쪽으로 쓸모가 없어집니다. 이번 분기에 착수한 항목은 지키고 그 뒤 칸은 움직인다는 선을 문서 맨 위에 한 줄로 밝혀 두면, 읽는 쪽도 어디까지를 계획으로 삼을지 알게 됩니다.

두 번째는 로드맵을 기능 목록으로 보는 것입니다. 칸에 기능 이름을 적게 되니 그렇게 보입니다. 이름만 남으면 그 항목이 무엇을 풀려던 것인지가 사라지고, 사라지면 대안을 고를 수 없게 됩니다. 권한을 세분화하는 화면을 만들기로 적어 두면 그 뒤로는 아무도 공유 링크에 만료 기한을 붙이는 더 작은 방법을 떠올리지 않습니다. 해결하려는 문제를 항목 옆에 한 줄로 붙여 두면, 석 달 뒤 더 싼 방법이 나왔을 때 항목을 갈아 끼우는 결정이 로드맵을 뒤엎지 않고 끝납니다. 문제가 적혀 있으면 항목이 바뀌어도 그 칸이 존재하는 이유는 그대로이기 때문입니다. 기능 이름만 적힌 칸은 이름을 바꾸는 순간 계획 자체가 흔들린 것처럼 보이고, 그 인상을 피하려고 이미 틀린 항목을 분기 끝까지 그냥 두게 됩니다.