문제 정의

기획 문서는 오래도록 해법에서 시작했습니다. "문서에 댓글을 달 수 있게 하자" 처럼 만들 것을 먼저 적고, 화면과 동작을 아래에 붙이는 식입니다. 그렇게 쓴 문서는 읽기 편하고 착수도 빠릅니다.

문제는 그 문서에 겨냥이 적혀 있지 않다는 데서 나옵니다. 페이지덱에서 댓글 기능을 만들기로 정한 자리가 그랬습니다. 착수 2주 뒤 지현이 이 기능을 왜 만드는지 다시 물었을 때 답이 셋으로 갈렸습니다. 태오는 문서마다 따로 메신저로 오가는 대화를 한곳에 모으는 일이라고 했고, 민서는 신입이 무엇을 고쳐야 할지 알게 하는 일이라고 했고, 수아는 기업 고객이 요구한 기능이라고 했습니다. 셋 다 그 문서에서 읽은 내용이었습니다. 겨냥이 적혀 있지 않으니 각자 자기가 아는 문제를 채워 넣은 것입니다.

겨냥이 갈린 채로 만들면 기능은 나옵니다. 다만 넉 달 뒤에 아무도 안 쓰는데 왜 안 쓰는지 설명하지 못합니다. 무엇을 하려던 것이었는지가 문서에 남아 있지 않기 때문입니다. 만들 것보다 풀 것을 먼저 적어 두는 한 문단이 그래서 따로 생겼습니다.

한 문단이지만 채워야 하는 칸은 다섯 개이고, 하나라도 비면 읽는 사람이 자기 짐작으로 메웁니다.

1. 누구의 문제인지. 사용자 전체가 아니라 좁힙니다. 특정 사용자 집단을 한 사람처럼 구체화한 페르소나가 있으면 그 이름을 쓰고, 없으면 조건으로 적습니다. "5명 이상 팀에서 문서를 주로 읽기만 하는 구성원" 처럼 적으면 나중에 그 사람을 실제로 찾아가 확인할 수 있습니다.
2. 어떤 상황에서 무엇을 못 하는지. 기능이 없다고 적지 않고 그 사람이 막히는 장면을 적습니다. "동료 문서를 읽다 고칠 곳을 발견했는데 그 자리에서 남길 방법이 없어 메신저로 옮겨 적는다" 가 이 칸입니다.
3. 지금 어떻게 버티고 있는지. 대체로 사람들은 이미 나름의 방법으로 버티고 있고, 그 방법이 문제의 크기를 알려 줍니다. 메신저에 문서 주소와 문단을 복사해 붙이고 있다면 불편하지만 견딜 만한 것이고, 아예 포기하고 넘어간다면 더 큰 문제입니다.
4. 그대로 두면 생기는 손해. 숫자를 붙입니다. 문의 중 이 이야기가 한 달에 40건이라거나, 5명 이상 팀의 2주 후 재방문율이 34퍼센트에서 멈춰 있다는 식입니다. 숫자가 없으면 이 문제와 다른 문제 중 무엇을 먼저 할지 정할 근거가 없습니다.
5. 왜 지금인지. 반년 전에도 있던 문제라면 지금 꺼내는 이유가 따로 있어야 합니다. 기업 고객 계약 갱신이 다음 분기라는 사실이나, 경쟁 제품이 그 기능을 넣었다는 사실이 이 칸에 들어갑니다.

여기에 해법을 적지 않는 것이 이 글의 규칙입니다. 댓글 기능을 만들자는 문장이 들어오면 그 문단은 문제 정의가 아니라 결론이 되고, 다른 해법을 고를 여지가 닫힙니다. 해법은 다음 단계인 가설에서 다룹니다. 다섯 칸이 한 문단에 들어가지 않으면 문제를 아직 좁히지 못한 것입니다.

