PR/FAQ

기획서는 오랫동안 회사 안쪽 말로 쓰였습니다. 전환율이 1.8퍼센트라서 결제 화면을 고치겠다, 문서 목록에 필터를 붙이겠다. 이런 문장은 안에서 읽을 때 문제가 없어 보입니다. 숫자가 붙어 있고 무엇을 만들지도 분명합니다.

문제는 마지막에 드러났습니다. 개발이 끝나고 공지를 쓰려는 자리에서 "이거 고객에게 뭐라고 알려요" 하는 물음이 나오면 방이 조용해집니다. 필터를 붙였다는 말은 고객이 받을 소식이 아니고, 무엇이 좋아졌는지 한 문장으로 옮기려 하면 옮겨지지 않습니다. 반년을 들여 만든 것이 고객 쪽에서 보면 시시했다는 사실이 다 만든 뒤에 밝혀지는 셈입니다.

순서를 거꾸로 돌리면 이 일이 앞으로 옮겨집니다. 만들기 전에 고객이 받을 소식부터 써 보고, 한 문장이 안 써지면 그 자리에서 멈추는 겁니다. PR/FAQ 는 그 검사를 문서 형식으로 굳힌 결과입니다.

문서는 두 덩어리입니다. 앞은 출시 당일에 낼 것처럼 쓴 보도자료이고, 뒤는 그 소식을 두고 나올 질문과 답입니다. 분량은 합쳐서 두세 장, 원페이저보다 길고 PRD보다 짧습니다.

앞쪽 보도자료는 다섯 조각입니다. 언론에 배포하는 보도자료의 생김새를 그대로 빌립니다.

1. 제목 — 고객이 보게 될 한 문장입니다. 기능 이름이 아니라 고객 쪽에서 무엇이 달라지는지를 씁니다. 문서 필터 기능 출시가 아니라, 문서가 500개 넘는 팀도 찾던 문서를 3초 안에 찾게 됩니다 쪽입니다.
2. 부제 — 누구를 위한 것인지 한 줄로 좁힙니다. 모든 팀이 아니라 문서가 일정 수를 넘긴 팀처럼 적습니다.
3. 요약 — 무엇이 가능해지는지를 한 문단으로 씁니다. 이 문단만 떼어 고객에게 보내도 뜻이 통해야 합니다.
4. 문제 — 고객이 지금 겪는 일을 사람이 겪는 장면으로 씁니다. 검색이 부정확하다는 문장보다, 회의 중에 지난 분기 회의록을 찾다가 2분을 쓰고 결국 옆 사람에게 물어본다는 문장이 그림을 만듭니다.
5. 해결과 시작 방법 — 어떻게 해결되는지, 그리고 고객이 어디서 무엇을 눌러 쓰기 시작하는지를 적습니다.

뒤쪽 예상 질문은 두 갈래로 나눠 씁니다.

1. 외부 질문 — 고객이 물을 것들입니다. 값이 오르는지, 기존 문서에도 적용되는지, 무료 플랜에서도 되는지. 답이 불편한 질문을 빼면 검사 장치로서 쓸모가 없어집니다.
2. 내부 질문 — 만드는 쪽이 물을 것들입니다. 얼마나 걸리는지, 누가 붙는지, 성공을 무엇으로 판정하는지, 틀렸을 때 무엇을 되돌려야 하는지. 검토했지만 고르지 않은 안과 버린 이유도 여기 들어갑니다.

쓰는 쪽은 제안하는 사람입니다. 프로덕트 매니저가 가장 많이 쓰고, 출시 커뮤니케이션을 맡는 프로덕트 마케팅 매니저와 제목 한 줄을 함께 다듬는 일이 흔합니다. 초안을 대여섯 번 고쳐 쓰는 문서이고, 제목과 요약 문단에서 시간이 가장 많이 갑니다.

읽는 쪽은 둘입니다. 승인하거나 반대할 결정권자, 그리고 만들게 될 팀입니다. 이 둘을 문서 맨 위에 이름으로 적어 두면 어휘와 분량이 저절로 정해집니다. 대표가 읽는 문서라면 기술 용어를 풀어 써야 하고, 개발팀이 읽는 문서라면 요금제 구조를 한 줄 설명해야 합니다.

읽는 방식도 형식의 일부입니다. 미리 읽어 오라고 보내는 대신 회의 첫 10분을 다 함께 읽는 시간으로 쓰는 회사가 많습니다. 미리 보내면 절반은 읽지 않은 채로 들어오고, 그러면 회의가 다시 설명으로 시작하기 때문입니다.

문서가 놓이는 자리는 정해져 있습니다. 가설을 검증할 최소한의 제품을 뜻하는 MVP의 범위를 정하기 전, 요구사항과 완료 기준을 적는 문서보다 앞입니다. 통과하면 만들 항목이 앞으로 만들 후보를 모아 둔 제품 백로그로 올라가고, 이 자리에서 내린 판단 자체는 무엇을 왜 그렇게 정했는지 남기는 의사결정 기록에 따로 적습니다.

"이거 PR/FAQ 로 한 번 써 보고 다음 주에 다시 봅시다."

제안이 고객 쪽에서 말이 되는지부터 확인하자는 뜻이고, 이번 회의에서는 결정하지 않겠다는 말입니다.

"제목 한 줄이 아직 안 나오는데요. 그러면 아직 만들 준비가 안 된 겁니다."

고객이 받을 소식을 한 문장으로 못 쓰는 상태를 착수 전에 걸러 내는 말입니다.

"외부 질문은 괜찮은데 내부 질문에 되돌리는 방법이 없어요."

틀렸을 때 무엇을 어떻게 되돌릴지가 비어 있으니 채워 오라는 요청입니다.

페이지덱에서는 무료 플랜 사용자를 유료로 넘기는 제안을 지현이 이 형식으로 썼습니다. 제목을 여덟 번 고쳐 쓰는 동안 처음 생각했던 안이 두 번 바뀌었습니다. 고객 쪽 문장으로 옮기니 열흘 무료 연장은 소식이 되지 않았고, 열 명을 넘긴 팀이 결제 없이 한 달 더 같이 쓸 수 있다는 쪽이 읽혔습니다. 규원이 회의 첫 10분에 그 문서를 읽고 던진 첫 질문도 내부 질문 쪽이었습니다.

보도자료를 실제로 언론에 배포하는 문서로 읽는 경우가 가장 많습니다. 이름에 보도자료가 들어 있고 생김새도 똑같으니 그렇게 읽히는 게 당연합니다. 하지만 이 문서는 회사 밖으로 나가지 않습니다. 출시 전 계획이 그대로 적혀 있어 나가면 안 되는 문서입니다. 진짜 보도자료는 출시가 확정된 뒤에 따로 씁니다. 두 문서를 섞으면 문장을 다듬는 데 시간을 쓰게 되고, 정작 검사해야 할 내부 질문 쪽이 얇아집니다.

쓰기만 하면 기획이 좋아진다고 읽는 것도 흔합니다. 형식을 채우는 일 자체가 점검처럼 느껴지기 때문입니다. 그런데 항목을 다 채워도 답이 불편한 질문을 빼 버리면 남는 것은 잘 쓴 홍보 문구뿐입니다. 값이 오르느냐는 질문에 아니라고 쓰고 싶어서 유료 항목을 슬쩍 빼 두는 식입니다. 그 상태로 통과한 문서는 출시 뒤에 같은 질문을 고객에게서 다시 받습니다. 형식이 하는 일은 답하기 싫은 질문을 종이 위에 남게 만드는 것까지이고, 답을 쓰는 것은 사람의 몫입니다.