与产品经理合作Working with product managers

工程师与产品管理部门的关系，比与公司任何其他部门的关系都要更加不正常。他们之间没有像与其他工程师之间那样的共同文化或语言，而且“谁有权指挥谁”的规则也不像与经理之间那样界限分明。工程师与法务、设计或销售部门没有太多共同点，但他们也不需要与这些角色进行太多互动。根据我的经验，工程师几乎每天都要与产品经理进行沟通。

反对“产品妈咪”

产品与工程关系中最糟糕的情况大致如下：

工程师在技术上很胜任，但显得过于自我封闭，以至于无法被完全信任。他们需要一个既和蔼又严厉的家长式人物，知道如何与组织中的其他利益相关者沟通（例如，能够自然地说出“利益相关者”这种词），以及如何防止工程师跑偏。

这种令人不适的动态关系被一个流行词“产品妈咪”1精准概括了。我真的非常、非常不喜欢这个词，也不喜欢这整个互动模式。虽然我曾远距离旁观过这种情况，但我与我的产品经理之间的关系几乎完全不是这样。

能否与产品经理良好合作，决定了你在一家公司是成功还是失败。为什么工程和产品部门之间很难维持良好的关系？良好的关系又是什么样的？

为什么建立信任如此困难

产品经理和工程师的技能树基本不重合。产品经理不了解工程师所做的技术工作，也不具备讨论这些工作的能力：如果工程师为某件事给出了技术上的理由，产品经理通常只能耸耸肩说“好吧，我想是这样”。同样，工程师对组织的洞察力也完全无法与产品经理相比。特别是在大型组织中，关于谁需要什么以及哪些功能是重要的，产品经理才是唯一的信息源。当产品经理说某件事至关重要时，工程师通常也只能耸耸肩说“好吧，我想是这样”。

这显然需要极大的信任。不太明显的是，这种信任正在不断被双方打破。每一个产品经理都曾被无数次地告知，某项技术任务在技术上是不可能的，或者会导致灾难性的后果，结果该任务最终却相当顺利且成功地完成了。每一个工程师也都曾被无数次地告知，某项需求绝对至关重要，值得为之付出巨大的努力，结果该需求却被悄无声息地放弃或更改，连句抱歉都没有。

当然，这并不是恶意的。工程师经常给出错误的预估，因为预估本身就是不可能准确的；有时他们警告的可怕后果也确实会发生（只是它们在幕后被解决了，就像工程师处理许多其他类型的技术故障一样）。产品经理“改变主意”，是因为在大型科技公司里，重要的事情确实每一小时都在发生变化2，即使他们尽了最大努力，只把最可靠的优先级过滤传达给工程团队，有时也会出错。

操纵与谎言

这种信任破裂的后果是，双方的关系会变得极难维持。当你作为一名工程师向产品经理解释某件事时，如果你知道他们并不相信你（尽管他们自己根本没有能力去判断这个问题），这会让人感到无比沮丧。同样地，当你作为一名产品经理，拼命试图向工程师解释我们需要做什么时，如果你知道他们内心根本不以为然，这种感觉一定令人难以忍受。难道他们不知道这对公司至关重要吗？你明明刚刚还在和组织的高层开会！

充满不信任的产品经理最惯用的手段就是操纵。我还记得有这样一位产品经理，在我们刚刚解释完可能导致延期风险之后，他试图让团队成员挨个表态“我承诺在两周内完成这项工作”，以此来逼迫团队做出承诺。我猜他的想法是，既然我们发了神圣的誓言，就会更加拼命地工作吧？这种手段还有更微妙的变体，比如暗示如果工作延期你会非常失望（典型的“产品老妈子”做派），或者含糊其辞地暗示如果提前完工可能会获得某种抽象的奖励（而产品经理根本无权兑现）。

充满不信任的工程师最惯用的手段则是撒谎。其中最无害的版本是夸大工作量预估：例如，一条经典的建议就是把你的预估时间翻倍再加20%。我见过有工程师声称他们必须要跟进各种基本是虚构出来的任务（一个常见的例子是“联系相邻团队确认某件事”），只为了能多争取点时间。在最坏的情况下，工程师甚至可能直接撒谎说工作已经完成，然后把“生产环境中无法运行”的反馈当作一个 Bug 来处理。

一旦发生这种情况，双方的关系就几乎无法修复了。我无法让自己去信任一个明显试图把我当提线木偶一样操纵的产品经理，我也确信，产品经理同样无法信任一个曾经当面撒谎的工程师。这就是为什么从一开始就避免陷入糟糕的合作关系至关重要。

不要和产品经理起冲突

何必费这个劲呢？既然与产品经理建立良好的合作关系如此困难，为什么不安于糟糕的现状呢？因为如果不小心应对，产品经理绝对能让你吃不了兜着走。

