优秀的产品经理如何促进协作

在致力于面向消费者的功能的科技公司中，产品经理 （PM） 面临着一系列具有挑战性但至关重要的任务：确定产品将解决的业务问题，正确定义产品要求，并在将项目交给工程师构建之前确定最佳设计。在流程的每一步，PM 都必须确保构建的内容同时服务于客户和企业。

在整个过程中，设计师和工程师发挥着至关重要的作用，许多 PM 发现自己在管理这些关键利益相关者时走钢丝。一些观察家将这三组专业人士称为产品三人组——要使这个群体有效，他们需要良好的合作。在本文中，我借鉴了自己作为 PM 的经验，以及与专家和现在担任该角色的其他人的对话，为管理这种关系提供了建议。

重新定义产品团队

与产品团队仅由 PM 组成的常见误解相反，产品团队由多个参与者组成。在她的书《持续发现习惯》中，产品发现教练 Teresa Torres 是这样描述这些角色的：

• 产品经理：使客户需求与业务目标保持一致的战略思考者。
• 设计师：确保产品直观且使用愉悦的用户体验专家。
• 软件工程师：带来可行性和实施见解的技术专家。

虽然这三个核心构成了产品团队的核心，但请务必注意，其组成可能会因公司的规模和产品复杂程度而异。在某些组织中，PM 可能还承担设计职责，或者您可能拥有一名兼顾设计和工程角色的设计技术专家。此外，根据公司或组织的不同，工程或设计团队可能很大，并且项目中可能涉及不止一名设计师或工程师。但是，在构思阶段，最好由 PM 确定相关的工程和设计潜在客户，并将其纳入产品三重奏中。有时，根据产品和组织，可能需要包含其他角色。Teresa 写道：“产品三重奏的意图不是将其他角色排除在发现之外。这是为了强调在构建数字产品时跨职能协作的必要性。

关键要点是产品开发本质上是跨职能的，这些核心角色之间的早期协作可以显著增强发现过程。

时机就是一切

以下是三种常见情况，说明了为什么让 PM、设计师和工程师达成共识具有挑战性：

1. 迟交陷阱

想象一下，一位 PM 花了数周时间进行客户研究、采访利益相关者，并制作他们认为完美的产品需求文档。PM 将其交给模型设计、与几个客户一起测试，然后将其提交给工程部门进行实施。突然之间，PM 遇到了一连串的技术可行性问题，需要彻底重新思考。这种情况在行业中太常见了，因为它是由于在流程中太晚才涉及设计和工程。产品组合伙人 Marty Cagan 在他的书《Inspired》中恰当地指出：“如果你的开发人员第一次看到一个想法是在 sprint 计划中，那你就失败了。这种延迟参与不仅有项目延迟的风险，还会削弱团队成员和利益相关者之间的信任。

2. 早期参与陷阱

另一方面，一些 PM 为了具有包容性，从一开始就让广泛的利益相关者参与进来。想象一下这样一个场景：PM 在明确定义他们要解决的问题之前就召集了与设计、工程、营销和销售的会议。结果如何？满屋子的同事们感到困惑和可能感到沮丧，每个人都试图为一个定义不明确的目标做出贡献。这很快就会导致信誉的丧失和所有相关人员的时间浪费。著名的产品教练和全球科技公司的领导者 Simon Waldman 警告说：“仅仅说每个人都需要参与，然后无休止地发送电子邮件/Slack 线程，每个人都参与进来，这是不够的。

3. 优先级错位的困境

也许最令人沮丧的情况是，当 PM 和他们的团队投入大量时间和资源来解决客户问题，却在游戏后期才意识到它与关键业务目标不一致。这种错位可能导致项目停滞不前，以及对 PM 有效确定优先级的能力失去信任。

为了应对这些挑战并取得适当的平衡，重新定义产品团队的构成并检查产品开发过程的关键阶段至关重要。

在正确的时间让正确的参与者参与进来

让我们将产品开发过程分解为五个关键阶段，研究如何在每个点有效地让利益相关者参与进来：

1. 问题框架：奠定基础