쓰는 사람은 대개 그 제품을 맡은 프로덕트 매니저 한 명입니다. 혼자 쓰지만 재료를 혼자 만들지는 않습니다. 사용자를 만나 묻고 지켜보는 사용자 리서치의 기록, 이미 들어와 쌓인 문의와 불만을 모아 둔 고객의 소리, 그리고 제품에서 나오는 숫자가 재료입니다. 재료 없이 쓰면 다섯 칸 중 3번과 4번이 비고, 그 문단은 결국 쓴 사람의 짐작이 됩니다.

읽는 사람은 넷이고 각자 다른 칸을 봅니다.

1. 개발 — 태오는 2번 칸을 봅니다. 사용자가 막히는 지점을 알면 화면을 고치는 일인지 구조를 바꾸는 일인지 가늠할 수 있습니다.
2. 디자인 — 민서는 1번과 3번 칸을 봅니다. 대상이 누구이고 지금 무엇으로 버티는지를 알면 그 습관을 대체할 화면을 그릴 수 있습니다.
3. 승인 — 규원은 4번과 5번 칸만 봅니다. 손해의 크기와 지금 해야 하는 이유가 다른 후보보다 크지 않으면 사람을 붙이지 않습니다.
4. 고객을 만나는 쪽 — 수아와 현우는 1번 칸을 봅니다. 여기 적힌 집단이 자기가 만나는 고객과 다르면 그 자리에서 짚습니다.

쓰는 시점은 풀 문제를 고른 직후이고, 요구사항을 적는 PRD보다 앞입니다. 이 순서가 뒤집히면 이미 정해 놓은 해법에 맞는 문제를 거꾸로 찾게 됩니다. 다시 읽는 시점은 두 번입니다. 만드는 중에 새 요청이 들어올 때 이 문단과 맞는지 보고, 출시 넉 달 뒤에 다시 열어 그 문제가 실제로 줄었는지 대조합니다.

"문제 정의부터 다시 씁시다. 지금 문서는 만들 것만 있고 왜가 없어요."

해법을 지우고 겨냥부터 합의하자는 요청입니다.

"이건 문제 정의에 없던 요청인데요. 문단을 고칠지 다음으로 넘길지 정해야 합니다."

새 요청을 그냥 붙이지 않고 겨냥을 바꾸는 결정으로 다루겠다는 말입니다.

"문제 정의 한 문단만 보내 주세요. 그거 보고 일정 답할게요."

무엇을 풀려는 일인지만 알면 규모를 가늠할 수 있다는 뜻입니다.

페이지덱에서는 지현이 이 문단을 쓰고 회의에서 소리 내어 읽습니다. 한 문단이라 읽는 데 30초가 걸리고, 그 30초 안에 누가 고개를 젓는지가 드러납니다. 수아가 "제가 만나는 고객은 그 집단이 아닙니다" 라고 말하면 그날 회의는 해법으로 넘어가지 않고 대상을 다시 좁히는 데 씁니다.

해법을 문제처럼 적어 놓고 문제 정의를 썼다고 여기는 경우가 가장 많습니다. "댓글 기능이 없다" 라는 문장은 없는 것을 지적하니 문제처럼 읽히지만, 실제로는 만들 것을 미리 정해 둔 문장입니다. 이렇게 적으면 확인할 것이 하나도 남지 않습니다. 댓글이 아니라 문서 안 할 일 표시나 수정 제안 기능이 그 불편을 더 싸게 없앨 수도 있는데, 첫 줄에서 이미 답을 정했으니 그 후보가 논의에 오르지 못합니다.

한 번 쓰면 끝나는 형식이라고 보는 것도 흔합니다. 착수 전에 한 번 채우고 문서 앞쪽에 붙여 두면 할 일을 한 것처럼 보이기 때문입니다. 그런데 이 문단의 값은 만드는 동안 판정 기준으로 쓰이는 데서 나옵니다. 새 요청이 들어올 때마다 이 문단과 맞는지를 보지 않으면, 겨냥이 적힌 문단이 있는데도 기능은 여전히 요청이 들어온 순서대로 늘어납니다.