PR/FAQ(Working Backwards) 작성법: “만들기 전에” 성공을 증명하는 제품 문서

PM 문서가 실패하는 가장 흔한 패턴은 이겁니다. 만들고 나서 정당화합니다.

PR/FAQ(Working Backwards)는 순서를 뒤집습니다. 출시 1주 전이라고 가정하고(가상의 런치데이), 보도자료(PR)와 FAQ를 먼저 써서 “이 제품이 왜 성공해야 하는지”를 문서로 증명합니다. 

 

---

 

PR/FAQ란 무엇인가

PR/FAQ는 Press Release(가상의 보도자료) + Frequently Asked Questions(FAQ)로 구성된 문서 프레임워크입니다. 핵심은 “문서가 홍보물이 아니라 제품 개발 도구”라는 점입니다. 

 

• PR: 고객 관점으로 “무슨 문제를 어떻게 해결해서 어떤 가치가 생겼는지”를 런치데이 톤으로 서술
• FAQ: 고객/내부 이해관계자가 던질 질문을 선제 처리(외부 FAQ + 내부 FAQ로 나누는 방식이 흔함) 

---

 

왜 PM에게 PR/FAQ가 강한가

PR/FAQ가 강한 이유는 ‘형식’이 아니라 진실 탐색(Truth-seeking)을 강제하기 때문입니다. 문서를 쓰는 과정에서 아래가 자동으로 드러납니다.

 

• 고객 문제가 진짜인가? (문제 정의가 빈약하면 PR 자체가 안 써짐)
• 차별성이 있는가? (기존 해결책 대비 “의미 있게 더 나은가”가 명확해짐) 
• 조직이 유지·운영 가능한가? (내부 FAQ에서 보안/운영/CS/법무/재무가 튀어나옴)

 

즉, “아이디어 평가”가 아니라 실행 가능한 제품 가설로 정제됩니다. 

---

 

PR/FAQ는 언제 쓰나

상황	PR/FAQ가 특히 유효한 이유
신규 제품/카테고리 진입	고객 가치·차별성·운영 가능성 검증이 핵심
큰 투자/큰 리스크 프로젝트	“왜 하는가”와 “실패 시나리오”를 문서로 먼저 때려봄
이해관계자 많은 조직	문서가 합의의 중심축(논쟁을 질문/답으로 전환)
로드맵이 ‘아이디어 목록’이 된 상태	PR이 “고객 가치 기준”으로 우선순위를 재정렬

 

---

 

PR/FAQ 표준 구조

 

1) PR(Press Release) 구성

실무에서 많이 쓰는 PR 파트의 구성 요소를 표준화하면 아래처럼 정리됩니다. 

섹션	목적	작성 기준
헤드라인(1문장)	고객이 이해하는 제품 이름	내부 용어 금지
서브헤드(1문장)	누가 어떤 혜택을 얻는지	“고객+핵심 가치”만
요약(3~5문장)	PR 전체 한 단락 요약	기능 나열 금지, 가치 중심
문제(3~5문장)	고객 문제가 왜 중요한지	고객 언어로, 현재 대안 언급
해결(3~5문장)	어떻게 해결하는지	원리/경험 중심, 구현 디테일 최소화
Getting Started	시작 방법/경험 플로우	온보딩/첫 성공 경험(First success)
인용문(2개 이상)	신뢰/서사 강화	내부 1, 고객(가상) 1 방식이 흔함

 

2) FAQ 구성

FAQ는 보통 외부 FAQ(고객)와 내부 FAQ(조직)로 나눕니다. 

구분	질문 유형	예시
외부 FAQ	가격/정책/신뢰/사용법	“얼마인가?”, “환불은?”, “왜 믿어야 하나?”
내부 FAQ	운영/법무/보안/리스크/우선순위	“CS는 누가?”, “개인정보는?”, “실패 시 롤백은?”

 

---

 

PM용 PR/FAQ 템플릿

 

PR 템플릿(복붙용)

