kimsanguine/ai_pm/working-backwards

Skill — Working Backwards (PR-FAQ)

Task

아직 만들지 않은 제품/기능에 대해, 출시일 기준의 가상 보도자료(Press Release) + FAQ 를 작성한다. 목적은 마케팅 문구가 아니라 만들 가치가 있는지 사전 검증 이다.

Scope

• PR-FAQ 작성과 자체 비평까지. 실제 구현·일정 확정·예산 승인은 별도 단계.
• 입력은 기능 아이디어 + 타깃 고객 + 알려진 근거(인터뷰/데이터). 근거 없으면 가정으로 명시.
• PR 은 1페이지를 넘기지 않는다 — 길어지면 가치가 한 문장으로 안 잡혔다는 신호.
• 수치·인용은 실제 근거가 있을 때만. 없으면 [가정] 태그.

Length

• PR 본문 ≤ 400자(헤드라인·서브헤드 제외). FAQ 외부용 3–5개 + 내부용 3–5개.
• 전체 1,500–3,000자.

Format

1. ## Press Release — 헤드라인 / 한 줄 서브헤드 / 문제 단락 / 해결 단락 / 가상 고객 인용 1개 / "시작하는 법" 한 줄.
2. ## FAQ — 고객용 — 고객이 실제로 물을 질문 (가격, 기존 도구 대비, 데이터 안전 등).
3. ## FAQ — 내부용 — 가장 답하기 싫은 질문부터 (왜 우리가, 왜 지금, 실패 조건, 안 만들면 무슨 일).
4. ## 검증 신호 — 이 PR-FAQ 가 통과/기각될 기준(이 가정이 틀리면 만들지 않는다).
5. ## 한계 — [가정] 으로 채운 부분, 근거 부족 항목, 추가 확인 필요.

룰

• 출처 명시: Working Backwards / PR-FAQ 는 Amazon 의 제품 기획 관행이다. "고객으로부터 거꾸로 일한다(start from the customer and work backwards)" 원칙을 인용할 때 출처를 적는다.
• PR 은 고객 언어 로. "혁신적", "업계 최고", "seamless" 같은 마케팅 형용사 금지 — 구체적 진전으로 대체.
• 가상 고객 인용은 그 고객이 실제로 할 법한 문장으로. 칭찬이 아니라 "무엇이 달라졌는지" 를 말하게 한다.
• 내부 FAQ 는 반대 의견을 먼저 적는다. 통과를 전제하지 않는다.
• 근거 없는 수치("3배 빨라짐")는 [가정] 표기. 검증 전 사실로 쓰지 않는다.
• PR 한 문장으로 가치가 안 잡히면, 만들 가치가 불명확하다는 결론을 숨기지 않고 적는다.

의존

• 입력 우선순위: 사용자가 제시한 기능 아이디어 + samples/ 근거
• 참고 챕터: 4.1-discovery-user-research.md

예시

• 좋은 출력: good-examples/prfaq-team-digest.md
• 나쁜 출력: bad-examples/marketing-fluff-pr.md