产品与工程协作：缺乏信任和协作如何拖慢产品增长

对于任何一家成功的初创公司来说，产品团队与工程团队之间的紧密协作都是关键。良好的产品与工程协作，能够提升研发效能、缩短产品价值交付周期，并帮助企业更快实现产品增长。这听起来并不复杂，但真正做到却异常困难。

这两个团队的目标可能并不完全一致，对“成功”的定义也可能不同，而这些差异都需要被协调。工程团队可能希望打造一款未来可扩展性极强、开发者体验极佳的产品；产品团队则可能更关注快速验证想法，并尽快推出能够吸引客户付费的功能。

另一个常见问题是，工程团队制定了一份“工程路线图”，产品团队制定了一份“产品路线图”，两者彼此独立。这会让产品和工程团队都感到困惑，也会削弱组织的协同效率。

这两种截然不同的思维方式，容易让组织内部的两个部门产生冲突。最简单的做法是回避那些艰难的对话：各自为政，偶尔聚在一起发布产品。但我们认为，只有将这两个原本分散的部门整合为紧密协作的团队，才能真正消除组织内部的摩擦，并缩短产品价值实现的时间。

产品与工程团队是如何陷入协作瓶颈的？

在创业初期，团队协作往往自然而然。那时团队规模不大，成员之间合作紧密，产品负责人和技术负责人很可能在公司成立前就已经建立了深厚的私人关系。最初的创业想法也相对清晰，随着业务快速发展，下一步应该做什么，对所有人来说似乎都显而易见。

然而，随着公司不断壮大，基于技能的职能分工开始出现，管理层级也逐渐增加。这些管理者并不总是会把与同事建立高效合作关系作为优先事项。相反，他们往往会被一些更紧迫的任务牵引，例如维护应用程序的正常运行，或者为下一轮融资做准备。

与此同时，初创公司会来到一个关键转折点：公司需要决定如何以最佳方式投资产品，并制定一套更完整的投资策略。

运作良好的初创公司，通常已经开始采用跨职能产品团队模式。某些职能天然更容易协作，因为它们往往隶属于同一条垂直链路。例如，开发和测试在初创公司中通常整合得较好，而在传统企业 IT 部门中却经常各自为政。

但是，在许多快速成长型公司中，我们常常发现产品团队和技术团队的职责划分相当分散。这种情况之所以会出现，是因为员工在以活动为导向的组织中，更容易关注自身职能，而不是关注以结果为导向的团队目标。

而且，这种割裂会出现在各个层级：产品经理与技术负责人、工程经理之间的职责不一致；总监与总监之间的职责不一致；副总裁与副总裁之间的职责不一致；首席技术负责人和首席产品负责人之间的职责也可能不一致。

最终，这种瓶颈会通过组织绩效下降表现出来，因为它阻碍了客户价值和业务价值的创造。初创公司会发现，这种瓶颈通常表现为组织内部的紧张关系、突发事件增多、技术债务长期得不到解决，以及开发速度持续下降。

幸运的是，我们可以通过一些关键信号，识别产品团队与工程团队之间是否已经出现摩擦。本文将描述这些信号，并提供一些解决方案，帮助组织降低沟通障碍，构建更均衡的投资组合，最大化投资回报，并尽可能降低长期风险。

对于正在经历产品与工程协作摩擦的团队来说，仅靠会议和口头沟通往往不够，还需要让目标、客户反馈、需求清理、评审排期、开发、测试、发布和知识沉淀形成连续流程。PingCode 这类智能化研发管理工具，可以帮助企业把研发管理过程自动化、数据化、智能化，让产品与工程团队围绕同一套事实和数据协同推进工作。

产品与工程协作出现问题的常见信号

各部门互相指责

当团队成员把自己的管理结构或职能领导视为主要身份认同时，而不是把业务价值流或客户价值流视为主要身份认同时，团队之间就更容易形成“我们”和“他们”的对立姿态。

在最糟糕的情况下，这种“我们与他们”的对立会变得非常有害，双方彼此缺乏尊重。我们见过这样的情况：产品负责人随意下达需求，把工程团队当作功能工厂；当项目未能达到预期目标时，又突然取消项目，而在此之前并没有任何迹象表明项目无法达到 KPI。

反过来，工程团队也可能不断让产品团队失望，无法按时交付，而且事先没有任何预警。最终，双方都会失去对彼此的信任。

工程师常因缺乏产品背景而陷入困境

