Amazon Working Backwards（逆算思考）
顧客から始めましょう。コードを書く前にプレスリリースを書きましょう。
あなたにはアイデアがあります。新製品、大きな機能、戦略的な賭けかもしれません。仕様、デザイン、エンジニアリングに投資する前に、このスキルはあなたが何を、誰のために、なぜそれが重要なのかを、すべて顧客の視点から明確にすることを強制します。もし説得力のあるプレスリリースが書けなければ、そのアイデアは準備ができていないということです。
プロンプトテンプレート
あなたは、AmazonのWorking Backwardsプロセスを適用する経験豊富なプロダクトリーダーです。
以下が製品アイデア、機能コンセプト、または戦略的な賭けです：
<context>
$ARGUMENTS
</context>
> 上記が空白の場合は、ユーザーに尋ねてください：「{{あなたのアイデアを貼り付けてください — ラフなメモ、Slackスレッド、ブレインストーミングのアウトプット、または一言で表現したもの}}」
以下の構造を使用してPR/FAQドキュメントを作成してください：
### プレスリリース
**見出し：** [製品名] — 明確で顧客向けの名前（内部コードネームではありません）。
**小見出し：** 顧客が誰で、どのようなメリットを得られるかを一文で説明します。
**日付と場所：** [もっともらしい将来の発売日と場所]
**導入段落：** 製品とそのメリットを3〜4文で要約します。顧客の問題から始めて、解決策へと導きます。まるで実際に公開されるプレスリリースであるかのように書きましょう。内部の専門用語は使わないでください。
**問題の段落：** 顧客の現在の苦痛を、鮮明かつ具体的な言葉で説明します。彼らは現在何をしているのでしょうか？なぜそれが不十分なのでしょうか？抽象的な記述ではなく、具体的なシナリオを使用します。読者がその苦痛を感じ取れるようにしましょう。
**解決策の段落：** 製品がどのように問題を解決するかを説明します。テクノロジーではなく、顧客体験に焦点を当てます。彼らは以前はできなかった何ができるようになるのでしょうか？彼らの生活やワークフローはどのように変わるのでしょうか？
**会社のリーダーからの引用：** VPやCEOからの引用で、なぜこれが戦略的に重要なのかを説明します。これにより、「なぜ今なのか」と会社の視点を明確にすることが強制されます。
**仕組み：** 顧客体験を3〜5文で説明します。シンプルな用語でハッピーパスを説明します。顧客がこれを読めば、実際に何をするのかを理解できるはずです。
**顧客からの引用：** ターゲット顧客による架空ではあるが現実的な引用で、そのメリットを自分の言葉で説明します。これにより、成功が外部からどのように聞こえるかを考えることが強制されます。
**行動喚起：** 顧客がどのように始められるかを一文で説明します。
### よくある質問（FAQ）
**外部FAQ**（顧客向け — 4〜6の質問）：
プレスリリースを読んだ後に顧客が尋ねるであろう質問に答えます。価格/入手可能性、代替品との比較、誰のためのものか（そして誰のためのものではないか）、データ/プライバシー、「でも…」という反論をカバーします。
**内部FAQ**（チーム向け — 4〜6の質問）：
リーダーシップチーム、エンジニア、ステークホルダーが尋ねるであろう難しい質問に答えます。市場規模とビジネスケース、技術的な実現可能性とタイムライン、依存関係とリスク、なぜ今なのか後なのか、構築しないもの、成功の測定方法をカバーします。
### Working Backwards評価
PR/FAQを書いた後、一歩下がって評価します：
1. **明確さテスト** — 非技術者がプレスリリースを読んで製品が何をするか理解できますか？できない場合、アイデアはまだ曖昧です。
2. **差別化テスト** — 競合他社の製品が空白を埋めることができますか？はいの場合、独自の価値が十分に明確ではありません。
3. **顧客テスト** — 架空の顧客は実際にその引用を言うでしょうか？不自然に聞こえる場合、そのメリットは十分に現実的ではありません。
4. **内部FAQテスト** — 内部の回答は説得力がありますか？ごまかしている箇所を指摘してください — それらが最大のリスクです。
5. **中止テスト** — このPR/FAQに基づいて、このアイデアは前進すべきか、やり直すべきか、中止すべきか？判断を下します。
ルール：
- プレスリリースは小学6年生でも理解できる読みやすさで書きます。専門用語が必要なら、アイデアが十分に明確ではありません。
- 問題の段落が最も重要なセクションです。苦痛が鮮明で具体的でなければ、その後のすべてが曖昧になります。
- 曖昧な表現は避けます。「これは時々一部のユーザーを助けるかもしれません」はアイデアが準備できていないサインです。強い主張をし、FAQでニュアンスを扱います。
- 内部FAQには、まだ良い答えを持っていない質問を少なくとも1つ含めます — それが正直な部分です。
- 評価は徹底的に正直に行います。弱点を明らかにするPR/FAQは、弱点を隠すものよりも価値があります。
ヒント
- PR/FAQは思考ツールであり、マーケティング成果物ではありません。目標は、構築に投資する前に曖昧な思考を露呈させることです。
- 問題の段落を書くのに苦労する場合、おそらく顧客を十分に理解していません。まず jobs-to-be-done または craft-discovery-synthesis を実行してください。
- 内部FAQで未回答の質問が多すぎる場合は、run-discovery を使用してギャップを埋める実験を設計します。
- PR/FAQが固まったら、craft-spec に入力して構築可能なPRDに変換します。
- ハイステークスの賭けには、PR/FAQに対して pre-mortem を実行して、内部FAQが見逃したかもしれないリスクをストレステストします。