第一性原理与产品心理学
建立每个 PM 决策背后的运营心智、心智模型与具备偏差意识的判断力。
Explainer
产品管理始于一种看待事物的方式。在框架、路线图与指标之前,PM 的工作是把模糊性翻译为可以累积的决策。这意味着同时把用户的现实、业务的经济性与系统的约束放在脑中,并选择接下来该学什么 —— 不回避你已知与你假设之间的差距。
PM 是翻译者,而非小 CEO
把 PM 视为「小 CEO」是一种误导。PM 通常没有团队的雇用/解雇权,也无法单方面决定工程产能。更有用的视角是翻译者:在用户真相与业务结果之间,在战略与工单之间,在今日的可能与下一注成功后将成为可能之间。影响力来自翻译的质量,而不是头衔。
- 把用户痛点翻译为最小的、可学习的问题陈述。
- 把业务目标翻译为团队可以瞄准的可观察的行为变化。
- 把技术约束翻译为团队可以辩论的产品取舍。
用户 vs 客户 vs 购买者 vs 拥护者
大多数 PM 错误从把四种不同的利益相关者塞进一个词开始。用户体验产品;客户付钱;购买者签字;拥护者在内部为产品发声。在 B2C 与 prosumer 中,他们常常重叠为一个人。在 B2B、医疗、政府和市场类产品中,他们是有不同激励、行动意愿差异巨大的不同利益相关者。
- 用户:从日常使用中获得价值或摩擦;承担切换成本。
- 客户:支付账单;关心 ROI、治理与安全。
- 购买者:签合同或批准上线;关心风险与政治。
- 拥护者:在组织内部推动 adoption;关心信誉与可见的胜利。
- 在绘制功能图之前,先按工作流绘制他们。
产品三角:可行性、可用性、可实现性
每一个产品决策都坐落在一个三角内:业务可行性(这能赚钱或省钱吗?)、用户价值与可用性(它真的比替代方案更好地解决了真实问题吗?)、技术可实现性(我们能否用我们的团队和栈来构建、运维和演进它?)。强 PM 在三个透镜之间自如切换;弱 PM 默认让其中之一支配 —— 通常是他们最熟悉的那个。
- 可行性:营收、成本、留存经济、监管与合同暴露。
- 价值与可用性:已被证明的需求、切换意愿、可学习性、可访问性。
- 可实现性:延迟、可靠性、安全、可观测性、维护、团队产能。
- 当利益相关者意见不合时,说出每个人在捍卫哪个角 —— 大多数分歧是角的冲突,不是事实之争。
结果 vs 输出 vs 活动
Marty Cagan 的区分是产品中最有用的之一。输出是你交付的东西;活动是你做的事情;结果是你引发的用户行为或业务表现的变化。大多数团队衡量活动(「这周我们做了 discovery 访谈」),一些团队衡量输出(「我们发布了 8 个功能」),只有最好的团队衡量结果(「新群组中每周活跃编辑者从 41% 升至 49%」)。以输出驱动的路线图看似高效,却很少推动业务。
- 活动最容易伪造,也最常出现在状态报告中。
- 输出感觉像进步,但只有当用户行为改变时才有意义。
- 结果迫使团队承认工作没有移动指标。
- 通过提问重述任何输出陈述:「因此哪种用户行为应当改变,我们如何知道?」
一类 vs 二类决策
Jeff Bezos 的区分:一类决策是单向门 —— 难以或无法逆转(架构选择、公开定价变化、并购)。二类决策是双向门 —— 容易逆转(大多数功能发布、文案修改、单一群组的定价实验)。把二类当一类对待是速度最常见的拖累。把一类当二类对待是灾难最常见的来源。
- 对二类决策默认行动;快上线、快学习,错了就回退。
- 在一类决策上慢下来;请进最强的声音,做 pre-mortem。
- 不确定时直接问:「如果错了,我们如何在 7 天内把它撤回?」
第一性原理思考
类比推理快但有损(「我们就照 Stripe 那样做」)。第一性原理推理慢但更耐用:把问题拆解到无可争辩的事实,再向上构建。PM 用它来挑战继承的假设(「我们一直按席位收费」),在没有基准时从零估算,以及发现并不适合团队真实约束的复制粘贴策略。
PM 应内化的心智模型
心智模型是可重复使用的思维捷径,把经验压缩起来。重点不是死记硬背,而是让六七个时刻挂在嘴边,以便在对话中即时挑选合适的那个。
- 反向思考:不要问「我们如何成功?」,而问「我们如何保证失败?」并避免那些路径。
- Pre-mortem:假设发布失败了,在上线前写出 post-mortem。
- 二阶思考:「然后呢?」绘制后果的后果。
- Steel-manning:在反对之前,先把对方观点说得比对方还强。
- 可证伪性:永远无法被证伪的信念不是有用的信念。
- 汉隆剃刀:能用缺乏上下文充分解释的事,就不要归因于恶意。
- 切斯特顿栅栏:在你弄清它为何被设立之前,不要拆掉它。
PM 的原型(以及为何它们重要)
PM 是科技领域中最广泛的角色之一。Growth PM 的日常与 Platform PM 截然不同。知道你的角色最接近哪个原型,能帮你选出值得投资的指标、伙伴与技能。
- 产品负责 PM:面向终端用户的界面;与设计强协作;关注激活与留存指标。
- Growth PM:实验密集;聚焦漏斗;与市场和数据合作;AARRR 指标。
- Platform / Infra PM:面向内部或开发者;关注易用性、可靠性、采用率;与工程协作能力路线图。
- Technical PM:面对深度技术(API、SDK、数据产品、ML 系统);常以接近协议的方式书写规格。
- Data / ML PM:ground truth、评估、模型行为、数据集权属;与研究协作。
- Internal Tools PM:员工是用户;ROI 是节省的小时数与避免的错误;政治是最难的部分。
决策框架:DACI、RAPID、RACI
产品中的速度,主要是关于谁决定什么的清晰度。DACI(Driver、Approver、Contributors、Informed)与 RAPID(Recommend、Agree、Perform、Input、Decide)对产品决策最有用。RACI 在运营上线中更常见。选一个并坚持使用 —— 形式不及命名一个唯一 Approver / Decide 的纪律重要。
- Driver / Recommend:撰写提案;通常是 PM。
- Approver / Decide:做决定;只有一个人,明确指名。
- Contributors / Input:提供专业意见;他们的工作是被听到,而不是否决。
- Informed:保持知情;不需要表态。
利益相关者地图
利益相关者地图是最被低估的 PM 工件。把利益相关者放进权力 × 兴趣的 2x2 矩阵。高权力 / 高兴趣的人,需要成为计划的共同作者。高权力 / 低兴趣的人,需要被告知,但不必每个细节都征询。低权力 / 高兴趣的人,通常是你的传道者。低权力 / 低兴趣的人,是噪音。
- 在每个季度开始时刷新地图。
- 说出每位利益相关者的个人利害 —— 职业风险、团队负担、品牌影响。
- 规划深思熟虑的接触点,而不是偶遇式的走廊更新。
PM 的操作系统
出色的 PM 以周节奏运转 —— 而非靠英雄主义。一种简单节奏:周一回顾结果(指标相对计划如何?);周中做发现与异步书面工作;周三或周四开跨职能工作会议;周五写一份周报。用一页纸的周报替代状态会议;用分诊队列替代临时请求。
- 默认采用异步书面沟通;把同步留给决策与分歧。
- 维护公开的「now / next / later」,让利益相关者自助获取答案。
- 保留一份私人「未知」清单:每个你尚未验证的假设。
- 为深度工作排专门时段;日历俄罗斯方块是状态游戏,而非生产力策略。
Framework atlas
Reference cards for each method in this mission
Expand a card for when to deploy it, misuse patterns, sequencing guidance, and (where relevant) shorthand formulas.
Decision-making · Atlassian / IntuitDACI(DACI)
一个四角色决策框架,为每个有意义的决策明确命名一个 Driver、一个 Approver、一小组 Contributors 和一份 Informed 名单。
When to use
- 涉及 3+ 团队的跨职能决策。
- 你曾感到「没人负责」的决策。
- 定期的季度规划或路线图会议。
When not to
- 单一团队内真正琐碎的二类决策。
- 当团队小到临时决策比框架开销更便宜时。
How to apply
- 用一句话加截止日期命名决策。
- 指定一个 Driver,负责把决策推进到是/否。
- 指定一个 Approver —— 做最终决定的人。
- 列出 Contributors 并明确注明他们的专业范围。
- 列出 Informed 方并说明如何告知他们。
- 让 Approver 成为一群人:那是委员会,不是 approver。
- 把 Contributors 当作否决权持有者。
- 跳过 Informed 名单 —— 通常是最后一刻戏剧的来源。
Decision-making · Bain & CompanyRAPID(RAPID)
Recommend、Agree、Perform、Input、Decide。比 DACI 更重,但在决策跨越法律/监管边界或有重大财务后果时有用。
When to use
- 有监管或合同暴露的决策。
- 「Agree」(软否决权,通常是法务/安全)与「Input」有实质区别的决策。
When not to
- 日常产品权衡。
- DACI 的更简单结构足够的地方。
How to apply
- Recommend:谁构建提案。
- Agree:谁必须签字(法务、安全、财务)。
- Perform:决策做出后谁执行。
- Input:谁提供专业意见。
- Decide:谁做最终决定。
- 把 Agree 与 Decide 混淆;Agree 是在特定维度上的否决,不是决定。
- 通过 RAPID 路由太多决策 —— 开销会适得其反。
Risk surfacing · Gary KleinPre-Mortem
想象发布失败了,然后提前写 post-mortem。浮现出人们在正常规划中太礼貌或太锚定而不敢提出的风险。
When to use
- 任何一类决策。
- 有声誉、监管或财务暴露的发布。
- 当团队异常乐观时 —— 「这不可能失败」就是警报。
When not to
- 可逆的微实验,失败成本只是一个群组和一周。
How to apply
- 设定场景:「现在是六个月后,项目明显失败了。」
- 每个人静默写 5 分钟:为什么失败了?
- 聚类失败模式;按可能性和影响排序。
- 把前 3-5 个作为要消除的风险加入你的发现和执行计划。
Personal prioritization · Dwight D. EisenhowerEisenhower Matrix
紧急 vs 重要的 2x2。紧急 + 重要:现在做。重要但不紧急:安排。紧急但不重要:委派。都不是:放弃。对个人分诊和功能分诊同样有用。
When to use
- 分诊溢出的收件箱或待办事项。
- 在你的一周中区分反应性支持工作与战略工作。
When not to
- 真正的产品路线图优先级 —— 改用 RICE/ICE/Kano,因为「重要」在规模上太模糊。
How to apply
- 列出每个开放的请求或承诺。
- 把每个标记为紧急或不紧急、重要或不重要。
- 分诊:做、安排、委派、放弃。
- 把「紧急因为有人大声要求」当作「紧急因为截止日期」。
- 让「安排」桶成为拖延墓地。
Team alignment · Andy Grove / Jeff BezosDisagree and Commit
一旦做出决定,即使不同意的人也必须全力承诺。在决策前浮现异议;之后产生团结。与「恶意服从」相反。
When to use
- 在你听到异议并做出决定的二类决策之后。
- 当团队有在侧频道重新讨论决策的文化时。
When not to
- 当异议是关于安全、伦理或监管合规时 —— 这些不应被压制。
How to apply
- 提前明确决策过程(DACI)。
- 在决定前明确邀请异议。
- 一旦做出,问:「你能承诺吗?」—— 接受是或「我不同意但会承诺」。
- 设定审查日期,让异议有未来的听众。
Mental model · G.K. ChestertonChesterton's Fence
在你弄清为何设立之前,不要移除约束、流程或功能。许多「明显愚蠢」的系统是过去失败的疤痕组织。
When to use
- 继承一个「明显应该简化」的代码库、产品或流程。
- 看似不理性的利益相关者推回 —— 找到原始事件。
When not to
- 当原始原因已记录且明显不再适用时。
How to apply
- 识别栅栏(规则、功能、仪式)。
- 与记得它的任期最长的人交谈。
- 搜索 post-mortems 和事件报告。
- 如果原始原因已消失,用清晰的迁移计划移除。
Product Psychology
Cognitive biases that distort product decisions
Confirmation Bias
倾向于寻找、解释和记住支持现有信念的信息,同时忽略矛盾证据。
Product Risk
团队挑选支持性的访谈引语,忽略会使偏好解决方案无效的数据。
Research Countermove
在发现之前,写下什么证据会证伪假设。以同等严格性跟踪假设的胜负。
Survivorship Bias
过度重视可见的成功,而忽略失败并退出数据集的用户、产品或公司。
Product Risk
团队复制突破性产品的做法,却看不到使用相同策略的数十个失败产品。
Research Countermove
以研究强力用户和案例研究的同等严格性,研究流失用户、失败实验、失去的交易和被放弃的工作流。
Anchoring
听到的第一个数字、框架或例子对后续判断产生不成比例的影响。
Product Risk
一个大声的利益相关者的数字成为隐含预测,每个估算都相对于它而不是事实进行调整。
Research Countermove
让估算者在讨论前私下写数字;使用基准率和历史参考类别;在会议中明确指出锚点。
Sunk Cost Fallacy
因为已经花费的资源而继续投资于某个行动方案,而不是基于预期的未来回报。
Product Risk
多季度计划继续获得资金,因为杀死它们会「浪费」先前的工作,即使前向预期价值为负。
Research Countermove
每季度进行「新鲜眼光」审查:「如果我们今天以我们所知开始,我们会资助这个吗?」如果不会,重新定向。
IKEA Effect
人们不成比例地重视他们自己建造的东西。内部团队系统性地高估自己的产品和流程。
Product Risk
PM 和工程偏好内部工具、仪表板或功能,而不是更适合的第三方选项,因为他们记得构建成本。
Research Countermove
在评估中使用盲比较。让团队外的人评价工件。包括维护成本预测,不仅仅是构建成本。
Curse of Knowledge
一旦你理解了某事,就很难想象不理解它;专家系统性地高估他们的解释有多清晰。
Product Risk
PM 假设用户会「理解」工作流,因为团队理解;对团队来说流畅的文案和入职对首次用户来说难以理解。
Research Countermove
对从未见过产品的用户进行无主持测试。把「我不知道在这里做什么」当作本周最有价值的数据。
Loss Aversion
损失的痛苦大约是等价收益快乐的两倍。用户会做不理性的工作来避免失去他们拥有的东西。
Product Risk
团队在日落功能时低估移除成本;用户因一个他们几乎不用的小功能被移除而流失。
Research Countermove
在移除或迁移时,将变化框架为用户获得的收益(更可靠、更快、更少错误)。提供过渡期。在变化前沟通,而不是之后。
Availability Heuristic
最近或生动的例子主导判断,无论它们是否具有代表性。
Product Risk
一次愤怒的高管升级重塑了路线图,因为它在情感上是新鲜的,即使数百个用户有不同的问题。
Research Countermove
在定期视图中汇总证据(支持主题、NPS 逐字记录、流失原因)。强制提问:「这个问题在数据集中有多大,而不是在我的收件箱中?」
Planning Fallacy
系统性地低估任务需要多长时间和花费多少,即使估算者之前经历过同类任务延期。
Product Risk
Sprint 承诺、季度 OKR 和发布计划经常延期;对团队承诺的信任随时间侵蚀。
Research Countermove
使用参考类别预测:最近 3 个类似项目实际花了多长时间?将乐观估算乘以历史延期因子。明确规划未知的未知。
Action Bias
偏好行动而非不行动,即使可用行动的预期价值为负。
Product Risk
团队在指标下降后发布功能以「被看到在做事」,在原因被理解之前;功能本身成为要调试的新变量。
Research Countermove
当指标下降时,在发布修复前隔离原因。跟踪哪些「修复」实际移动了指标,哪些是为活动而活动。
Authority Bias
不成比例地重视权威人物的意见,无论底层证据如何。
Product Risk
高管的随意评论成为季度目标,因为没人推回。
Research Countermove
将信息与信使分开。将高管的想法重述为假设,然后像评估任何其他假设一样基于证据评估它。
Bandwagon Effect
信念和实践传播是因为其他人在采用它们,无论它们是否适合本地环境。
Product Risk
团队采用框架(OKRs、Shape Up、ICE)因为同行公司这样做,然后在环境不匹配导致失败时责怪框架。
Research Countermove
在采用任何实践之前,阐明它为*你*解决的具体问题。如果你不能,你在货物崇拜。
Status Quo Bias
偏好当前状态;替代方案被视为相对于现状的损失。
Product Risk
遗留产品行为受到保护,即使数据显示它们伤害新用户;「我们不能破坏现有用户」成为无条件否决。
Research Countermove
量化现状的成本。通常变化的假定风险被停滞的持续成本所矮化。
Dunning-Kruger Effect
在某个领域的低能力通常与过度自信相关;有能力的从业者矛盾地更清楚他们不知道什么。
Product Risk
初级 PM 在他们几乎不理解的领域发布自信的路线图;高级 PM 犹豫太多以至于看起来优柔寡断。
Research Countermove
对于自信的主张,问:「反对这个的最强论据是什么?」如果你不能提出一个,你还不理解这个领域。
Rhyme-as-Reason Effect
朗朗上口或押韵的陈述比同样精确但不那么优雅的陈述感觉更真实。
Product Risk
令人难忘的研究摘要被重复为路线图驱动的真理,即使底层证据薄弱。
Research Countermove
将任何朗朗上口的短语翻译为与观察到的行为或数据相关的可证伪假设。
Organizational anti-patterns
When ceremonies look like rigor but aren't
The Feature Factory
路线图进度以每季度发布的功能衡量。结果仅在方便时报告。发现就是 sprint 的第 1 周。
输出容易计数;结果需要时间和诚实。活动在绩效评审中成为影响的代理。
将每个路线图项目重新基于目标指标移动。在评审中杀死功能计数指标。像庆祝发布的好赌注一样庆祝杀死的坏赌注。
Stakeholder Ventriloquism
PM 用「CEO 想要」或「销售说」来证明决策;没有呈现第一手用户证据;团队感觉像交付服务。
PM 回避冲突或信息不足,使用权威洗白来推动项目。
在将每个利益相关者请求带给工程之前,将其翻译为用户问题和证据清单。如果证据薄弱,向上推回。
Solutioneering
规格直接跳到 UI 模拟。第一张幻灯片是屏幕,不是问题。发现(如果有的话)在设计开始后发生。
解决方案具体且令人兴奋;问题抽象且不舒服。
在任何 UI 之前,在每个规格的第 1 页写下问题陈述、用户、当前替代方案和成功指标。
The Roadmap as Wishlist
路线图有 40 个项目,都是 H2 优先级,没有排序理由。每个季度,团队承诺所有项目并完成三分之一。
PM 使用路线图来安抚利益相关者,而不是下注。
将路线图限制为「现在 / 下一个 / 以后」,每季度不超过 3-5 个主题。在前期强制权衡对话,而不是在最后。
Discovery Theater
团队进行「发现」,包括在规格编写后进行几次用户访谈。发现被总结以确认现有计划。
发现被采用为仪式而不是学习循环。
在访谈*之前*定义最危险的假设和证伪标准。保留基于发现改变规格或杀死项目的权利。
Outcome Theater
每个项目突然与模糊的结果相关(「改善用户体验」);没人能就哪个指标、基线或阈值算作成功达成一致。
团队听说「以结果为中心」,但在定义和衡量结果方面缺乏严格性。
强制三要素:指标、基线、目标、截止时间。如果你不能为一个计划写出所有四个,它是伪装成结果的输出。
Worked examples
Walkthroughs translated from real trade-off rooms
重新框架「让注册更容易」
一个 B2B SaaS PM 收到销售的请求:「我们在注册时失去试用用户。让注册更容易。」
- 抵制解决方案:「更容易」不可证伪。
- 定义用户行为:「在点击邮件后 10 分钟内到达第一个有价值的动作。」
- 拉取数据:38% 的试用在邮件确认和团队邀请步骤之间流失。
- 对现有流程进行 5 次无主持测试;观察摩擦点。
- 提出两个范围实验:懒加载团队邀请或简化邮件确认。
Takeaway功能请求「让注册更容易」变成了两个与可衡量行为相关的可证伪赌注,在一类承诺之前有一个快速的二类实验来学习。
使用产品三角对高管请求说不
CEO 想在本季度向营销网站添加聊天小部件以「吸引潜在客户」。
- 承认目标:更多合格的管道。
- 走三角:可行性 —— 对合格管道的预期提升是什么?可用性 —— 潜在客户现在真的想要同步聊天吗?可实现性 —— 在发布季度在三个时区为聊天配备人员。
- 提出两个替代方案:带回复 SLA 的较小异步表单,或仅针对合格账户的聊天小部件。
- 用 DACI 框架决策:Driver: PM;Approver: CEO;Contributors: Sales、CS、Design、Eng。
Takeaway对字面请求说不,对底层目标说是,并给 CEO 一个真正的决策而不是礼貌的拒绝。
在发现冲刺中捕捉确认偏误
团队确信下一个大赌注是协作编辑。8 次访谈后,引语集压倒性地支持。
- 暂停并写下证伪标准:「如果少于 30% 的用户自发描述最近的协作编辑痛点,需求比我们想象的弱。」
- 按自发性重新标记访谈语料库:有多少引语是未提示的 vs 提示的?
- 发现大多数支持性引语是提示的;只有 18% 是未提示的。
- 重新框架赌注:协作编辑在概念上是需要的,但还不是首要痛点。将其从 Q1 移到 Q3,并用真正的首要痛点回填。
Takeaway确认偏误悄悄地夸大了感知需求。一个简单的证伪检查重新平衡了路线图。
Resources / Case Studies
Curated reading for this mission
Ben Horowitz
1996 年关于强产品经理与弱产品经理失败模式的预期操作标准的备忘录。
围绕对结果的责任而不是活动或流程剧场来锚定产品心态。
Marty Cagan (SVPG)
关于现代产品管理的经典文本。涵盖产品发现、产品三人组、结果 vs 输出以及赋权产品团队的角色。
定义了行业其余部分使用的词汇。必读。
Marty Cagan & Chris Jones (SVPG)
INSPIRED 的配套卷。专注于产品领导者必须做什么来使赋权产品团队能够发现和解决真正的问题。
弥合 PM 工艺与让该工艺复合的组织系统之间的差距。
Lenny Rachitsky
PM 一周的具体分解,包括发现、交付、对齐和管理的时间分配。
为新 PM 揭开工作的神秘面纱,并为有经验的 PM 提供基准,了解他们可能在哪里投资过多或不足。
Shreyas Doshi
高能动性 PM 如何运作:拒绝虚假约束,寻找杠杆,将模糊性翻译为行动。
关于区分伟大 PM 与称职 PM 的操作心态的最集中演讲。
Julie Zhuo
关于管理早期的实用、坦率指南 —— 适用于工作越来越多地通过他人完成的高级 PM。
在没有通常的 MBA 废话的情况下,架起 IC PM 和 Lead PM 过渡的桥梁。
Teresa Torres
将发现操作化为每周习惯而不是阶段。介绍机会解决方案树。
为想要从功能请求转向需求驱动产品决策的 PM-设计-工程三人组设定实用基线。
Marty Cagan (SVPG)
Cagan 关于产品团队应如何构建和问责的阐述:赋权团队、结果和作为持续实践的发现。
结晶课程其余部分假定的操作模型。
Jeff Bezos (1997 Shareholder Letter)
一类 / 二类区分,用 Bezos 自己的话,嵌入在他 2015 年给股东的信中。
提供可重用框架,将决策速度与可逆性匹配 —— 日常 PM 工具。