Chinese PM in US: First Performance Review English Translation Tips
一句话总结
Performance Review不是一场关于你做了多少事的汇报会，而是一次关于你在这个组织中“权力定位”的重新定价。正确的翻译不是把中文的勤奋翻译成英文的单词，而是把执行层面的Input翻译成决策层面的Impact。如果你在Self-Review里写的是我完成了什么，那么你被评为Meets Expectations就是必然结果。
适合谁看
这篇文章只写给在硅谷大厂（如Google, Meta, Uber）或快速增长的Tier 1 Startup工作，且正面临入职半年到一年第一次Performance Review的华人PM。特别是那些在技术能力上毫无疑问，但在Self-Review撰写时习惯用中文思维翻译，导致绩效被低估，或者在Review Meeting中无法有效反击Manager负面反馈的产品经理。
如果你还在纠结是用"lead"还是"coordinated"这两个词，这篇文章将告诉你，词汇选择是最低维度的优化，核心是叙事权的夺取。
为什么你的Self-Review在Manager眼里是不可见且低价值的？
大多数华人PM在写Self-Review时，陷入了一个致命的翻译陷阱：他们把Performance Review当成了工作周报的汇总。
在中文语境里，勤奋是通过列举任务清单来证明的，但在硅谷的绩效体系里，这种行为是在向Manager传递一个危险信号——你是一个执行者（Individual Contributor），而不是一个产品领导者（Product Leader）。
一个典型的BAD案例是：I coordinated with 5 engineers and 2 designers to launch the new feature on time, and we reduced the latency by 20%. 这句话在Manager眼里是透明的。因为它描述的是过程，而不是结果。
正确的判断是：绩效评估不是在衡量你的工作量，而是在衡量你对业务目标的贡献度。这里的翻译逻辑应该是：不是描述你做了什么（What I did），而是定义你改变了什么（What I changed）。
在一次具体的Performance Debrief会议中，我曾听到一位VP在评价一名华人PM时说：He is very reliable, but I don't see his leadership. 这句话的潜台词是，这个PM在Self-Review里写了太多关于"coordinate"和"support"的描述，而没有写关于"define"和"drive"的决策过程。
在硅谷，如果你不能证明你通过某种洞察（Insight）改变了产品的方向，那么你的所有加班在绩效考评中都被归零。
正确的叙事结构应该是：不是 A (I did X) $\rightarrow$ B (Result Y)，而是 A (Business Gap) $\rightarrow$ B (Strategic Decision) $\rightarrow$ C (Measurable Impact)。
例如，不要写 "I managed the API integration for the payment module"，而要写 "Identified a critical friction point in the onboarding funnel that led to a 15% drop-off; pivoted the product strategy to prioritize API seamlessness, resulting in a 5% increase in conversion rate, adding $2M in ARR." 这里的区别在于，前者是在请求认可，而后者是在宣示主权。
> 📖 延伸阅读：Meta裁员后解释职业空窗期的面试策略：华人PM必看
为什么你的语言翻译在向上管理中产生了权力不对等？
很多华人PM在Review Meeting中习惯于一种“谦卑的翻译法”。当Manager提出质疑，比如 "I feel you could have handled the stakeholder conflict better" 时，典型的错误反应是 "I'm sorry, I will try my best next time" 或者 "I think there were some misunderstandings"。
这种翻译将一场关于“能力定义”的讨论，翻译成了一场关于“态度问题”的认错会。
在硅谷的权力动态中，谦卑不等于专业，而是意味着你缺乏Confidence。正确的判断是：Review Meeting不是一个接受审判的场合，而是一个同步认知的谈判场。当你面对负面反馈时，你的翻译逻辑应该是：不是承认错误（Admission），而是定义问题（Problem Definition）。
具体场景是：当Manager质疑你的沟通能力时，不要说 "I will improve my communication"，而要说 "I've identified that the current communication gap stems from the lack of a shared success metric between Product and Engineering; I have already established a weekly sync to align on the North Star metric." 这种翻译将一个关于“个人性格”的指责，迅速转化为一个关于“流程优化”的解决方案。
这种翻译的深层逻辑是组织行为学中的“归因理论”。如果你将失败归因于个人能力不足（Internal Attribution），Manager会对你的潜力产生怀疑；如果你将失败归因于系统性缺陷并给出解决方案（External/Systemic Attribution），你就在潜意识中把自己提升到了管理者的维度。
一个能够定义问题的人，比一个能够解决问题的人更有价值。在硅谷，PM的价值不在于写PRD，而在于定义什么是正确的东西。
如何将“勤奋”翻译成“战略影响力”？
在硅谷，最昂贵的错误就是试图用“工作时长”或“交付速度”来换取高绩效。很多华人PM在Review里写 "I worked overtime to ensure the launch"，这在美式职场语境里不仅不能加分，反而可能被视为缺乏时间管理能力或缺乏优先级判断力。
正确的翻译逻辑是：不是展示你的努力（Effort），而是展示你的杠杆率（Leverage）。杠杆率意味着你通过一个决定，带动了多少资源产生了多少价值。一个具有高杠杆率的PM，他的Self-Review里应该出现的是这类词汇：Architected, Spearheaded, Orchestrated, Pivoted, Redefined。
对比两个具体版本：
BAD版本："I wrote 10 PRDs and handled 50 Jira tickets, ensuring the sprint was completed on time." (这是一个助理的写法)
GOOD版本："Architected the roadmap for the Q3 Growth initiative, prioritizing the top 3 high-impact features that contributed to a 10% increase in MAU, while deprecating 2 low-value features to save 4 engineering weeks." (这是一个Leader的写法)
后者的逻辑在于，它向Manager证明了你具备“舍弃”的能力。在产品经理的认知框架中，决定不做什么（Deciding what NOT to do）比决定做什么要难得多，也昂贵得多。
当你写出 "deprecating low-value features" 时，你是在告诉Manager，你不仅在执行，而且在管理资源。这种翻译将你的定位从一个“任务接收机”变成了一个“资源分配者”。
此外，在描述跨部门协作时，不要用 "Worked with" 这种模糊的词。正确的是用 "Aligned stakeholders from Legal, Compliance, and Eng on a high-risk trade-off regarding data privacy, ensuring the launch happened without regulatory delays." 这里的翻译重点在于 "Aligned" 和 "Trade-off"。
在硅谷，处理Trade-off（权衡）是PM最高阶的能力，因为这证明了你在冲突中拥有决策权。
> 📖 延伸阅读：OPT到H1B签证空窗期：Meta中国毕业生应对策略
绩效结果与薪资包的真实逻辑：如何通过Review争取Raise？
很多PM在拿到Performance Review结果后，面对薪资讨论时过于被动。他们认为只要绩效是 "Exceeds Expectations"，薪资自然会涨。这是一个巨大的误区。薪资的涨幅不是基于你的绩效得分，而是基于你的市场价值（Market Value）和你在团队中的不可替代性（Irreplaceability）。
一个典型的硅谷PM薪资结构是：Base (底薪) + RSU (限制性股票) + Bonus (年度奖金)。
例如，一个L5 (Senior PM) 的典型包可能是：Base $180K - $220K, RSU $200K - $400K (4年分批), Bonus 15% - 20%。
当你试图在Review后争取一个Compensation Adjustment时，你的翻译逻辑应该是：不是请求涨薪（Requesting a raise），而是同步价值（Aligning compensation with impact）。
具体对话场景：
错误写法："I had a great performance this year, so I hope I can get a higher bonus." (这在Manager看来是乞求)
正确写法："Based on the impact I delivered—specifically the $5M revenue uplift from the new pricing model—and the current market benchmark for Senior PMs with this level of ownership, I'd like to discuss adjusting my RSU grant to reflect my increased scope of responsibility."
这里的逻辑是：用具体的数字（$5M revenue）作为锚点，用市场基准（Market Benchmark）作为筹码，用责任范围的扩大（Scope of Responsibility）作为理由。你不是在谈钱，而是在谈一个关于“价值对等”的商业交易。
你要明白，Manager在为你申请预算时，他需要的是一套可以向他的上级汇报的“理由清单”。如果你给他的理由是“他很努力”，这个理由在HR和VP那里毫无说服力。但如果你给他的理由是“他一个人承担了原本需要两个PM才能处理的跨团队协调，且带来了具体营收增长”，那么Manager在为你争取钱时，实际上是在向公司证明他自己的管理能力。
准备清单
为了确保你的第一次Performance Review不成为一次职场滑铁卢，请在提交Self-Review前完成以下清单。记住，这是一次关于个人品牌重新定义的写作，而不是填表。
- 建立Impact Matrix：列出过去半年所有交付物，将其分为“执行类”和“影响力类”。删除所有执行类描述，将每一项翻译成：问题 $\rightarrow$ 决策 $\rightarrow$ 结果。
- 词汇库替换：将所有 "helped", "assisted", "worked with" 替换为 "driven", "led", "orchestrated", "aligned"。
- 定义Scope Expansion：写出你在入职之初的Job Description，然后写出你现在实际承担的工作，用对比的方式证明你的Scope已经扩大（例如：从负责一个Feature扩展到负责一个整个Domain）。
- 收集Peer Feedback：提前向3-5个核心协作方（尤其是Eng Lead和Design Lead）请求具体的、带有结果导向的反馈，将这些原话直接引用到Self-Review中，用他人的口吻证明你的Leadership。
- 系统性拆解面试结构（PM面试手册里有完整的Product Strategy实战复盘可以参考），回顾你面试时承诺的价值，在Review中证明你已经兑现了这些承诺，并在某些维度上超出了预期。
- 准备反击剧本：针对可能的负面反馈（如 Communication, Ownership, Vision），预先准备三套“问题 $\rightarrow$ 解决方案 $\rightarrow$ 验证结果”的话术，确保在Meeting中不陷入防御心态。
- 量化所有结果：确保每一个成就后面都跟着一个数字（%, $, Time saved），如果没有直接数字，就用代理指标（Proxy Metrics）或定性的高层认可（Executive recognition）。
常见错误
错误 1：把 Self-Review 写成日记或清单
BAD: "In Q3, I wrote the PRD for the search filter, coordinated with the backend team, tested the bugs, and launched the feature on Oct 15."
GOOD: "Spearheaded the overhaul of the search filtration system, reducing user search time by 30% and increasing click-through rate (CTR) by 12%, directly contributing to a lift in conversion."
裁决：前者在描述流程，属于执行层；后者在描述结果，属于产品层。Manager不需要知道你写了多少PRD，他只需要知道用户体验提升了多少。
错误 2：在面对负面反馈时过度道歉
BAD: "I'm sorry I didn't communicate the delay earlier. I will be more careful next time and make sure it doesn't happen again."
GOOD: "The delay occurred because of a misalignment in the cross-functional dependency mapping. To prevent this, I've implemented a new Dependency Tracker and a bi-weekly sync with the platform team to ensure early detection of risks."
裁决：前者是在承担个人责任（Personal failure），后者是在解决系统问题（Systemic solution）。在硅谷，一个能通过失败建立新流程的PM，比一个从不犯错的PM更有价值。
错误 3：将协作描述为“协助”而非“对齐”
BAD: "I worked with the marketing team to ensure the launch campaign was aligned with the product features."
GOOD: "Aligned the marketing strategy with the product roadmap by defining the core value propositions, ensuring a consistent user journey and resulting in 50k new sign-ups in the first week."
裁决：前者是 "I was there"（我在场），后者是 "I drove the outcome"（我驱动了结果）。"Worked with" 是一个被动的词，而 "Aligned" 是一个拥有权力主导权的词。
FAQ
Q1: 如果我的项目因为外部原因（如公司策略调整、资源被砍）没能上线，在Review里怎么写才不会被判定为绩效不佳？
结论：将“失败的项目”翻译成“风险管理和资源优化”的案例。不要强调项目没上线，而要强调你在项目被砍过程中如何通过快速止损（Cut loss）节省了多少工程资源。
例如，不要写 "The project was cancelled by the VP"，而要写 "Recognized the shift in company priority and proactively pivoted the team's focus to Project B, saving 3 months of redundant engineering effort while ensuring the core objective of X was still met." 这种写法将一个外部失败翻译成了你的战略敏锐度和资源管理能力，证明你能根据公司大方向快速调整，而不是被动地被砍掉。
Q2: Manager在Review Meeting中说我 "Too quiet" 或 "Lack of visibility"，这在硅谷语境下意味着什么？我该如何回应？
结论：这意味着你失去了对个人叙事权的掌控，在组织认知中，你的贡献被归功于他人或被视为理所当然。这不是一个性格问题，而是一个“政治可见度”问题。
回应时，不要说 "I am just shy" 或 "I prefer to focus on work"，而要将其定义为“沟通模式的优化”。你可以说 "I've focused on deep-work and execution in the first half, but I recognize the need for higher visibility. I will start sharing a bi-weekly 'Impact Summary' with the leadership team to ensure strategic alignment." 这样你将一个弱点翻译成了一个可执行的优化计划，同时通过这个计划强行增加了你的Visibility。
Q3: 拿到 Meets Expectations (ME) 之后，如果我认为自己应该拿 Exceeds (EE)，能否在Meeting中挑战Manager？
结论：可以挑战，但不能基于“我觉得我很努力”，而必须基于“证据缺失”。正确的挑战方式是提供一份 "Evidence Gap" 文档。
告诉Manager："I understand the current rating, but I believe there are a few key impacts that weren't fully captured in the review, such as X and Y. If these are accounted for, does it change the evaluation?" 此时，你是在邀请Manager一起重新审视证据，而不是在质疑他的判断。如果Manager依然坚持ME，那么你的目标应该迅速转变为："What are the specific, measurable milestones I need to hit in the next 6 months to move to EE?" 将模糊的评价转化为具体的里程碑，为下一次涨薪地雷区铺路。
准备好系统化备战PM面试了吗？
也可在 Gumroad 获取完整手册。