Amazon Forte自我评估：PM晋升中文示例
一句话总结
正确的判断是：在Amazon的Forte自评里，最关键的不是罗列项目数量，而是用“影响力·深度·所有者”三维度精准量化每一件事的商业价值。多数候选人以为只要写满页数就能通过，实际评审会把空洞的叙述直接剔除。
你有没有遇到过这种情况：觉得自己答得还行，但面试官突然变脸？这背后的评分逻辑，《面试自我介绍·黄金90秒》里拆解得很透。
适合谁看
本篇针对已经在Amazon担任产品经理（L5）并准备申请L6晋升的内部同事，以及准备进入Amazon做PM且想提前了解内部评审标准的外部候选人。阅读者应具备至少两年完整的PM全栈经验，熟悉Amazon的Leadership Principles，并且能够提供可量化的业务数据。
核心内容
1. Forte自评的结构到底该怎么拆？
Forte自评分为四大块：项目概述、个人贡献、影响范围、后续行动。不是把所有项目堆在“项目概述”，而是把每个项目拆成独立的“案例”。不是只写“我负责需求收集”，而是要写“我通过A/B实验把转化率提升12%”。在实际的内部评审会议（debrief）里，评审官会先挑出每个案例的“关键指标”，如果指标前后对比缺失，案例立即被标记为“缺乏证据”。因此，写作时必须在每段结尾附上明确的前后对比数字、时间跨度以及对应的Amazon业务线（如Prime Video、AWS Marketplace）。
2. 影响力的度量——从“团队层面”到“公司层面”
不是只说“我带领团队完成里程碑”，而是要把团队的产出映射到公司整体的KPIs。举例：在2023 Q2，我主导的跨部门项目把Prime Video的推荐召回率提升了8%，直接贡献了约1500万美元的新增订阅收入。一次HC（Hiring Committee）讨论中，Hiring Manager问：“这个提升对公司整体收入占比多少？”我直接回答：“约0.6%，相当于全公司Q2增长的15%”。这种把团队成果转化为公司层面价值的叙述，能够让评审快速定位你的影响力层级。
3. 深度 vs. 广度——如何在自评里平衡
不是把所有项目都写成“一句话”，而是挑选2-3个最能体现“所有者心态”的项目做深挖。不是把每个项目都写成“我负责…”，而是要把“所有者”体现在决策权、风险承担与结果归因上。例如，在一次跨部门冲突（与AWS Billing团队）中，我主动承担了费用归因模型的重新设计，在48小时内交付MVP，避免了因计费错误导致的潜在200万美元损失。该案例在debrief会上被评审称为“所有者行为的典型”。
4. 量化的语言——避免空洞的形容词
不是使用“显著提升”“极大改进”，而是用具体的百分比、绝对值和时间窗口。不是写“我很擅长沟通”，而是写“我每周组织2次跨职能同步会，平均会议时长30分钟，议题完成率从上个季度的68%提升到本季度的94%”。在实际面试的“Leadership Principles”环节，面试官会要求你用STAR结构复述，若没有量化数据，面试官会直接转向下一个问题。
5. 时间线的严谨性——每一步都要标注起止点
不是只写“项目上线”，而是要写“项目从需求立项（2022‑03）到上线（2022‑09）历时6个月”。在一次内部审计（内部审计团队对PM自评进行抽查）中，发现有同事把2021年的项目误写成2022年，导致评审直接打了0分。时间线的准确性是评审核查的第一道门槛。
准备清单
- 收集所有在职期间的业务指标原始报表，确保每个数字都有来源。
- 选定3–4个最能体现“影响力·深度·所有者”的案例，确保每个案例都有前后对比、时间跨度、涉及的业务线。
- 用STAR结构把每个案例写成300字以内的段落，段落末尾必须加上“前后对比：X%提升，贡献Y美元”。
- 系统性拆解面试结构（PM面试手册里有完整的“案例复盘”实战章节可以参考），确保每轮面试的重点都对应到自评的相同维度。
- 预演一次内部debrief，邀请一位已经晋升的L6同事扮演评审角色，检验自评的逻辑连贯性。
- 检查所有时间线、数字、业务线名称的准确性，避免出现2022写成2023的错误。
- 了解当前L6的薪酬结构：Base $180,000，RSU $120,000/年（4年归属），Bonus $30,000（基于个人+团队绩效）。
常见错误
错误示例A（BAD）
“我负责了Prime Video的推荐系统优化，提升了用户体验。”
评审记录：缺乏量化，未标明影响范围，无法判断是否具备所有者心态。
改进示例B（GOOD）
“在2023 Q1，我牵头Prime Video推荐系统的A/B实验，实验组CTR提升12%，转化率提升8%，对应新增订阅收入约1500万美元，项目从需求立项（2023‑01）到上线（2023‑04）历时3个月。”
评审记录：明确量化、时间线、业务价值，直接映射到公司KPIs。
错误示例C（BAD）
“我与跨部门合作，解决了计费错误问题。”
评审记录：描述模糊，未说明个人决策点与风险承担。
改进示例D（GOOD）
“2022‑07，我发现AWS Billing计费模型导致潜在200万美元损失，主动召集5个相关团队，48小时内交付重新设计的费用归因模型，避免了该损失，并在上线后第一周即验证准确率提升至99.8%。”
评审记录：突出所有者行为、风险承担、具体结果。
错误示例E（BAD）
“我组织了团队会议，沟通顺畅。”
评审记录：空洞形容词，没有数据支撑。
改进示例F（GOOD）
“自2022‑09至2023‑02，我每周主持跨职能同步会，平均时长30分钟，议题完成率从68%提升至94%，团队满意度调查分数提升至4.7/5。”
评审记录：提供明确的KPI提升，展现沟通效率。
FAQ
Q1：如果我的项目没有直接的收入贡献，能否仍然写进自评？
答案是肯定的，但必须转换成对公司关键指标的间接价值。比如一次内部工具的自动化改造，虽然没有直接收入，却把运营成本降低了15%，对应的年度节约约300万美元。一次HC讨论中，候选人用“成本节约”而不是“功能上线”说服了评审，最终得到了正面评价。
Q2：在自评里出现的数字被质疑怎么办？
评审会要求提供原始数据或BI报表链接。最佳做法是提前在自评的脚注里注明数据来源（如QuickSight报表ID），并在内部debrief时把对应的PDF或截图准备好。一次内部审计中，有同事因为未准备数据被迫现场补报，导致评审时间被压缩，最终自评被打了低分。
Q3：面试的每一轮具体会考哪些维度？
第一轮（45分钟）聚焦Leadership Principles，重点在“所有者”和“客户至上”，面试官会让你复盘一次跨部门冲突。第二轮（60分钟）是产品设计，要求在30分钟内完成一个新功能的PRD，评审点在“深度”。第三轮（30分钟）是数据分析，提供一段业务指标的Excel，要求在10分钟内找出异常并给出改进方案，评审点在“影响力”。第四轮（30分钟）是文化适配，评审官会验证你的价值观是否与Amazon的长期目标一致。每轮都有对应的时间节点与评分标准，务必在准备阶段对号入座。
以上裁决基于多年内部晋升案例，遵循Amazon最核心的评审逻辑。正确的判断是：用结构化、可量化、时间标记的叙事取代空洞的自夸，才能在Forte自评中脱颖而出。
准备好系统化备战PM面试了吗？
也可在 Gumroad 获取完整手册。