当产品经理未经工程师充分参与，就把功能和需求交给工程师时，关键的业务背景和客户背景往往会丢失。这种情况在需求被简单塞进项目管理工具后尤其常见。

如果工程师在缺乏背景信息的情况下工作，那么当他们需要做出设计或开发决策时，就不得不停下来寻找产品经理确认，而无法独立做出明智判断。

更糟糕的是，他们可能会基于错误理解直接做出决策，并按照偏离产品愿景的方式构建软件。结果可能是项目延期，也可能是最终交付的软件无法真正满足需求。这类摩擦会扰乱交付流程，并在价值流中制造不必要的浪费。

依赖项被遗漏

当工程师和架构师在缺乏充分背景信息的情况下工作时，变更带来的完整影响可能会被忽略或误解。缺少背景信息时，需求或用户故事就会显得单薄而片面。

客户画像可能会被忽略，业务规则可能被遗漏，技术集成点或跨职能需求也可能没有被充分识别。这往往会导致临时变更频繁出现，或对业务和客户体验造成意想不到的干扰。

工作被遗漏

任务被遗漏，团队成员认为某项活动应该由其他人负责；团队成员因为觉得别人侵犯了自己的职责边界而互相推诿；更糟糕的是，有人直接说“这不是我的工作”。

这些都是角色和职责不清、沟通与协作不足，以及组织摩擦加剧的信号。

技术债务谈判破裂

技术债务是现代软件开发中的常见副产品，其来源复杂，我们此前已经讨论过。当产品团队和工程团队在产品规划阶段缺乏有效沟通与协作时，资源配置往往会失衡。

这意味着产品待办列表可能会过度偏向新功能开发，而对技术债务偿还投入不足。

例如：

事故发生频率更高，生产支持成本持续上升。

开发人员为了在各种障碍中快速交付功能而精疲力竭。

功能列表越来越长，但许多功能质量不高，导致客户很快放弃使用。

团队之间有沟通，但没有协作

定期开会讨论工作的团队，是在沟通；积极共同工作，并公开寻求和提供意见的团队，才是在协作。

定期召开进度会议，让团队成员汇报各自部分的进展，并不意味着团队就具备协作能力。协作发生在团队成员主动尝试相互理解，并在工作过程中公开寻求和提供意见之时。

如何突破产品与工程协作瓶颈？

打破产品和工程之间的壁垒，是打造高效产品团队的关键。跨职能团队必须能够有效沟通和协作，并能够围绕如何最佳实现目标展开协商。

许多快速成长型企业在应对这一瓶颈时，都可以从以下策略中获益。

确定并加强你的“第一团队”

从最基本的层面来看，产品团队是一群围绕共同目标协同行动的人。这个共同目标，就是创造业务价值和客户价值。每个团队都会以自己独特的方式，或在自己独特的范围内，为价值创造做出贡献。

作为领导者，重要的是识别并强化围绕价值创造形成的团队动力，而不是强化组织汇报结构。这种跨职能产品团队，应该成为团队成员的“第一团队”。

如果领导者把团队定义为自己的直接下属，那么实际上是在助长一种部落意识，进而加剧“我们与他们”的对立局面。

“第一团队”思维模式由海外某位组织管理学者提出，并在多本管理著作中被提及。虽然这一概念通常用于强调跨职能领导团队应当成为管理者的主要责任团队，而不是各自的组织汇报线，但同样的理念也适用于产品团队。

仅仅改变组织语言，而不改变实际行为，并不会真正解决规模化难题。不过，语言改变可以成为一个简单的起点，用来缓解组织内部摩擦，并触及导致绩效问题的深层文化因素。

改变语言，减少产品与工程对立

一个组织越愿意主动打破部门壁垒，就越有可能有效消除那些促成壁垒形成的隐性对立状态。

采取切实行动，规范组织内部使用的语言，是打破障碍、减少摩擦的第一步。

可以尝试不用“团队”这个词来称呼组织中的从业者群体，而改用“小队”“小组”或任何符合组织文化的术语。这个改变看似很小，却可能产生明显影响。

为跨职能产品交付团队命名时，最好使用其产品名称或价值流名称。这也是一个简单但有效的改变，可以帮助这些跨学科成员形成不同于组织汇报结构的新团队身份。

请从专业语境中剔除“我们”和“他们”。试图用其他说法指代“那边那群人，而不是我们这群人”，其实只是换了一种方式延续对立。在专业环境中，我们常常会主动约束并调整自己的表达，而这类说法应当被列入“禁用清单”。

