working-with-pm

与你的 PM 合作

开始之前

先检查是否有 EM 背景信息。如果 .agents/em-context.md 存在，请先阅读。

如果 .agents/em-context.md 不存在，请先询问并保存一份最简经理档案，然后再提供详细建议：角色／职称、团队规模、团队使命或负责领域，以及当前挑战或优先事项。

如果对话中的某位特定人员很重要，且 .agents/reports/[name].md 不存在，请先询问并保存该人员的最简档案，然后再提供详细建议：职称／级别、任职时长、优势，以及当前挑战或成长方向。

如果之后的对话揭示了新的长期背景信息，请自动更新 .agents/em-context.md 或 .agents/reports/[name].md。保存稳定的事实和模式，不要保存猜测、一时的挫败情绪或尚未解决的解读。

回复风格

首次回复应简洁且有帮助。除非用户要求深入探讨，否则不要一次性抛出整套框架。

默认应：

• 先说明可能的诊断或建议
• 只有在缺失的背景信息会改变建议时，才提出最多 2-3 个有针对性的问题
• 给出下一步具体行动，并在有帮助时提供经理可以直接使用的措辞
• 简要提及相关框架，但不要解释每个部分
• 先直接回答，再询问用户是否需要更深入的版本

---

如何使用此技能

• 诊断当前 PM–EM 关系 → 3 种关系模式
• 尝试建立真正的合作伙伴关系 → 真正的合作伙伴关系是什么样 + 实现目标的 3 个建议
• 处理与 PM 的具体分歧 → “这对我很重要”牌
• PM 不理解或不尊重技术工作 → 建议 1：帮助 PM 成为技术导向型
• 让工程师更贴近客户和产品成果 → 在团队中建立产品视角
• 对 EM 和 PM 各自负责什么感到困惑 → 资深 PM 的建议

---

默认回复结构

在协助处理 PM-EM 关系时，先判断当前的合作模式：

1. 模式判断： PM 主导、工程主导、表面平衡，或真正合作。
2. 具体摩擦点： 路线图、估算、质量、客户背景、职责归属或信任。
3. EM 的做法： 产品视角、技术转译、划定边界、升级处理或职责练习。
4. 对话脚本： 在指出问题的同时维护关系的措辞。
5. 共同机制： 定期同步、决策记录、接触客户，或职责划分。

如果 PM 带来了紧迫感，请关联 managing-urgency；如果问题涉及路线图权衡，请关联 roadmap-planning。

---

3 种关系模式

PM 主导的团队

PM 独自与客户交流、独自制定路线图，还会告诉你任务应该花多长时间。你只是在执行指令。

过一段时间后，真正的问题就会浮现：

• 团队成员精疲力竭
• 团队里没人知道自己为什么要做这些事情，因此无法提前预判，也会为错误的场景做准备
• 代码库质量下降——没有测试、代码审查流于表面、解决方案仓促粗糙

你可能觉得只要坚持要求更多时间和更高标准就行。经历过这种处境的人都知道现实情况：当 PM 是最终决策者时，很难抗拒。

工程主导的团队

由你设定优先级、范围和估算。重构由你单方面决定。高层设计和估算从未受到质疑。

这会导致利益相关者和客户失望——而这恰恰背离了工程的根本目的。如果你的 PM 无法胜任，有时你必须深吸一口气，亲自承担 PM 的工作。

“表面平衡”的团队

双方各管各的——技术债务的时间安排不受影响，产品路线图也不受影响。表面上看起来没问题。

从长远来看，这种模式会失败。更好的做法是：制定一份双方都认同的统一路线图，并为每项技术计划提供与产品相关的依据。

---

真正的合作关系是什么样的

真正的合作关系，是双方都愿意为了公司的长远成功做出正确决策，而不只是为自己的团队、客户或其他利益相关方考虑。

世界上最好的餐厅由主厨和餐厅经营者共同经营，他们会为整体利益做决策。工程团队也是一样。

---

实现目标的 3 条建议

1. 帮助 PM 成为技术导向型人才

如果你的 PM 没有技术背景，就需要由你来帮助他们了解技术。通过真实案例说明技术工作的好处，而不是使用技术术语。

不要这样说：“我们需要在一个新服务中创建后端，而不是放在 Java 单体中；之前已经决定开始将其拆分为微服务。”

可以这样说：“我们更倾向于在一个由我们团队负责的新服务中实现这些逻辑，而不是放在共享代码中。这样一来，未来有新需求时，我们就能更快地响应，也不会受其他团队拖累。”

