一句话总结
Forte评估不是你的工作述职，而是你对业务决策的自我裁判。亚马逊PM晋升靠的不是“做了什么”，而是“你如何用六大原则做了别人不敢做的判断”。写Forte时，90%的人犯同一个错：他们把评估写成流水账，而非展现自己如何用16条领导力原则中的至少3条，在资源不足、数据模糊、跨部门反对的情况下，做出了一个让组织长期受益的决定。
不是“我推动了X”，而是“我判断Y，因为Z原则，结果W”。不是“我们团队完成了”，而是“我选择了，我负责”。
适合谁看
- Amazon内部L5/L6 PM，正在准备下一次Forte或晋升文档，尤其是从Sr. PM到Principal的跃迁
- 其他科技公司（Google、Meta、Microsoft）PM，需要理解Amazon独有的“原则驱动”评估体系
- 管理咨询或创业背景转行做PM的人，Forte写作逻辑与你之前的OKR/PPT完全不同
- 任何需要写自我评估，但总觉得写不出“决策感”的产品经理
不适合：刚入职3个月的L4 PM，你还在学习机制，先别急着写晋升。也不适合非产品岗位（如TPM或工程师），Forte对PM的要求完全不同。
核心内容
为什么你的Forte看起来像在“汇报”，而不是在“裁判”？
大多数PM写Forte时，会自然滑向一种叙述模式：“我负责了X项目，取得了Y结果，团队协作良好。”这不是Forte，这是周报。Forte的核心不是展示你做了什么，而是展示你如何判断什么不该做。
具体场景：你的L7 Bar Raiser在review你的Forte时，会问三个问题——第一，这个决策是在数据充分还是模糊的情况下做出的？第二，如果数据充分，你为什么没有更早行动？如果数据模糊，你为什么敢赌？第三，你的决策有没有让其他团队付出代价，而你如何管理这个代价？
不是“我们完成了A/B测试，转化率提升12%”，而是“在数据样本量不足500用户时，我判断继续等待数据会错过Q4窗口。我选择基于离线模拟结果直接上线，并在3周内建立实时监控。结果是转化率提升12%，但更重要的是，我们获得了‘速度优先于完美’的组织习惯。”
这里的关键是：你必须在Forte里主动暴露你的判断过程，而不是隐藏它。亚马逊的晋升委员会（Promotion Committee）要的不是一个“安全”的候选人，而是一个能在不确定中做决定的人。
如何用“客户至上”写出一段让Bar Raiser无法反驳的Forte？
客户至上是Amazon最被滥用的原则。90%的PM写“我深入客户研究”，但Bar Raiser会直接问：“你做了多少访谈？样本偏差在哪？你如何区分‘客户说的’和‘客户做的’？”
正确的写法是展示你如何拒绝客户的请求。具体场景：你负责Amazon Fresh的购物车体验，客户调研显示用户想要“一键重复购买上次订单”。你的团队花了两周原型。
但你在分析购物车数据时发现，80%的重复购买用户会在3天内改变主意，退货率是正常订单的2倍。你判断：这个功能会短期提升购买率，但长期伤害客户信任和退货成本。你砍掉了这个功能，转而优化了“智能推荐替代品”功能——这更符合客户“真正的需求”（减少决策疲劳），而不是他们“说的需求”（重复购买）。
不是“我听取了客户意见”，而是“我判断客户说的不是他们真正需要的，因为数据证明重复购买导致高退货。我选择了更难的路径：改变团队方向，用2周重新设计推荐算法。结果退货率下降15%，客户满意度提升8%。”
这段Forte必须包含：你拒绝的具体场景（2周原型白费）、你依赖的数据（80%退货率）、你做的取舍（短期指标vs长期信任）。Bar Raiser看到的是：你不是一个“听话”的PM，而是一个“有判断”的PM。
为什么“Ownership”不是“我负责”，而是“我承担了谁的怒火”？
Ownership是Amazon最核心但最容易被误解的原则。很多PM写“我own了X项目”，但真正让Bar Raiser注意的是：你有没有在跨部门冲突中主动承担风险，而不是把责任推给其他组。
具体场景：你负责Amazon Music的推荐算法，与Amazon Ads团队有数据共享冲突。Ads团队不愿意提供用户画像数据，因为担心隐私合规。你的团队说“这不是我们的事，让法律团队去谈”。
你判断：如果等法律团队介入，至少6周，Q3目标会泡汤。你主动约了Ads的VP，提出一个折中方案：你的算法只使用聚合匿名数据，且不存储原始数据。你承担了合规风险——如果数据泄露，你的名字会出现在incident report上。
不是“我协调了跨部门合作”，而是“我判断等待法律团队会错失窗口，我主动承担了数据合规风险，在3天内与Ads VP达成协议。结果是推荐点击率提升20%，但更重要的是，我建立了一个可复用的跨部门数据共享框架。”
这段Forte必须包含：你承担的具体风险（合规风险）、你主动的程度（不等法律团队）、你面对的具体反对者（Ads VP）。Bar Raiser看到的是：你不只是own了任务，你own了后果。
如何用“Invent and Simplify”证明你不是在“堆功能”，而是在“砍功能”？
在Amazon，创新不是“加东西”，而是“减东西”。很多PM写“我推出了3个新功能”，但晋升委员会要的是“我砍掉了2个功能，并用一个简单的方案替代了它”。
具体场景：你负责Amazon Go的收银台体验。你的团队有5个工程师在开发“动态定价系统”——根据高峰时段自动调整商品价格。你花了两周分析数据，发现动态定价只能带来2%的利润提升，但需要3个月开发和复杂的合规审查。你判断：这个功能不值得。你砍掉了它，转而用“高峰时段手动折扣”替代——一个每天花15分钟的手动操作，却能实现同样的效果。
不是“我推出了动态定价”，而是“我判断动态定价的收益（2%利润）不值得成本（3个月开发+合规风险）。我砍掉了这个项目，并用一个手动方案替代，节省了团队3个月时间，且利润提升完全一致。”
这段Forte必须包含：你放弃的具体功能（动态定价）、你放弃的理由（收益vs成本）、你选择的简单方案（手动折扣）。Bar Raiser看到的是：你不是一个“功能工厂”，而是一个“资源裁判”。
为什么你的Forte必须包含“失败”，而且是“有判断的失败”？
Amazon的晋升文化里，“失败”不是减分项，而是加分项——前提是你展示了判断力。很多PM回避写失败，或者写成“我们学到了教训”这种套话。这是错的。Bar Raiser要看到的是：你在失败前做了什么判断，失败后你怎么决策。
具体场景：你负责Amazon Prime Video的移动端下载功能。你判断“离线观看”是用户核心痛点，投入3个月开发。上线后，用户使用率只有5%。你分析了数据，发现用户下载电影的平均大小是2GB，而手机存储普遍不足。
你判断：不是功能不好，而是门槛太高。你立刻叫停了后续开发，并转向“智能压缩”功能。这个决策让你在Q2损失了3个月工程资源，但避免了再浪费2个月。
不是“我们开发了离线下载，但使用率低”，而是“我判断离线下载是正确方向，但上线后使用率仅5%。我分析了数据，发现存储是瓶颈。我果断叫停了后续开发，转向智能压缩。结果是使用率从5%提升到30%，但更重要的是，我学会了‘在数据面前认错’的能力。”
这段Forte必须包含：你最初判断的依据（用户痛点）、你失败的具体数据（5%使用率）、你纠正的果断程度（立刻叫停）。Bar Raiser看到的是：你不是一个“从不犯错”的人，而是一个“犯错后能快速止损”的人。
如何用“Hire and Develop the Best”证明你提升了团队，而不是自己？
这条原则在PM晋升里容易被忽略，但L6到L7的晋升必须展示你对团队的影响。不是“我指导了3个实习生”，而是“我改变了团队做决策的方式”。
具体场景：你的团队有5个PM，每个人都在独立做A/B测试。你发现他们每次测试的设计都有偏差——样本量不够、对照组不随机。你判断：这不是个人能力问题，而是流程问题。
你花了一个月，建立了一个“A/B测试标准模板”，包含样本量计算器、随机化检查清单、结果解读指南。你培训了所有人，并让团队每周review一次测试设计。结果：团队的错误率从40%降到5%，测试速度提升2倍。
不是“我培训了团队”，而是“我判断团队的错误根源是流程缺失，而不是技能问题。我建立了一个标准化模板，并设计了review机制。结果是团队测试质量提升8倍，且这个模板被其他4个团队复用。”
这段Forte必须包含：你发现问题的具体场景（5个PM独立做测试）、你判断的错误根源（流程而非技能）、你产出的具体物件（模板+review机制）。Bar Raiser看到的是：你不只是一个PM，你是一个“系统建设者”。
> 📖 延伸阅读：TPM vs TPM: Key Differences in Amazon Interview Loops
准备清单
- 提前6周开始写Forte初稿：别等到deadline前一周。每天写一段，每段聚焦一个原则。写完后关掉电脑，第二天再读，你会发现判断力是否清晰。
- 用“决策日志”倒推案例：翻出你过去6个月的工作记录，找到那些你做了“不是A，而是B”的决策时刻。每个案例必须包含：数据状态（充分/模糊）、反对者是谁、你承担了什么风险。
- 让一个L7或L8 review你的Forte：找一位不在你汇报线上的Bar Raiser。问他：“如果我只读这一段，你能否判断我该不该晋升？”如果他说“不能”，重写。
- 检查每个案例是否包含“具体数字”：不是“提升了效率”，而是“从3天降到8小时”。不是“降低了成本”，而是“节省了$50K/月”。Amazon的晋升委员会对模糊数字过敏。
- 系统性拆解Forte结构：每个案例必须包含“判断（我选择了什么）→ 数据（我看到了什么）→ 风险（我承担了什么）→ 结果（我得到了什么）→ 原则（我用了哪条）”——这个结构在PM面试手册里有完整的实战复盘可以参考，核心是让Bar Raiser在30秒内抓到你的决策逻辑。
- 写一个“失败案例”：选一个你判断失误但及时止损的项目。展示你的决策勇气，而不是完美主义。Amazon的Bar Raiser更信任一个承认错误的人，而不是一个假装全对的人。
常见错误
错误1：把Forte写成“周报合集”
BAD版本：“我负责了Amazon Music的推荐算法优化。我协调了数据团队和工程团队，完成了3轮A/B测试。最终推荐点击率提升15%。”
问题：这像周报，不像Forte。没有判断，没有原则，没有风险。
GOOD版本：“我判断推荐算法的瓶颈不在模型，而在数据源。我拒绝了团队提出的‘升级模型’方案，转而推动与广告团队的数据共享协议。我承担了隐私合规风险（如果数据泄露，我的名字会上incident report）。结果是点击率提升15%，且这个数据共享框架被其他3个产品复用。这个决策体现了Ownership和Customer Obsession。”
区别：GOOD版本展示了判断（选数据源而非模型）、风险（合规风险）、原则（Ownership、Customer Obsession）。BAD版本只是陈述事实。
错误2：回避“我”字，滥用“我们”
BAD版本：“我们团队完成了X项目，我们实现了Y增长，我们协作得很好。”
问题：“我们”让你看起来像团队的一份子，而不是决策者。Amazon的Forte评估的是“你”，不是“团队”。如果所有决策都是团队做的，那你的判断在哪里？
GOOD版本：“我判断X项目是正确的方向，尽管数据团队反对。我主动承担了资源分配决策，砍掉了Z功能，让团队聚焦在X上。结果是Y增长。我亲自处理了与数据团队的冲突，通过每周sync会议建立了信任。”
区别：GOOD版本每个句子主语都是“我”，且展示了“我做了什么判断”、“我承担了什么冲突”。
错误3：只写成功，不写失败
BAD版本：“我负责的Prime Video下载功能取得了30%使用率，客户满意度提升。”
问题：这看起来完美，但Bar Raiser会怀疑：你难道没有犯过错误？完美主义在Amazon是危险信号——它暗示你不敢暴露判断失误。
GOOD版本：“我最初判断离线下载是核心痛点，但上线后使用率仅5%。我分析了数据，发现存储是瓶颈。我果断叫停了后续开发，转向智能压缩。结果使用率提升到30%。这次经历教会我：在数据面前认错，比坚持错误方向更重要。”
区别：GOOD版本展示了失败、数据驱动的纠正、以及从中学习的谦逊。Bar Raiser更信任一个能承认错误的人。
> 📖 延伸阅读：[](https://sirjohnnymai.com/zh/blog/zh-**-buying-decision-amazon-pm-interview-playbook-vs-coaching-2026)
FAQ
Q1: Forte评估里必须包含所有16条领导力原则吗？
不需要。Amazon的晋升委员会明确说：聚焦3-5条最能体现你判断力的原则。如果你试图覆盖所有16条，Forte会变成“原则清单”，而不是“决策故事”。
选2条核心原则（如Ownership、Deliver Results）和1-2条支撑原则（如Customer Obsession或Invent and Simplify）。每个案例里，你只需要明确写出“这个决策体现了X原则”，而不是罗列所有。例如，你的案例里写了“我承担了跨部门冲突的风险”，那就自然指向Ownership，不需要再加一句“这也体现了Hire and Develop the Best”。
Q2: 我今年没有特别大的项目，能写Forte吗？
能，但你必须重新定义“项目”的大小。Amazon的Forte评估的不是项目规模，而是决策质量。一个“小”项目，如果你在数据模糊、资源不足、跨部门反对的情况下做出了关键判断，比一个“大”项目但只是执行更有价值。
具体场景：你只负责一个10人的小功能，但你在功能上线前发现了一个数据隐私漏洞，你主动叫停项目并推动合规审查，避免了潜在的百万美元罚款——这就是一个高影响力的Forte案例。关键不是项目有多大，而是你的判断有多大。
Q3: 我的Forte被L8打回，说“不够具体”，怎么办？
这通常意味着你写的案例缺乏“数据点”和“冲突点”。L8要看的是：你在什么具体时刻、面对什么具体反对者、看到了什么具体数据、做了什么具体取舍。解决办法：打开你的工作日志，找一个“你和其他PM或工程师吵过架”的决策时刻。
然后把吵架的对话写进Forte——不是“我协调了”，而是“我告诉数据团队，‘你的数据是错的，因为样本偏差，我们重做’”。这种具体的对抗和判断，才是L8要的东西。
准备好系统化备战PM面试了吗？
也可在 Gumroad 获取完整手册。