改变行为，建立协作文化

那些希望改变组织文化的人，需要清楚说明自己想做什么、希望采取什么行为方式，以及团队成员之间应该如何互动。随后，组织需要提供培训，并采取必要措施强化这些行为。文化会在这些行为持续发生后自然改变。

当组织无法取得预期成果时，改变文化并不容易。关于这一主题，已经有许多书籍进行过讨论。通过提前定义并传达团队及其成员的预期行为，领导者可以为希望建立的文化奠定基调。

领导者应树立不追责的文化原则和行为预期。当问题出现时，它应被视为一个绝佳的学习机会，值得深入研究，并用于持续改进。不追责复盘正是这种理念的体现。

组织应设定行为预期，并定期检查这些行为是否真正发生。团队成员需要对这些行为负责，组织也不应容忍例外情况。

团队构建应围绕价值流展开，而不是围绕职能展开。要区分真正共同交付价值的“团队”，以及“实践社区”或“卓越中心”这类组织。后者通常是为了深化或交付某项特定能力而建立，例如产品管理能力或质量保障能力。

同时也要认识到，某些性格类型之间的兼容性不如其他类型。组织需要灵活调配优秀人才，寻找最佳的团队协同效果。

明确并阐述企业如何创造价值

从许多方面来看，公司就像一个拥有共同目标的大型团队，而这个共同目标就是组织的成功。如果产品团队和工程团队对这个目标缺乏共识，就很难就如何实现目标达成真正协作。

为了避免这种摩擦，高管必须清晰地阐述并传播组织为客户、投资者和社会提供的整体价值。领导者有责任说明产品组合中的每一项产品和服务，如何为实现这一价值做出贡献。管理层还必须确保每位团队成员都明白，自己日复一日的工作是如何为组织及其客户创造价值的。

目标是建立一套关于企业如何创造价值的共同思维模式。实现这一目标的最佳方法，很大程度上取决于企业自身特点。我们发现，有几类资产在成长型企业中既常见又有用。

描述客户和用户价值的资产

这些内容应描述产品和服务创造的价值、目标客户，以及衡量该价值的方法。例如：

商业模式画布或精益画布。

用户旅程。

服务蓝图。

用户画像。

同理心地图。

故事板。

待完成任务图。

产品概述，例如单页简介。

描述经济模型的资产

这些内容应描述公司从客户那里获得的价值、创造该价值的成本，以及衡量该价值的方法。例如：

商业飞轮。

价值流图。

战略地图。

留存和流失模型。

客户获取模型。

客户生命周期价值模型。

预计资产负债表和损益表。

描述战略的资产

这些内容应描述你为什么选择以这种方式服务这些客户，做出这一决策所依据的证据，以及你可以通过哪些方式最有效地增加所创造和获得的价值。例如：

目标客户画像。

问题树。

影响地图。

机会—解决方案树。

层级图。

因果循环图。

其他定制框架和模型。

一旦拥有这些资产，就必须在演示、会议、决策，以及最重要的冲突解决过程中持续引用它们。当你更新这些资产时，务必沟通变更内容，并解释变更原因。同时，也要及时向组织征求反馈。简单来说，要让这些资产成为日常工作的一部分，而不是让它们沦为背景板或办公室里的装饰品。

我们发现，一个简单的启发式方法可以帮助判断沟通是否有效：随机挑选一位员工，让他回答这些资料中提出的问题。如果他能在不参考资料的情况下回答得越好，就说明他越能将这种思维方式融入日常工作。如果他甚至不知道这些资料的存在，那就说明组织还有大量工作要做。

这些资产带来的协调和聚焦，可以帮助组织更好地部署资源，从而支持规模化发展。此外，它们还能化解产品和工程之间固有的紧张关系。与其让无益的人际摩擦持续存在，不如借助创建和更新这些资产的机会展开真正协作，并围绕那些能够增强公司实力的想法进行建设性讨论。

组建跨学科、目标一致的产品团队

公司初创阶段通常只有一条价值流。但随着公司发展壮大，就需要将产品和服务拆分成多条价值流，让不同团队能够全面负责不同的产品或产品组件。

本文不展开讨论最佳拆分方法，但以下几个问题值得考虑：

这条价值流及其包含的产品和服务，能否像一家独立公司一样运转，即使它未必会非常成功？

你能否将这条价值流与公司创造价值的特定方式，或公司服务的特定客户和用户保持一致？

