近年来，产品经理这一角色在科技行业中越来越受欢迎。随着越来越多的公司在其组织架构中增加PM，团队配置方面仍在进行大量实验，以找到产品和工程之间最佳的协调方式。这两个职能现在比以往任何时候都更紧密地合作，虽然这被认为是高绩效团队的秘诀，但许多公司仍在努力实现良好的协作水平。
使其运作的策略在Martin Fowler的网站上有很好的介绍。在本文中，我将更多地关注工程师的视角，以及我们对优秀产品经理的期望。
不应该期望什么#
作为一名工程师，我观察到摩擦来自双方，但也有一些富有成效的合作。虽然可以说团队或组织可以影响结果，但主要取决于每个职能愿意与另一方合作的程度。
让我们做一个练习，反向思考这些期望。我认为PM角色仍处于早期阶段，因此它呈现出不同的形式，尤其是在正在开始构建产品开发策略的不太成熟的公司中。
Excel经理#
宏命令高手，在每周指导会议上汇报进度的大师。整个项目看起来像一件几何艺术品，条形图一层层堆叠。Excel经理很少关心产品生命周期，会把所有筹码都押在让开发人员承诺那些截止日期上。
功能主义者#
360度市场研究的顶级专家。她了解史蒂夫·乔布斯和iPod的一切故事，关心产品生命周期，但不能浪费时间制定策略，因为"细节很重要，值得等待把它做好"。
退休程序员#
对永远做码农的想法感到不满，她放弃了工程，寻求幸福和成功。带着遗憾回顾她留下的生活，退休程序员是一个好盟友，愿意管理领导层的期望。
国王之手#
当我们都在为更大的目标服务时，为什么要分享自己的想法？像一个全通滤波器，国王之手不冒任何被指责的风险。她只是信使。
产品管理的核心理念#
上述刻板印象（有意地）有一个共同点，就是它们都将业务决策委托给领导层，我认为这是产品经理角色最大的改变者。PM不仅仅负责设计或实施，还要对整个产品生命周期负责，从创意到实施、客户反馈和市场表现。
我参与过的最成功的团队是那些PM在场的团队，有时甚至在同一领导/汇报线下。PM & EM: Rules of engagement建立了3条基本规则：信任、共同责任和独立所有权。
让团队了解业务#
一直困扰我的事情之一是工程师对他们正在构建的产品知之甚少。无论是否令人惊讶，一个人可能工作一辈子都不知道谁在使用你构建的软件以及它赚了多少钱。与团队定期讨论产品的表现是促进创新和保持高动力水平的有力方式。
一个路线图统治所有#
在产品团队工作时构建技术路线图是我经历过的最适得其反的经历之一。虽然跟踪需要偿还的技术债务很重要，但如果产品方面不买账，经验告诉我这些任务永远不会被实施。
一个好的PM能够理解不偿还技术债务的成本，并将其纳入产品策略。
目标日期，而非截止日期#
如果你想给工程师压力，问他ETA或让他承诺领导层设定的截止日期。在压力下构建软件只会损害业务，因为它会迫使人们犯更多错误。
虽然工程师随意浪费大量时间也是不可接受的，但PM应该足够灵活，允许目标日期移动或范围缩减。
最终备注#
完美的PM应该是什么样子仍然是一个开放的问题，但很明显，如果产品和工程都致力于建立有效的合作关系，结果可以更加高效。从工程师的角度来看，理想的PM不是利益相关者，而是同伴，很像大公司内小型创业公司的CEO。
