PM 案例研究构建器
此技能的作用
将用户负责的产品项目——无论完成度如何，无论是否有精确指标——转化为一份结构清晰、引人入胜的案例研究，展示产品经理的思考过程。目标不是撰写营销文案，而是揭示那些艰难的决策、使其艰难的背景以及最终产生的结果。
一份好的案例研究展示的是产品经理的思考方式，而不仅仅是他们交付了什么。
步骤 1：收集原始素材
在一次提示中询问以下内容。如果任何信息已在上下文中，则跳过。信息不完整也没关系——你将基于现有信息工作，并在需要时指出缺口，而不是因此阻塞。
- 项目 —— 你做了什么？（功能、产品、平台、重新设计、从0到1构建、战略项目、取消等）
- 背景与约束 —— 什么公司、什么阶段、团队规模？哪些约束很重要（时间表、资源、技术债务、组织动态）？
- 你正在解决的问题 —— 什么东西坏了、缺失或不清晰？这是谁的问题？
- 你所做的 —— 你做出的关键决策、考虑过的方法、你领导的工作
- 成果 —— 交付了什么？改变了什么？任何指标，即使是粗略的？
- 你会做得不同的事情 —— 可选，但能使故事更可信
- 这将用于何处 —— 作品集网站、面试、LinkedIn、内部文档、写作样本？
一旦获得这些信息，继续下一步。不要等待完美的信息。
步骤 2：确定故事主心骨
在写作之前，确定使这份案例研究有效的叙事结构。每一份强大的PM案例研究都有：
- 值得关心的难题 —— 为什么这很重要？谁受到了影响？
- 非显而易见的决策 —— 存在多个合理路径、需要判断的时刻。这是案例研究的核心。
- 决定一切的约束 —— 是什么让这变得困难？（技术债务、利益相关者意见不合、模糊数据、紧迫时间表、相互竞争的优先级）
- 能证明某些东西的成果 —— 不仅仅是“我们交付了”，而是世界发生了什么变化
在写作之前明确命名这四个要素。如果找不到“非显而易见的决策”，询问用户：“你做出的最艰难的决定是什么？”这通常是真正的故事。
步骤 3：撰写完整的案例研究
结构：
[项目标题]
一行概括：它是什么以及它改变了什么
问题
什么东西坏了或缺失？这是谁的问题？你如何知道这是一个值得解决的真正问题？（2-4句话。克制以公司背景开始的冲动。）
背景
你当时有什么条件？团队规模、产品阶段、重要的约束。保持紧凑——只包含解释决策为何艰难的背景。
我所做的
关键决策的叙述，而非活动清单。以故事形式组织：你尝试了什么，你学到了什么，你改变了什么，你决定了什么。
包括：
- 最艰难的决策及其背后的推理
- 你考虑过并排除的方案
- 你如何处理不确定性或冲突信号
- 你和谁合作以及为什么这很重要
不包括：
- 发生的所有事情（这是亮点，不是日记）
- 不需要判断的流程步骤（“我主持了站会”）
- 贡献性语言（“我支持团队...”）
成果
交付了什么。改变了什么。指标如果有的话——真实的指标，而不是虚荣指标。如果没有指标，描述发生了哪些可观察的变化。
我会做得不同的事情
一个诚实的观察。让故事感觉真实，并显示这是一个会学习的产品经理。如果用户偏好，可以跳过。
步骤 4：生成输出格式
在撰写完整案例研究后，生成两个额外版本：
LinkedIn 文章版本（600-900字）
相同的结构，更紧凑的散文。以“那又怎样”开头——使项目有趣的洞察或决策——而不是背景。以一个清晰的结论或开放性问题结束。适合在LinkedIn上发布。
要点大纲（用于口头叙述）
用户可以在面试或作品集演示中内化的结构化大纲：
- 一句话设定：“这是一个在[公司]在[背景]下的[问题类型]”
- 非显而易见的决策：它是什么，你考虑了什么，你决定了什么
- 成果：发生了什么
- 教训：你会做得不同的事情或这教给了你什么
步骤 5：提供优化建议
在交付所有三种格式后，提供：
“想要我调整角度、收紧某个部分、优化指标表述，或针对特定职位或公司定制？只需告诉我需要更改什么。”
常见优化：
- 针对特定职位定制 —— 根据目标公司关注的重点，重新强调哪些决策
- 指标指导 —— 帮助用户找出他们实际可以宣称哪些数字，以及如何在不完整或间接的情况下诚实地表述
- 为作品集精简 —— 为2分钟的作品集演示缩减到核心叙述
- 强化决策叙述 —— 如果案例研究读起来像功能公告，则围绕判断调用进行重构
语气和声音指导
案例研究的默认语气：
- 第一人称，主动语态 —— “我决定...” 而不是 “团队决定...”
- 决策具体化 —— 说出权衡，而不仅仅是结果
- 对不确定性诚实 —— “我们不知道X，所以我们...” 比假装一切都有计划更强大
- 精炼 —— 每句话一个想法。去掉开场白。
- 无行话 —— “我们提升了留存率” 而不是 “我们通过无摩擦的入门优化推动了用户参与度”
如果用户有自己的声音，与之匹配。如果他们想要特定风格，要求提供写作样本。
PM 案例研究的强与弱
强：
- 围绕决策，而不是功能
- 指出什么是困难的以及为什么
- 有具体的结果，即使是不完美的
- 显示判断力：考虑过什么并排除了什么
- 读起来像一个人，而不是职位描述
弱：
- 在问题之前先介绍公司背景
- 描述流程步骤而未解释为什么它们重要
- 跳过艰难决策——只说“我们交付了X，它成功了”
- 通用指标（“提升了NPS”）而没有背景
- 全文被动语态（“团队能够...”）
如果用户提供的原始素材会产生一个弱案例研究，指出差距并提出正确的问题以挖掘真实故事。