不同价值流之间会如何相互作用？

在定义好价值流之后，就应该将跨学科团队成员聚集在一起，因为价值创造本质上是一项团队合作。

可以请各价值流负责人创建类似前文所讨论资产的更详细版本，然后确定在这条价值流中，从始至终交付和提升产品或服务价值，通常需要哪些技能和能力。

接下来，应将这些人员整合到一个以结果为导向的团队中，而不是让他们在以活动为导向或职能为导向的团队之间反复协调工作。有海外某位组织设计研究者指出：“流程和间接性越多，有效协作的阻力就越大。相比之下，团队成员无需安排正式会议即可相互协作。他们可以持续协作，并根据需要进行简短的临时讨论，无论是线上还是线下。”

这种模式不仅有助于减少以结果为导向的团队内部延迟，也能减少跨学科成员之间的摩擦。

请记住，随着公司发展，你可能需要组建“团队的团队”。也就是说，多个团队围绕同一价值流协同运作，并由一个跨职能领导团队负责这条价值流。随着价值创造复杂度增加，保持产品交付团队目标一致的重要性也会越来越高。

产品经理和软件工程师共同承担着理解客户需求的责任，以便定义工作内容并确定优先级。产品经理和工程师之间并不存在一个放之四海而皆准的理想比例，每个产品都需要根据自身情况调整。重要的是，双方都要理解自己共同承担着理解客户需求、确定优先级并创造价值的责任。

随着产品不断迭代，团队需求也会随之变化。组织应定期盘点团队能力，并赋予各分支团队足够自主权，让它们能够提出自身需求。确保团队拥有充足的人员、技能、信息和权限，从而高效交付，并避免不必要的外部资源依赖。

资源充足且被充分授权的产品团队，会作为一个整体运作，而不受个人汇报结构的限制。这将显著减少跨部门摩擦。

在各个层级建立团队工作协议

确保每位团队成员都清楚自己扮演的角色。

优秀团队往往已经协商出最适合自身的工作方式。对于组织而言，建立合理的默认机制非常重要，因为它可以指导经验不足的团队如何高效协作。

即便有了默认机制，团队仍然需要拥有自主权，自行决定每位成员的职责。这种自主权可以增强责任感，并提升内在动力。

新团队组建时，应将工作协议写入团队的通用知识库。在回顾会议中，随着团队成员对彼此优势和短板的了解不断加深，应重新审视这份工作协议，并据此调整职责分配。

这份工作协议既是团队的社会契约，也是其他团队无法复制的独特“责任指纹”。当新成员加入或团队成员轮岗时，一份可参考的工作协议能够加速新成员融入团队，缩短其入职后的价值实现时间。

对于跨部门协作较多的团队来说，工作协议不仅需要被写下来，还需要和日常任务、项目、文档、日历、工时、审批等协同场景连接起来。Worktile 这类通用项目协作系统，可以帮助团队把这些基础协作流程统一管理，减少信息分散带来的沟通成本。

团队工作协议通常包括以下内容：

团队名称：团队的唯一标识是什么？

团队使命：这个团队存在的意义是什么？它预期创造什么价值？

团队指标：团队将如何衡量成功？其中应包括价值创造指标，而不仅仅是活动指标。

团队职责：为了确保成功，需要完成哪些工作？哪些团队成员同意负责这些工作？组织可以提供典型活动和职责分配建议，但团队成员应可以自由协商。

团队技能：为了确保成功，这个团队需要哪些技能？

团队规范：团队成员应遵循哪些指导方针、原则、仪式和默认规则，以统一行为、互动和决策方式？

领导者也应建立自己的团队工作协议。对于跨职能团队来说，这是一个有用工具；对于协调跨职能领导者来说，它同样非常重要。

产品负责人、设计负责人和技术负责人这三类拥有全局视角的领导者，单独来看都很有价值，但当他们结合在一起时，真正的力量才会显现出来。

从宏观层面来看，高管团队有责任在公司战略、产品战略以及相应的成功衡量标准上达成一致。如果高管们无法就“理想的跨产品投资组合”等关键问题达成共识，那么负责实现这些目标的团队也很难取得成功。

在数字化产品组织中，职能部门经理可能不再直接负责产品线团队的日常工作，这项职责更多由团队及其产品经理承担。但职能负责人仍然至关重要。他们的职责是确保团队拥有足够的人才和技能储备。

为了避免产品团队内部出现冲突，这些直接主管必须就产品团队成员的角色和职责达成一致。团队成员也必须将团队成果置于个人或部门需求之上。