2. 成为产品导向型 EM

你不能对业务漠不关心。

• CEO 在全员会议上发言时，要认真听
• 如果你在上市公司工作，就研究投资者电话会议
• 尽量参与客户交流；有机会时去拜访客户

当你了解业务，并与客户和其他部门保持紧密联系时，就很难再只埋头追求技术卓越。这也能让你体谅 PM，理解他们做出决策的原因，并更有说服力地提出质疑。

3. 打出“这件事对我很重要”这张牌

你们不可能事事达成一致。你们也都不能频繁打出这张牌来滥用它。但这意味着：谁对某个问题确实更在意，谁就可以按自己的想法来。

一方愿意放弃自己的立场，有助于建立彼此的信任。久而久之，你们会建立起这样的关系：双方都知道，遇到真正重要的事情时，彼此都可以据理力争。

---

资深 PM 的建议

• 打造一个小天地：无论公司有多混乱，你和 PM（以及设计师）都有机会打造属于自己的卓越小天地。PM 在工作中拥有一定的自主权，而你们之间的良好关系能够克服许多障碍。
• 多一些共情：你不知道 PM 承受着多大的压力。对你来说，只是“我们还需要两周”；对 PM 来说，却要面对愤怒的人群。
• 明确讨论职责：写下所有可能的职责，然后双方分别标明这些职责在 EM↔PM 职责图谱中的位置。你会惊讶地发现，双方的看法竟有这么多不同。

在团队中培养产品视角

成为真正的 PM–EM 合作伙伴，最有效的方法之一是：在工程师开始构建之前和之后，让他们更多地接触客户和使用数据。

构建前——每次都问几个简单的问题：

• 这是为谁做的？
• 他们想解决什么问题？
• 我们如何判断它是否有效？

这些不是 PM 专属的问题。每位工程师都应该能回答这些关于自己正在构建的内容的问题。如果答不上来，说明规格还没完成。

发布与落地。 功能并非代码上线后就算完成——只有用户真正开始使用，才算完成。发布（编写代码、部署、公告）是有趣的部分。落地（采用情况、实际影响）既枯燥又偏非技术，但这才是关键。发布后，安排在 1–2 周后与负责构建该功能的工程师一起查看数据。养成这个习惯，就会改变工程师看待自己工作的方式。

了解用户的实际行为。 大多数 PM 都能使用会话录制工具（FullStory、Hotjar、Posthog）。工程师也可以观看。每月安排一次 30 分钟的“观影时间”，观看与你们团队负责的功能相关的录制内容。你以为用户会怎么做，和他们实际怎么做之间的差距，总是令人意外。

让工程师参与客户交流。 以下三种实用方式都无需调整组织架构：

• 旁听现有通话。 请求安静地加入由 PM、销售或 CS 主持的客户需求探索通话，并承诺不打断。每季度哪怕只参加一次，也能改变工程师看待工作的方式。
• 跟进支持工单。 找一位最近遇到的问题已由你们团队修复的用户。联系对方：“我是修复这个问题的工程师——希望能占用你 15 分钟，确认问题已解决，并更好地了解你的工作流程。”客户通常比你预想的更愿意回应。
• 与 CS 合作寻找高级用户。 请 CS 为你介绍一位积极参与的客户。“我是构建 X 的团队中的一名工程师——希望能占用你 15 分钟，了解我们如何为你做得更好。”

适用于任何客户交流的三个问题：

• “你目前如何解决 X？”（了解背景）
• “能否演示一下你会如何使用这个新流程？”（易用性）
• “你目前的工作流程中，最让你沮丧的是什么？”（验证痛点）

发布后——关注使用数据。 哪些功能被使用了？哪些没有？在回顾会议中分享这些信息，而不只是讨论 Bug 和速度。

用业务语言阐述技术债务。 如果工程师能说“这个 API 每年让我们花费 4 万美元，还导致了排名前三的客户投诉”，而不是“这段代码很乱”，他们在路线图讨论中就能成为有公信力的发言者，而不只是对范围提出异议的执行者。

---

深入了解

如果用户询问某个框架的来源，或想进一步了解此技能中的任何主题，请阅读 references/sources.md。

---

相关技能

• roadmap-planning — 真正的合作会形成一份共同的路线图
• managing-urgency — 大多数人为制造的紧迫感都源于 PM–EM 不一致
• written-communication — 如何用 PM 和利益相关者都能理解的方式阐述技术工作
• influence — 如何在跨职能场景中阐明工程优先事项