产品经理在职场上几乎总是比工程师更加老练。这部分是结构性原因：产品经理会参与更多与公司核心决策者的对话，因此自然而然地与他们保持着更好的关系（从而也更善于察觉公司的风向）。另一部分则是选择性偏差：即使工程师的社交能力相对较弱也可能被录用，因为对他们主要评估的是技术能力；但社交技能却是产品经理这个角色的核心要求3。

如果你与产品经理发生冲突，你很可能会输。除非你极具影响力，否则他们绝对有比你多得多的机会在核心圈子里悄悄说你的坏话。只需几句诸如“哦，我可能不会选肖恩来负责那个项目”的闲言碎语，就能毁掉你的声誉。如果你公开与产品经理交恶，公司领导层默认会站在产品经理而不是你这边。他们可能跟产品经理更熟，有更多的共同文化背景，且通常倾向于将这种情况解读为“又一个不懂公司规矩的工程师”。

获得产品经理的信任会带来巨大的好处。产品经理渴望推进产品落地，通常也非常了解所有阻碍交付的非技术性障碍。如果你也同样希望推进产品交付，你们就能成为一支所向披靡的团队。

除此之外，由于工程师和产品经理之间建立信任极其困难，一旦你获得了他们的信任，这种关系就会非常牢固。产品经理通常会挑选一两名工程师作为他们在技术问题上获取“真实情况”的首选对象。如果这个人是你，你在公司里就会拥有举足轻重的影响力，并可以利用这种影响力来推进你想做的事。

如何才能与产品经理建立信任呢？

作为一名工程师，该如何与你的产品经理建立信任？

第一步是理解他们的处境。当他们告诉你某件事很重要，或者收到了新的需求时，你要明白这通常不是他们能决定的。刁难你的不是他们，而是层级更高的人在同时折腾你们俩。如果你能与他们站在统一战线，而不是针锋相对，这就是一个良好的开端。试着直接问：“天哪，好吧，那我们该怎么解决？”，而不是一味地抱怨。

第二步是在绝大多数时候都要保持正确。这听起来像是一句有些滑稽的亚马逊领导力准则，但事实证明它完全准确。我曾在另一篇文章中对此做过详细的探讨，但（尽管听起来不太公平）如果你想与产品经理建立信任，你确实必须在大部分时间里都判断准确。当你说某个功能会如期交付时，它就必须如期交付；当你说某件事不可能做到时，绝不能在几天或几周后被“打脸”。偶尔犯错无伤大雅，但你必须向他们证明，你能够持续稳定地提供有用且准确的技术信息。

第三步是在大多数情况下，把职场策略的决策权交给他们。如果你希望他们信任你的技术决策，那么在处理公司内部人际关系时，你也必须给予他们同等的信任。不要在会议上公开拆他们的台，有意见私下里提。如果他们说某件事很重要，哪怕你心里没底，至少表面上也要予以重视。要接受他们有时也会犯错的事实，就像你在技术问题上偶尔也会犯错一样。

第四步是得靠点运气。有时候，你遇到的产品经理可能就是个庸才。你无法与一个能力不足的人建立信任：你没有什么可以托付给他们的，他们也无法给予你实质性的信任。在大型机构中工作，你必须学会接受这样一个事实：有些同事的能力就是比其他人强；同时，你还要想出应对之策，去和那些不仅不能推进工作反而添乱的人合作（或者想办法绕开他们）。

“技术型”产品经理

许多产品经理曾经是工程师。如果你的产品经理懂技术，这是否意味着你就能对这些问题免疫了呢？绝对不是！

你可能无法选择与哪位产品经理合作，但请务必清楚，曾经做过工程师对他们来说是个减分项，而非加分项。没有任何产品经理能精通技术到产生实质影响的程度，因为他们并不参与代码库的开发：即使他们全职做工程师，也没有时间去建立对系统的特定上下文认知，而这是真正参与技术讨论所必需的。因此，遇到一个清楚自己不懂技术的产品经理，总好过遇到一个误以为自己懂的产品经理。

最糟糕的情况莫过于遇到一位前工程师出身的产品经理，且自认为技术足够敏锐，能察觉出工程师什么时候在骗他们。这种偏执心理是“技术型”产品经理很容易落入的陷阱，尤其是当团队中没有他们可以信赖的工程师可以依靠时。如果你正在和这样的人打交道，请做好心理准备：你要花大量时间去解释为什么有些事情不能“直接”搞定（而且还要做好这些解释不被采信的准备）。

结论

往最坏了想，与产品经理的关系就像身处一个病态的家庭：充斥着居高临下、情感操纵、谎言与不信任。这并不是因为产品经理都是坏人！而是因为这种关系结构本身就会引发冲突。双方都必须做出承诺（关于技术系统或组织目标），而这些承诺往往（a）是错误的，且（b）对方无法独立验证。为了避免陷入这种泥潭，双方必须保持宽容，愿意在对方的专业领域给予信任，而最关键的是，双方都要具备胜任力。

以下是一篇具有相同标签的相关文章的预览。