协商制定均衡的产品投资组合

均衡的产品投资组合，关键在于找到技术投资与产品投资之间的最佳平衡点。

如果产品功能积压过多，过度投资于功能可能意味着技术债务和发展空间投入不足，最终导致解决方案设计不足。反过来，如果技术待办事项过多，过度投资于技术则可能意味着客户真正重视的功能投入不足，最终导致解决方案设计过度。

很难准确判断何时才是最佳平衡点。随着公司发展和转型，这个平衡点很可能会不断变化。

我们经常见到的一种设计不足案例，是产品可用性问题。这意味着开发团队不得不花费大量时间处理突发状况，从而分散注意力并影响生产力。当公司规模较小时，这种情况或许还能勉强维持；但如果客户使用量激增，团队就会不堪重负，客户体验也会受到影响。而这种“债务”的偿还，往往会在公司最无力承担的时候到来。

如果技术团队过早进行过多优化，则可能造成另一种失衡，即过度设计。例如，当公司只有十个用户时，却设计出能够支持数十万用户的复杂架构。当初创公司转型时，很多此前投入的成果最终可能都会被废弃。因此，组织始终需要在“构建未来可扩展的产品”和“构建满足当前生存需求的产品”之间找到平衡。

重要的是，团队要能够发现投资组合何时失衡，并及时纠正。持续改进至关重要。如果团队，无论是产品团队还是管理团队，都清楚自己的共同目标，那么跨职能小组就可以定期评估这种平衡状态，并以数据作为指导。

有些数据可以量化，有些则更偏主观。可以参考以下信息：

收集个人意见：工程师是否觉得自己高效且有动力？产品经理是否认为团队高效？

生产力指标：我们测试和构建新功能的速度有多快？

当前状态和近期未来状态的展望：我们是否为了未来可扩展性，让当前构建过程变得过于复杂？

产品增长：我们是否了解产品目标的进展？是否有足够的分析、用户测试和客户反馈，证明我们的产品投资正在获得回报？

趋势：随着功能增多或用户增加，各项指标的趋势如何？例如，可以关注构建时间、部署到生产环境的前置时间，以及事件数量等指标。随着复杂度上升，技术投入应该能够有效控制这些指标，并减轻开发人员的工作负担。

一位经验丰富的技术专家，尤其是具备技术平台扩展经验的专家，价值极高。他们能够解读数据，凭借直觉发现潜在的未来问题，同时又能保持务实。

考虑跨职能需求，避免只关注新功能

好的产品并不只是拥有最新功能的产品，它必须具备以下几点特性：

1.良好的性能、可靠性和稳定性。

2.具有成本效益，产品运营成本不应超过产品产生的收入。

3.它的底层架构应能支持未来功能快速、高效地开发。

4.它应该考虑客户群扩展，并能够在不进行大量返工的情况下完成扩展。

5.它不应让个人客户数据或企业数据暴露在风险之中。

产品的这些特性，以及其他许多特性，都属于跨职能需求。为了尽快推出新功能而忽视这些需求，会导致一系列问题。

有些问题显而易见，因为你可以直接观察到它们。当客户开始投诉时，这些问题就会暴露出来。而另一些问题则需要长期观察才能显现。

有海外某位技术专家曾强调，保持内部高质量非常重要，包括重构代码、创建自动化测试以及实现架构解耦。初创公司往往会为了短期生产力而忽略这些工作。这在某些阶段或许是正确决策，但一旦公司开始扩充团队，就必须重视内部质量，否则长期价值创造能力会受到损害。

平衡产品待办列表

构建平衡的产品待办列表，始于信任。因为这本质上是产品团队和工程团队之间的一场协商。我们建议每位产品负责人都努力与技术团队建立紧密合作关系，反之亦然。在寻求平衡的过程中，必然会出现许多艰难讨论，而且这些讨论本就应该发生。初创公司的资源非常有限，经常需要在改善开发者体验和开发新功能之间做出艰难取舍。

高效协商依赖于透明度、分享详细信息的能力，以及从对方角度看待问题的意愿。如果产品经理理解技术架构和技术策略，就能提出更容易实现的方案。如果技术人员理解产品策略背后的逻辑和研究，就能提出产品经理可能没有想到的替代方案，例如使用机器学习或人工智能来解决某些问题。

