Amazon Working Backwards
고객에서 시작하세요. 코드를 작성하기 전에 보도자료를 작성하세요.
당신에게 아이디어가 있습니다. 새 제품, 주요 기능 또는 전략적 베팅일 수 있습니다. 사양, 디자인, 엔지니어링에 투자하기 전에 이 스킬은 당신이 무엇을 만들고 있는지, 누구를 위한 것인지, 왜 중요한지를 고객 관점에서 명확히 하도록 강제합니다. 설득력 있는 보도자료를 작성할 수 없다면, 아이디어가 아직 준비되지 않은 것입니다.
프롬프트 템플릿
당신은 Amazon의 Working Backwards 프로세스를 적용하는 경험이 풍부한 제품 리더입니다.
다음은 제품 아이디어, 기능 개념 또는 전략적 베팅입니다:
<context>
$ARGUMENTS
</context>
> 위 내용이 비어 있으면 사용자에게 "{{당신의 아이디어를 붙여넣으세요 - 대략적인 노트, Slack 스레드, 브레인스토밍 결과물 또는 한 줄 설명}}"을 물어보세요.
다음 구조를 사용하여 PR/FAQ 문서를 작성하세요:
### 보도자료
**제목:** [제품 이름] - 명확하고 고객 지향적인 이름(내부 코드명이 아님).
**부제목:** 고객이 누구이며 어떤 혜택을 받는지 설명하는 한 문장.
**날짜 및 도시:** [그럴듯한 미래 출시 날짜와 위치]
**서문:** 제품과 그 혜택을 3-4문장으로 요약하세요. 고객 문제로 시작한 다음 솔루션을 제시하세요. 실제 대중에게 공개되는 보도자료처럼 작성하세요. 내부 전문 용어는 사용하지 마세요.
**문제 단락:** 고객의 현재 어려움을 생생하고 구체적인 용어로 설명하세요. 그들은 오늘날 무엇을 하고 있나요? 왜 불편한가요? 추상적인 진술이 아닌 구체적인 시나리오를 사용하세요. 독자가 그 고통을 느낄 수 있어야 합니다.
**솔루션 단락:** 제품이 문제를 어떻게 해결하는지 설명하세요. 기술이 아닌 고객 경험에 초점을 맞추세요. 그들은 이전에는 할 수 없었던 무엇을 할 수 있게 되었나요? 그들의 삶이나 업무 흐름은 어떻게 변하나요?
**회사 리더 인용문:** 부사장 또는 CEO의 인용문으로 이것이 전략적으로 중요한 이유를 설명하세요. 이는 "왜 지금인지"와 회사의 관점을 명확히 하도록 강제합니다.
**작동 방식:** 3-5문장으로 고객 경험을 설명하세요. 간단한 용어로 행복 경로를 안내하세요. 고객이 이 글을 읽고 실제로 무엇을 해야 할지 이해할 수 있어야 합니다.
**고객 인용문:** 대상 고객이 자신의 말로 혜택을 설명하는 가상이지만 현실적인 인용문입니다. 이는 외부에서 볼 때 성공이 어떤 것인지 생각하도록 강제합니다.
**행동 촉구:** 고객이 어떻게 시작할 수 있는지 한 문장으로 설명하세요.
### 자주 묻는 질문
**외부 FAQ** (고객 대상 - 4-6개 질문):
보도자료를 읽은 후 고객이 물을 질문에 답변하세요. 가격/가용성, 대안과의 비교, 대상 고객(그리고 대상이 아닌 고객), 데이터/개인정보 보호, "그래도..."라는 반론을 다루세요.
**내부 FAQ** (팀 대상 - 4-6개 질문):
리더십 팀, 엔지니어 및 이해관계자가 물을 까다로운 질문에 답변하세요. 시장 규모와 비즈니스 사례, 기술적 타당성과 일정, 종속성과 위험, 왜 지금인가 vs. 나중인가, 우리가 만들지 않는 것, 성공 측정 방법을 다루세요.
### Working Backwards 평가
PR/FAQ를 작성한 후, 한 걸음 물러서서 다음을 평가하세요:
1. **명확성 테스트** - 비기술자가 보도자료를 읽고 제품이 무엇을 하는지 이해할 수 있나요? 그렇지 않다면 아이디어가 여전히 모호한 것입니다.
2. **차별화 테스트** - 경쟁사의 제품이 빈칸을 채울 수 있나요? 그렇다면 고유 가치가 충분히 명확하지 않은 것입니다.
3. **고객 테스트** - 가상 고객이 실제로 그 인용문을 말할까요? 억지스럽다면 혜택이 충분히 현실적이지 않은 것입니다.
4. **내부 FAQ 테스트** - 내부 답변이 설득력 있나요? 손쉽게 넘어가고 있는 부분을 표시하세요. 그것이 가장 큰 위험입니다.
5. **킬 테스트** - 이 PR/FAQ에 기반하여 이 아이디어를 진행, 재작업 또는 폐기해야 할까요? 결정을 내리세요.
규칙:
- 보도자료는 초등학교 수준의 읽기 수준으로 작성하세요. 전문 용어가 필요하다면 아이디어가 충분히 명확하지 않은 것입니다.
- 문제 단락이 가장 중요한 섹션입니다. 고통이 생생하고 구체적이지 않다면 이후의 모든 내용이 모호해질 것입니다.
- 애매모호하게 표현하지 마세요. "이것이 때때로 일부 사용자에게 도움이 될 수 있습니다"는 아이디어가 준비되지 않았다는 신호입니다. 강력한 주장을 하고 FAQ가 미묘한 차이를 다루도록 하세요.
- 내부 FAQ에는 아직 좋은 답이 없는 질문이 적어도 하나 포함되어야 합니다. 그것이 정직한 부분입니다.
- 평가는 냉철하게 솔직해야 합니다. 약한 아이디어를 드러내는 PR/FAQ는 균열을 덮는 것보다 더 가치 있습니다.
팁
- PR/FAQ는 사고 도구이지 마케팅 산출물이 아닙니다. 목표는 구축에 투자하기 전에 모호한 사고를 드러내는 것입니다.
- 문제 단락을 작성하는 데 어려움을 겪는다면 고객을 충분히 이해하지 못한 것입니다. 먼저 jobs-to-be-done 또는 craft-discovery-synthesis를 실행하세요.
- 내부 FAQ에 답변되지 않은 질문이 너무 많다면 run-discovery를 사용하여 격차를 해소할 실험을 설계하세요.
- PR/FAQ가 확고해지면 이를 craft-spec에 입력하여 구축 가능한 PRD로 전환하세요.
- 위험이 큰 베팅의 경우 PR/FAQ에 pre-mortem을 실행하여 내부 FAQ가 놓쳤을 수 있는 위험을 스트레스 테스트하세요.