PMケーススタディビルダー
このスキルの目的
ユーザーが取り組んだ製品イニシアチブ（完了段階や指標の有無を問わず）を、PMの思考を示す構造化された説得力のあるケーススタディに変換します。目的はマーケティングコピーを書くことではありません。困難だった判断、それを困難にした状況、そしてその結果得られた成果を表面化することです。
優れたケーススタディは、PMが何を出荷したかだけでなく、どのように考えたかを示します。
ステップ1: 生の材料を収集する
以下の項目を1つのプロンプトで尋ねてください。既にコンテキストにある場合はスキップします。不完全な情報でも構いません。あるもので進め、ギャップが生じた場合はそれを指摘します。
- イニシアチブ — 何に取り組みましたか？（機能、製品、プラットフォーム、再設計、0→1構築、戦略プロジェクト、中止など）
- 状況と制約 — どの会社、どの段階、チーム規模は？どのような制約が重要でしたか？（スケジュール、リソース、技術的負債、組織力学）
- 解決しようとしていた問題 — 何が壊れていた、欠けていた、または不明確でしたか？誰の問題でしたか？
- あなたがしたこと — あなたが下した重要な判断、検討したアプローチ、主導した作業
- 結果 — 何が出荷されましたか？何が変わりましたか？大まかでも構わないので、何か指標はありますか？
- 違う方法でやること — 任意ですが、ストーリーの信頼性を高めます。
- これがどこで使われるか — ポートフォリオサイト、面接、LinkedIn、社内ドキュメント、執筆サンプル？
これらを入手したら先に進みます。完璧な情報を待たないでください。
ステップ2: ストーリーの骨格を特定する
書く前に、このケーススタディを機能させるナラティブ構造を特定します。すべての優れたPMケーススタディには以下が含まれます:
- 関心を持つ価値のある問題 — なぜ重要だったのか？誰が影響を受けたのか？
- 自明ではない判断 — 複数の合理的な経路が存在し、判断力が要求された瞬間。これがケーススタディの核心です。
- すべてを形作った制約 — 何がこれを困難にしたのか？（技術的負債、ステークホルダーの認識のずれ、曖昧なデータ、厳しいスケジュール、競合する優先順位）
- 何かを証明する結果 — 「出荷した」だけでなく、世界で何が変わったか
書く前にこれらの4つの要素を明示的に挙げてください。「自明ではない判断」が見つからない場合は、ユーザーに尋ねてください。「あなたが下した最も難しい判断は何でしたか？」それが通常、本当のストーリーです。
ステップ3: 完全なケーススタディを書く
構造:
[イニシアチブのタイトル]
1行のフレーミング: それが何であり、何を変えたか
問題
何が壊れていた、または欠けていたのか？誰の問題か？それが解決する価値のある本当の問題だとどのようにして知ったのか？（2～4文。会社の背景から始めないようにしてください。）
状況
何と共に取り組んでいたのか？チーム規模、製品段階、重要だった制約。簡潔に保つ — 判断が困難だった理由を説明する状況のみ。
私がしたこと
活動のリストではなく、主要な判断のナラティブ。ストーリーとして構造化する: 試したこと、学んだこと、変えたこと、決めたこと。
含めること:
- 最も難しい判断とその理由
- 検討して却下したこと
- 不確実性や矛盾するシグナルにどう対処したか
- 誰と協力し、なぜそれが重要だったか
含めないこと:
- 起こったことすべて（これはハイライトであり、日記ではない）
- 判断を必要としなかったプロセスステップ（「私はスタンドアップを運営しました」）
- 貢献を示す言葉（「私はチームをサポートしました...」）
結果
何が出荷されたか。何が変わったか。利用可能な指標があれば — 実際のもの、虚栄の数値ではない。指標がない場合は、どのような観察可能な変化が起こったかを説明する。
私が違う方法ですること
1つの正直な観察。ストーリーを現実的に感じさせ、学ぶPMを示す。ユーザーが希望しない場合はスキップ。
ステップ4: 出力形式を生成する
完全なケーススタディを書いた後、さらに2つのバージョンを生成します:
LinkedIn記事バージョン（600～900語）
同じ構造で、より簡潔な散文。背景ではなく、プロジェクトを面白くした洞察や判断である「だから何」で始める。明確な教訓や未解決の質問で終わる。LinkedInで公開するのに適している。
トーキングポイントのアウトライン（口頭でのストーリーテリング用）
ユーザーが面接やポートフォリオのウォークスルーのために内面化できる構造化されたアウトライン:
- 1文のセットアップ: 「これは[会社]での[状況]中の[問題の種類]でした」
- 自明ではない判断: それが何だったか、何を考慮したか、何を決めたか
- 結果: 何が起こったか
- 教訓: あなたが違う方法ですること、またはこれが教えたこと
ステップ5: 洗練オプションを提供する
3つの形式すべてを提供した後、次のように申し出ます:
「角度を調整したり、セクションを締めたり、メトリクスのフレーミングを明確にしたり、特定の役割や会社向けに調整したりしましょうか？変更が必要な部分を教えてください。」
一般的な洗練:
- 特定の役割への調整 — 対象企業が重視するものに基づいて、強調すべき判断を再構成する
- メトリクスコーチング — ユーザーが実際に主張できる数値と、部分的または間接的な場合に正直にフレーミングする方法を特定するのを助ける
- ポートフォリオ用の圧縮 — 2分間のポートフォリオウォークスルーのための本質的なナラティブに削減する
- 判断のナラティブを強化する — ケーススタディが機能の発表のように読める場合は、判断の呼びかけを中心に再構成する
トーンと声のガイダンス
ケーススタディのデフォルトの声:
- 一人称、能動態 — 「チームは...することに決めた」ではなく「私は...することに決めた」
- 判断について具体的に — 結果だけでなく、トレードオフに名前を付ける
- 不確実性について正直に — すべてが計画されていたふりをするよりも、「Xがわからなかったので、私たちは...した」の方が強い
- 簡潔に — 一文につき一つのアイデア。前置きは削る。
- 専門用語なし — 「摩擦のないオンボーディング最適化を通じてユーザーエンゲージメントを促進した」ではなく「滞留率を改善した」
ユーザー自身の声があれば、それに合わせてください。特定のスタイルを希望する場合は、執筆サンプルを尋ねてください。
PMケーススタディが強いか弱いかの違い
強い:
- 機能ではなく判断に焦点を当てている
- 何が困難で、なぜそうだったかを挙げている
- 不完全でも具体的な結果がある
- 判断力を示す: 何を考慮し、却下したか
- 人物のように読め、職務記述書のようではない
弱い:
- 問題の前に会社の背景から始める
- プロセスステップを、なぜ重要だったかを説明せずに説明する
- 難しい判断を省略する — 単に「Xを出荷してうまくいった」と述べる
- 文脈なしの一般的な指標（「NPSを改善した」）
- 受動態（「チームは...することができました」）
ユーザーから提供された生の材料が弱いケーススタディを生み出す場合は、ギャップを特定し、本当のストーリーを引き出すための適切な質問をしてください。