항목	내용
Headline	(고객이 이해하는 이름)
Subheadline	(타깃 고객)에게 (핵심 혜택)을 제공한다
Summary	3~5문장: 문제 → 가치 → 결과
Problem	고객 관점에서 3~5문장
Solution	고객 경험 중심 3~5문장
Getting Started	시작/첫 성공 경험
Quotes	내부 1개 + 고객(가상) 1개

 

FAQ 템플릿(복붙용)

질문	답변	근거/가정	오너
(외부) 가격은?
(외부) 기존 대안과 차이는?
(내부) 운영/CS는?
(내부) 보안/법무 이슈는?
(내부) 롤백/가드레일은?

 

---

 

PR/FAQ를 “진짜 검증 문서”로 만드는 작성 규칙 7가지

1. 고객 언어로만 쓴다: 내부 시스템명/조직 용어 금지
2. 기능 나열 금지, 가치 중심: PR은 “기능 설명서”가 아님
3. 비교 대상(현재 대안)을 명시: “이미 해결된 문제”인지 검증 
4. 가정(Assumption)을 FAQ에 박제: 가격/전환/운영 비용 같은 불확실성 숨기지 않기
5. 내부 FAQ를 더 독하게: 보안/법무/운영이 막히면 제품은 못 나감
6. 단계적 론치 가정: 전면 런치 대신 베타/제한 론치 시나리오를 FAQ로 처리
7. 리라이트 횟수를 전제로 운영: PR/FAQ는 초안이 아니라 “반복 수정”이 핵심 

---

 

예시 미니 샘플: PR 헤드라인/요약(가상)

항목	예시
Headline	“여행 일정이 바뀌어도, 항공 옵션을 자동으로 다시 맞춰주는 ‘스마트 재예약’”
Subheadline	갑작스런 일정 변경으로 스트레스 받는 여행자에게 3분 내 재예약 경험을 제공
Summary	일정 변경 후 재예약 과정에서 발생하는 검색/비교/규정 확인 부담을 줄이고, 정책·가격·좌석 조건을 자동으로 맞춰 재예약 후보를 제안한다. 사용자는 후보를 비교한 뒤 한 번의 확인으로 재예약을 완료한다.

(실제 문서에서는 Problem/Solution/Getting Started와 FAQ로 검증을 이어가면 됩니다.)

---

 

제출 전 체크리스트

체크 항목	통과 기준
PR이 고객 언어로 읽히는가	내부 용어 없이도 의미가 통함
Problem이 “중요한 문제”인가	이미 충분히 해결된 문제를 다시 말하지 않음
Solution이 운영 가능하게 보이는가	내부 FAQ에서 운영/보안/법무가 커버됨
FAQ가 질문을 회피하지 않는가	가격/리스크/롤백을 “추후”로 넘기지 않음
성공 기준이 있다	런치 후 무엇으로 성공/실패 판단할지 명시
리라이트 계획이 있다	리뷰 라운드(초안→수정→승인)가 설계됨

 

---

 

다음 편 예고: RFC(제안서/스펙 합의 문서)

다음 글은 RFC입니다.

PR/FAQ가 “고객 가치로 제품을 증명”하는 문서라면, RFC는 “여러 팀이 충돌 없이 실행하도록 합의를 고정”하는 문서입니다.

PR/FAQ에서 합의된 방향이 실제 구현 단계로 넘어갈 때, RFC가 없으면 다시 구두 합의와 재논쟁으로 돌아갑니다.

RFC 작성법: 여러 팀 합의를 끌어내는 제안서/스펙 문서 구조

RFC 작성법: 여러 팀 합의를 끌어내는 제안서/스펙 문서 구조

 

---

함께 보면 좋은 글

SCQA 보고서 구조: 민토 피라미드로 “설득되는 첫 문단” 만드는 법

SCQA 보고서 구조: 민토 피라미드로 “설득되는 첫 문단” 만드는 법

Executive Summary 작성법: 임원이 읽는 1페이지 요약보고 구조

Executive Summary 작성법: 임원이 읽는 1페이지 요약보고 구조