你的平台工程团队需要产品管理，但这并不意味着它需要一个产品经理。
译自 Is Your Product Manager Hurting Platform Engineering?，作者 Steve Fenton 是 Octopus Deploy 的八爪鱼员工，是 DORA 社区的指南，也是一位有二十多年软件交付经验的六次 Microsoft MVP。他撰写了关于 TypeScript（Apress，InfoQ）、Octopus Deploy 和 Web 运营的书籍...
几乎所有的平台工程师都同意，你应该把平台看作是一个产品，把开发者视为客户。优秀的平台将是那些能够优雅地解决现实世界问题的平台，而不仅仅是满足平台工程师的需求。
随着这一认识的共识，普遍的建议是应该设立一个产品经理。然而，在云原生计算基金会（CNCF）社区的最近一次讨论中，对于平台团队的产品管理，挑战了这种千篇一律的指导。
当人们说你需要一个产品经理时，他们指的是你的团队必须具备一定的技能，必须完成产品管理任务。例如，你需要让平台专注于其用户，并能够评估功能是否带来了预期的好处。你需要将平台引入组织中的团队，并向他们展示它如何帮助他们。
你不需要一个产品经理来实现产品的关注；在某些情况下，添加一个产品经理可能是适得其反的。
创业公司通常是由一小群对解决特定问题深感兴趣的人组成的。许多技术创业公司是在开发人员发现某个令人沮丧的问题并开发工具来解决这个问题时创建的。
当这些开发人员能够将他们特定的第一手经验推广到与形状相似的其他人有着独特问题的人群中时，一个优秀的产品就会诞生。他们不仅仅解决自己的具体用例；他们可以解决整个一类用例。
这些工程师具有产品思维。他们能够结合直接的从业者知识和他人的信息，找到创新的方式来改进许多人的工作。
这就是 Octopus Deploy 的诞生方式。2010年，Paul Stovell 感到很沮丧，因为在许多其他软件交付任务已经实现自动化的情况下，部署仍然如此痛苦。为什么构建和测试自动化是一个解决的问题，而部署却是一团糟呢？
将个人的沮丧转化为商业成功的关键是产品思维。
Paul说：“客户的反馈就像氧气一样。它为产品开发过程中的创新提供动力。你发布一些东西，听取反馈，然后发布其他东西，因为你已经建立了对用户未满足需求的更深刻理解。如果让开发人员与这个至关重要的反馈之间有所阻碍，就会扼杀创新。”
从第一天开始就有一个产品经理可能会降低你的平台团队的氧气水平。反馈可能会被过滤、延迟或误解，大大降低其价值，使良好的结果变得不太可能。
平台工程师应该沉浸在反馈的充分、精确的细节中，并利用它来丰富对客户试图完成的任务的理解 — 以及在完成这些任务时客户服务不足的地方。这有助于平台团队创建创新解决方案，可能解决多个未满足的需求。
在这里，你不必使用“需要完成的工作”（Jobs To Be Done，JTBD）框架。关键细节在于，通过沉浸自己在客户需求中，你可以提出解决许多痛点的想法，而不是陷入解决问题之后的特性工厂陷阱。
你需要理解广泛的问题集，以制定一个适当抽象的解决方案。
这是推迟甚至避免添加产品经理的一个引人注目的理由。
虽然很容易想象当你的平台达到全面采用、被分拆为子公司组织并以其命名的会议时会发生什么，但值得理解的是规模并不是你添加产品经理的原因。
平台团队的目标应该是在规模上解决有价值的问题，同时以次线性的方式扩展自己。这意味着让更多的开发人员对采用黄金路径感兴趣，而不是试图为每种可想象的情况创建路径。
当团队基于想要你的平台提供的支持而做出选择时，你就可以在不必包含新技术堆栈的情况下进行扩展。这比通过支持神秘的团队选择来获得进一步采用更可取。
如果客户团队扩展，你的平台团队不应该受到影响。
在整个行业中存在一个问题，即软件管理者认为他们的工作是阻止程序员分心，以便他们能够花更多时间敲代码。结果，越来越多的软件开发人员从未与用户或客户交流。这导致了脱节的路线图，对正在开发的产品没有增值。
如果你需要扩展你的平台团队，保持平台工程师与平台用户之间的直接沟通至关重要。你可能会发现，重新组织成基于路径的团队可以帮助你在不失去与客户联系的情况下实现增长。
当一个软件团队变得繁忙时，非编码任务逐渐消失。结果可能是误导性的生产力倡议，也可能只是对不同活动的不同庆祝。例如，当团队完成一个功能时，会有蛋糕；但当有人从客户那里获得有价值的见解时，却是沉默。
当团队陷入“提交近视”时，他们开始制作没有人想要的功能。当组织庆祝增加功能的速度时，即使这些功能没有价值，问题就会变得更为严重。个体贡献者对组织重视的工作类型非常敏感，并将进行相应的优化。
对于平台团队来说，非编码贡献必须像新功能一样受到高度赞扬。
如果问题是工作没有得到重视，产品经理就像一块创可贴。
2023年《加速 DevOps 现状报告》确认，以用户为中心的团队胜过以功能驱动的团队。这是直接融入你的平台工程工具集的基石。能够与内部开发者平台的用户保持高带宽反馈的团队将花更多时间致力于有价值的功能。
在某些情况下，添加一个产品经理是正确的选择，但有时这会削弱团队的力量并破坏成果。
产品管理是必需的。但并不总是需要一个产品经理。