워킹 백워즈

기획이 만들 수 있는 것에서 출발하면 설명은 맨 마지막에 붙습니다. 무엇을 만들지 정하고, 화면을 그리고, 개발을 하고, 내보낼 주에 와서야 이걸 사용자에게 어떻게 알릴지 생각합니다. 그 순서에서는 설명이 안 되는 기능을 다 만든 뒤에 발견합니다.

페이지덱에서 검색 기능이 그랬습니다. 태오가 석 달을 들여 검색을 다시 만들었고, 출시 주에 현우가 사용자에게 뭐라고 알릴지를 물었습니다. 문장으로 옮겨 보니 검색이 빨라졌다는 말밖에 나오지 않았습니다. 정작 사용자가 겪던 불편은 제목을 정확히 몰라 문서를 못 찾는 것이었는데, 그 경우에 쓸 기능은 석 달 동안 만들어지지 않았습니다.

워킹 백워즈는 그 순서를 뒤집습니다. 맨 끝에 쓸 문장을 맨 앞에서 씁니다. 다 만든 뒤에 알릴 말을 찾는 대신, 알릴 말이 써지지 않으면 만들기를 멈춥니다. 글로 옮겨지지 않는 것은 사용자에게도 전달되지 않는다는 쪽에 기대는 방법입니다.

출시일에 고객이 받을 안내문을 완성된 형태로 쓰는 데서 시작합니다. 초안이나 개요가 아니라 그대로 내보낼 수 있는 문장이어야 합니다.

절차는 여섯 단계입니다.

1. 고객과 문제를 한 문장으로 적습니다. 누가 언제 무엇 때문에 막히는지를 넣습니다. 회의가 끝난 직후에 결정 사항을 찾으려는 사람이 지난 문서 열 개를 열어 봐야 한다는 식입니다.
2. 안내문을 씁니다. 기능 이름이 아니라 달라지는 일로 씁니다. 검색이 개선됐다고 쓰지 않고, 제목을 몰라도 문서 안의 문장으로 찾을 수 있다고 씁니다. 이 형식은 언론에 알리려고 쓰는 보도자료의 생김새를 빌린 것입니다.
3. 예상 질문을 적고 답을 붙입니다. 값을 얼마로 받는지, 기존 사용자에게 무엇이 달라지는지, 왜 지금인지 같은 질문입니다. 답이 안 나오는 질문은 아직 정하지 않은 것이라 그대로 남겨 두지 않습니다.
4. 성공 기준을 숫자와 기한으로 못 박습니다. 두 달 안에 검색으로 문서를 여는 비율이 12퍼센트에서 30퍼센트로 오른다는 식입니다.
5. 안내문이 참이 되려면 무엇이 있어야 하는지를 역순으로 적습니다. 화면, 그 화면이 쓸 데이터, 그 데이터를 만드는 처리 순서로 내려갑니다. 기술 이야기는 이 단계에서 처음 나오고, 여기서 나온 목록이 PRD의 재료가 됩니다.
6. 문서 상태에서 할지 말지를 정합니다. 만들기 전에 버리는 것이 이 방식이 내놓는 결과의 절반입니다.

2번과 3번을 합쳐 한 문서로 만든 것이 PR/FAQ입니다. 팀마다 항목 이름은 다르지만 앞에 안내문, 뒤에 질문과 답이 오는 구조는 같습니다.

되돌리기 어려운 결정에 맞습니다. 한 분기 이상이 들어가는 일, 여러 팀이 동시에 움직여야 하는 일, 지금까지 팔던 것과 다른 것을 새로 파는 일입니다. 이런 일에서는 문서 한 장에 이틀을 쓰고 그만두는 것이 석 달을 쓰고 그만두는 것보다 훨씬 쌉니다.

맞지 않는 자리는 셋입니다.

1. 며칠짜리 개선. 버튼 문구를 고치는 일에 안내문과 예상 질문을 쓰면 문서 쓰는 시간이 만드는 시간을 넘습니다.
2. 이미 해야 할 일이 정해진 대응. 법이 바뀌어 넣어야 하는 항목에는 고를 여지가 없어서 거꾸로 걸어 볼 것도 없습니다.
3. 수요 자체가 물음표인 일. 사람들이 원하는지 모르는 것은 글로 확인되지 않습니다. 만들 값어치가 있는지 먼저 살피는 제품 디스커버리나, 가설을 확인할 최소한의 제품인 MVP로 먼저 확인하고 그다음에 이 문서를 씁니다.

한계도 둘 있습니다. 첫째는 잘 쓴 글이 좋은 제안처럼 보인다는 것입니다. 문장이 매끄러우면 근거가 없어도 통과되기 쉬워서, 성공 기준과 검토한 대안 항목을 비워 둔 문서는 받지 않는 규칙이 함께 필요합니다. 둘째는 문서가 계약처럼 굳는다는 것입니다. 반년 뒤에 상황이 달라졌는데도 처음 쓴 최종 모습을 지키려 하면, 순서를 뒤집어 얻은 것을 그 자리에서 잃습니다.

"출시 안내문을 먼저 써 봤는데 두 문장을 못 넘겼어요. 만들 값어치가 있는지 다시 봐야 합니다."

문장이 안 나오는 것을 근거 부족의 신호로 읽은 말입니다.

"예상 질문에서 가격을 못 적고 있어요. 그게 안 정해진 채로 개발을 시작할 수는 없습니다."

문서의 빈칸을 아직 하지 않은 결정으로 취급한 것입니다.

"이건 문서로 결정할 게 아니라 작게 만들어 봐야 아는 질문이에요."

이 방식이 맞지 않는 일이라고 선을 그은 말입니다.

앞서 검색을 한 번 헛돌린 뒤에 페이지덱은 순서를 바꿔 다시 시작했습니다. 지현이 안내문을 먼저 썼고, 첫 문장은 제목을 몰라도 문서 안의 문장으로 찾을 수 있다는 내용이었습니다. 그 문장이 참이 되려면 문서 본문을 미리 훑어 색인을 만들어 둬야 한다는 사실이 5번 단계에서 나왔고, 태오가 2주를 들여 그것이 가능한지만 확인했습니다.

같은 회의에서 문서 하나는 버려졌습니다. 문서에 태그를 붙이는 기능이었는데, 안내문을 쓰려 하니 사용자가 무엇을 덜 하게 되는지를 한 문장으로 적을 수 없었습니다. 태그를 붙이는 일 자체가 사용자에게 새로 생기는 일이라는 것이 글로 옮기는 과정에서 드러났습니다. 개발은 시작되지 않았고, 그 결정에 든 시간은 이틀이었습니다.

보도자료를 그럴듯하게 쓰는 훈련으로 읽는 경우가 가장 많습니다. 산출물이 문서이고 형식이 홍보문을 닮아서 그렇게 보입니다. 하지만 이 방식이 실제로 하는 일은 만들지 않기로 정하는 것입니다. 문장이 써지지 않는 제안을 걸러 내는 자리이지, 이미 정해진 제안을 잘 포장하는 자리가 아닙니다. 이 점을 놓치면 통과율이 100퍼센트인 문서 더미가 쌓입니다.

문서 양식만 바꾸면 되는 일로 읽는 것도 흔합니다. 형식은 눈에 보이고 순서는 안 보이기 때문입니다. 그런데 이 방식의 값어치는 안내문을 언제 쓰는지에서 나옵니다. 기획과 개발을 다 해 놓고 마지막에 같은 양식을 채우면 그 문서는 승인 서류가 되고, 버릴 기회는 이미 지나가 있습니다.