在协商待办事项时，初创公司往往难以理解不同潜在投资的相对影响。由于使用率和收入指标容易获取，也更广为人知，那些会影响这些指标的工作往往会被优先考虑，从而导致投资组合失衡。

为了解决这个问题，我们建议寻找能够衡量技术投资影响的指标。每种情况都不尽相同，但有一些经过研究验证、能够提升长期生产力的事实标准，可以作为起点。关注 DevOps 和开发者体验相关的结果导向指标，是一个不错的方向。某些规模化实践团队会为成长型企业设置一组合理的默认实践，这些实践来自对成功企业所采用技术和方法的研究。其中包括持续交付、面向领域的微服务、谨慎处理技术债务，以及构建实验流程和基础设施。

此外，组织还应设定不容妥协的质量标准，并坚持执行。例如，每种编程语言都有一套最佳实践，团队可以相对容易地通过自动化检查，确认工作是否符合这些实践。

随着企业成长，产品与工程的协作方式也会变化

第一阶段：实验

在这个阶段，创业公司本身就是一个团队。

团队会建立初步的工作协议和相关资产，用来描述使命宣言。

投资组合会严重偏向产品投资。

团队通常更关注提升认知，而不是开发长期可用的产品，例如一次性原型。

团队会围绕不同经济模型展开实验。

第二阶段：取得进展

公司开始拆分成多个子团队，但仍然把自己视为一个“大团队”。

工作协议变得更加具体。

客户价值相关资产经过提炼，并开始应用于客户导入和入职培训。

经济模型变得更加清晰，但仍然保持灵活性。

公司开始聘请首批非创始人出身的产品和工程领导者。

投资组合仍然以产品为导向，但开始专注于打造更持久的产品。这是支持规模化发展的关键基础投资。

第三阶段：高速增长

公司规模已经太大，无法再作为一个“大团队”运作，因此需要拆分为多个围绕流程协作的团队。

组织开始为中层管理者组建跨职能领导团队。首批平台工程团队也可能在这一阶段成立。

公司不再主要寻找新市场，而是加倍提升现有产品所创造的价值。

客户价值、商业战略和经济模型相关资产已经相当具体，变化速度变慢，并且被设计为可以在组织内广泛传播。

每个产品和子产品都会根据需要，创建自己的价值声明和相关资产。

第四阶段：优化

领导者必须主动打破按职能划分的部门壁垒。

团队结构开始发生变化，以最大限度提升自主性和能动性。

支持技能发展以及各职能之间保持一致性的机制开始形成。

组织会创建多个团队，以提升价值流团队的工作效率，例如平台工程、产品运营、设计运营等团队。

核心产品的投资组合会更加重视技术投资，包括对开发者体验的投资。

总结：产品与工程协作决定产品增长效率

职能型组织结构让公司管理更加便捷。围绕共同技能和能力组建团队，并由职能负责人负责技能培养和职业发展，是任何快速成长型企业的重要基础。

但是，当团队成员开始认同并效忠于各自职能部门时，就可能滋生部落主义，导致团队之间出现摩擦。

当两个团队都向同一位经理或高管汇报时，消除团队间隔阂会相对容易。因此，在许多组织中，产品团队和工程团队之间的隔阂往往是最后才被消除的。

打造统一的产品团队，对于创建积极主动、能够高效交付业务价值和客户价值的团队至关重要。以下是预防或解决产品与工程之间摩擦的几项关键策略：

加强“第一团队”：职能型组织有利于培养技能娴熟的员工，但无论角色如何，所有共同交付同一业务价值或客户价值的人，都应被视为同一个团队的成员。

明确并传达价值主张：确保产品团队中的每一位成员都清楚，自己如何为企业及其客户创造价值。这是打造主动进取团队的关键。

组建跨学科、流程一致的团队：建立具备创造和交付可衡量价值所需全部技能与能力的端到端产品团队，并确保他们始终拥有充足资源。

在各个层级建立团队工作协议：在轻量级治理框架内，允许产品团队和职能负责人自行协商并明确角色和职责。持续评估和调整，直到团队达到相对平衡和稳定的状态。

协商均衡的产品投资组合：成功的产品团队不仅要交付功能丰富的产品，还要交付稳定、安全、可扩展，并具备长期演进能力的产品。

归根结底，产品增长并不只取决于产品创意或工程能力本身，更取决于产品与工程能否围绕共同目标持续协作。当产品团队和工程团队能够共享背景、共同决策、平衡功能交付与技术投入时，组织才能更稳定地提升研发效能，并持续创造客户价值。