PM 案例研究建構器
這個技能做什麼
接收使用者曾參與的一項產品計畫——無論完成程度為何，無論是否有精確的指標——並建立一個結構化、引人入勝的案例研究，以展現 PM 的思維能力。目標不是撰寫行銷文案，而是凸顯那些困難的決策、讓決策變得困難的背景，以及最終的成果。
一個好的案例研究展現的是 PM 如何思考，而不只是他們交付了什麼。
步驟 1：收集原始素材
在一個提示中詢問以下資訊。如果任何內容已在上下文中，則跳過提問。資訊不完美也沒關係——你會利用現有資訊進行，並標記缺口，而非卡關等待。
- 計畫內容 — 你做了什麼？（功能、產品、平台、重新設計、從零到一的建置、策略專案、取消等）
- 背景與限制 — 在哪家公司、什麼階段、團隊規模多大？哪些限制很重要（時間表、資源、技術債、組織動態）？
- 你正在解決的問題 — 什麼是壞掉的、缺失的或不清楚的？這是誰的問題？
- 你做了什麼 — 你做出的關鍵決策、你考慮過的方法、你主導的工作
- 成果 — 交付了什麼？改變了什麼？任何指標，即使很粗略也行？
- 你會怎麼做不同 — 可選，但能讓故事更可信
- 這將用在哪裡 — 作品集網站、面試、LinkedIn、內部文件、寫作樣本？
一旦獲得這些資訊，就繼續進行。不要等待完美資訊。
步驟 2：識別故事主軸
在寫作之前，先識別讓這個案例研究有效的敘事結構。每個強而有力的 PM 案例研究都有：
- 值得關心的問題 — 為什麼這很重要？誰受到影響？
- 非顯而易見的決策 — 存在多個合理路徑、需要判斷力的時刻。這是案例研究的核心。
- 塑造一切的限制條件 — 是什麼讓它變得困難？（技術債、利害關係人意見分歧、模糊的數據、緊迫的時間表、相互競爭的優先事項）
- 證明某事的成果 — 不只是「我們交付了它」，而是世界改變了什麼
在寫作前明確標示這四個要素。如果你找不到「非顯而易見的決策」，請詢問使用者：「你做出的最困難的決定是什麼？」那通常就是真正的故事。
步驟 3：撰寫完整的案例研究
結構：
[計畫標題]
一行說明：它是什麼以及它改變了什麼
問題
什麼是壞掉的或缺失的？這是誰的問題？你怎麼知道這是值得解決的真正問題？（2–4 句話。抵製從公司背景開始的衝動。）
背景
你當時有什麼條件？團隊規模、產品階段、重要的限制。保持精簡——只有那些能解釋為什麼決策困難的背景。
我做了什麼
關鍵決策的敘述，而不是活動列表。以故事結構呈現：你嘗試了什麼、學到了什麼、改變了什麼、決定了什麼。
包含：
- 最困難的決定及其背後的理由
- 你考慮過並排除的選項
- 你如何處理不確定性或相互矛盾的訊號
- 你和誰一起工作，以及為什麼那很重要
不包含：
- 發生的一切（這是重點，不是日記）
- 不需要判斷力的流程步驟（「我主持了站立會議」）
- 貢獻用語（「我支援團隊……」）
成果
交付了什麼。改變了什麼。如果有指標，使用真實的——不是虛榮數字。如果沒有指標，描述發生了什麼可觀察的變化。
我會怎麼做不同
一個誠實的觀察。讓故事感覺真實，並顯示 PM 會學習。如果使用者偏好，可以跳過。
步驟 4：產出輸出格式
在撰寫完整的案例研究後，生成兩個附加版本：
LinkedIn 文章版本（600–900 字）
相同的結構，更緊湊的散文。以「所以呢」開頭——讓專案有趣的見解或決策——而非背景。以明確的收穫或開放式問題結尾。適合在 LinkedIn 上發布。
談話要點大綱（用於口語敘事）
一個結構化的大綱，使用者可以內化用於面試或作品集導覽：
- 一句話設定：「這是在 [公司] 處於 [背景] 時的一個 [問題類型]」
- 非顯而易見的決策：它是什麼，你考慮了什麼，你決定了什麼
- 成果：發生了什麼
- 教訓：你會怎麼做不同，或這教會了你什麼
步驟 5：提供修改建議
在交付所有三種格式後，提供：
「想要調整角度、縮緊某個章節、強化指標框架，或針對特定職位或公司客製化嗎？告訴我需要改變什麼。」
常見的修改：
- 針對特定職位客製化 — 根據目標公司關心的內容，重新強調哪些決策
- 指標指導 — 幫助使用者弄清楚他們實際上可以主張哪些數字，以及如何在數字不完整或間接時誠實地呈現它們
- 濃縮用於作品集 — 剪裁至 2 分鐘作品集導覽的必要敘事
- 強化決策敘事 — 如果案例研究讀起來像功能公告，圍繞判斷呼叫重新組織
語調與聲音指引
案例研究的預設聲音：
- 第一人稱，主動 — 「我決定要……」而不是「團隊決定要……」
- 具體說明決策 — 說出取捨，而不只是結果
- 誠實面對不確定性 — 「我們不知道 X，所以我們……」比假裝一切都有計劃更強而有力
- 精簡 — 一句話一個想法。刪掉開場白。
- 不用行話 — 「我們改善了留存率」而不是「我們透過無摩擦的新手引導優化驅動了使用者參與度」
如果使用者有自己的聲音，請配合。如果他們想要特定風格，請索取寫作樣本。
強弱 PM 案例研究的區別
強項：
- 圍繞決策，而非功能
- 說出什麼是困難的及其原因
- 有具體的成果，即使不完美
- 展現判斷力：考慮過並排除的選項
- 讀起來像一個人，而不是一份職位描述
弱項：
- 在問題之前先介紹公司背景
- 描述流程步驟，卻不解釋為什麼它們重要
- 跳過困難的決策——只說「我們交付了 X，它成功了」
- 通用指標（「改善 NPS」）而沒有背景
- 被動語句貫穿全文（「團隊能夠……」）
如果使用者提供的原始素材會產生薄弱的案例研究，請指出缺口並提出正確的問題來解鎖真正的故事。