在涉及整个产品三重奏之前，PM 应该明确问题陈述。这个关键的第一步确保所解决的问题与业务相关，并且值得产品团队投入时间和资源。Product Management Exercises 的创始人 Bijan Shahrokhi 建议 PM 们：“在你把你的需求摆在很多人面前之前，你要先在项目的早期阶段（尤其是构思的早期阶段）保持预言者的身份。

一般来说，在这个阶段，项目经理的一个好主意是独立进行高级客户研究，并制作一个问题概述文档，其中包含业务问题到底是什么、目标客户是谁和相关客户问题以及期望的结果是什么的详细信息。

获得此文档后，请与领导层和主要利益相关者一起审查它，以确保在进入下一阶段之前保持一致。这种方法有助于降低处理无影响问题的风险 （可行性风险），并为发现过程提供坚实的基础。请注意，尽管名称相似，但问题概述文档不得与产品需求文档混淆。在这个阶段，我们不关心解决方案——这个阶段的目标是理解问题及其重要性。

2. 定义需求：协作探索

在此阶段，产品三人组作为一个团队共同进行客户访谈和研究，确定相关用户故事并确定其优先级，协作起草和迭代 PRD，创建和改进设计模型，并持续评估技术可行性。此阶段的目标是起草可缓解三个关键风险的产品要求：

• 合意性风险：我们是否构建了客户真正想要的功能？
• 可用性风险：用户能否轻松找到并有效地使用我们正在构建的内容？
• 可行性风险：是否有可能使用我们分配的工程资源和现有的技术堆栈来构建它？

在此过程中，PM 需要确保他们不会与其他职能部门过于紧密地合作，而将另一个职能部门排除在外。Amazon 的首席设计技术专家 Anish Beetun 警告要注意这种常见的陷阱：“我经历过的一件不起作用的事情是 PM 和设计师花费数周时间制定解决方案，在没有任何工程师参与的情况下在设计中非常详细。这会使您的解决方案在将来出现工程可行性问题时不太灵活地适应变化。

虽然与设计和工程的早期合作在资源分配方面似乎成本高昂，但它最终通过防止可能破坏整个项目的后期问题来节省时间。处理这种协调是 PM 的一项关键技能，他们必须在未经授权的情况下领导，同时在此过程中充当教练。一家总部位于英国的 AI 健康科技公司的产品主管 Alla Kitov 对合作提出了这样的观点：“与设计和工程师合作就像在不同时间协调具有不同优势和位置的赛艇运动员。我重视早期参与和明确的界限。最重要的是要明白，我们都在这条船上，我们都在达到同一个目标。

3. 实施：保持参与度

这是产品三人组正式将需求移交给更大的工程团队进行开发的阶段。随着项目进入实施阶段，很容易假设工程部门占据主导地位，而 PM 和设计师则退后一步。但是，在此阶段保持产品三重奏的持续参与对于成功至关重要。

Product Management Exercises 的 Shahrokhi 建议：“一旦你进入开发阶段并转向更多的工程设计，就要保持与设计的沟通，让他们了解情况。在开发阶段持续参与设计使您能够快速解决工程团队没有预见到的挑战。

在此阶段，PM 和设计人员应定期参加 sprint 评审，或安排临时同步会议以解决新出现的问题。如果需要，他们必须准备好修改需求或设计输入。根据产品的不同，业务利益相关者也可以参与其中。

这种持续的协作有助于降低错过需求的风险，并在必要时最大限度地减少周转时间。

 4. 测试：最终审查

当工程部门宣布产品代码完成并经过单元测试时，人们很容易认为工作已经完成。事实并非如此。

在此阶段，产品三重奏必须齐聚一堂，在 Gamma（测试）环境中测试产品，并让内部业务利益相关者参与其他测试（如果可能且相关）。此处的目标是查找可能对用户体验产生不利影响的用户界面不一致或遗漏验证，并在最终发布之前向工程部门提供反馈。

最终审核可以发现可能被忽视的其他细微问题，从而确保更高质量的商品发布并维护买家信任。

5. 发布：协调发布

发布阶段通常与测试同时开始。作为 PM，您通常会带头准备上市材料，但与您的产品三人组和其他相关团队保持协作非常重要。这项工作将包括准备发布公告和帮助中心更新、与内部支持或营销团队合作，以及让产品三人组审查所有面向买家的消息。

这种协作方法可确保产品不仅在技术上合理，而且可以有效地传达给您的目标受众。