跨职能团队的协作质量如何，取决于团队和个人以一种什么样的关系存在！

“产品探索”不同于传统的“需求发现”的特征之一就是：它是一种全员参与的了解客户的组织形式。

传统的“需求发现”往往以“产品经理”为核心和主导，这个无需多讲，产品经理们都有体会，从商业级别的《商业需求文档》，到市场级别的《市场需求文档》，再到产品级别的《产品需求文档》，直到开发级别的《需求规格说明书》，往往都是产品经理一个人包办，团队的其它成员不能说不参与，只不过通常是一种“有限参与”的形式。

同时，在以往的“需求发现”过程中，企业通常以一种“线性”的形式开展工作，什么意思呢，比方说，产品经理通常扮演“发现”需求的角色，而技术人员通常扮演“实现”需求的角色，技术人员往往只是被动的接受来自产品经理的需求，而不是在初期就参与到需求的发现过程中来。

我个人认为，要做好“产品探索”的工作，首先就是得把这个“跨职能团队”构建起来，因此，我就把如何构建“产品发现”团队放到了正篇的第一篇中。

接下来，我就说一下如何构建“产品探索”团队。

1、为什么要让产品团队完全参与

为什么说在传统的“需求发现”过程中，产品团队成员的“有限参与”越来越不能够满足“需求管理”的目标呢？

换句话说，产品团队“完全参与”的“产品探索”能带给他们何种不同的体验呢？主要有三点：

1）更好的了解客户和他们的需要

产品或者一个初创企业的失败，最大的因素就是做了一个没有客户需要的产品。

按照传统的“需求发现”流程，产品经理事实上承担了最大和最多的职责，但即使如此，也往往会出现对客户需要理解不透的情况，其中一个重要的原因就是产品经理就算是一把“瑞士军刀”，也会遇到无法面对的问题，比方说高度专业化的领域和客户。

例如，你负责的是一款财务软件，如果你不是财务专业出身，那么事实上你很难吃透客户的需要，那么，这就需要专业的财务专家来帮你分析业务层面的需要到底是什么。

产品经理与其把财务专家看成是一个独立的，可借助的资源的话，那为什么不把他们纳入到你的“产品探索”团队中呢？

2）团队内部形成一致的“共情”

产品经理是最了解客户，也是最容易和客户产生“共情”的一个角色。

但是，产品团队中的其他成员呢？

我们必须承认这样一种情况，并非他们不想和客户“打成一片”，而是以往的产品管理模式让他们不得不远离客户，最常见的莫过于产品经理负责发现，技术团队负责交付。

而脱离了和客户“共情”的交付，事实上很多时候就成了炫技的舞台，因为交付团队并不需要真正站在客户的角度去思考客户到底需要什么样到的技术解决方案，他们只需要“出彩”的完成产品经理发现的需求即可。

因此，让产品团队中的其他必要成员在初期就加入到“产品发现”的过程中，可以让他们从一开始就和产品经理一起去了解，学习，懂得客户真正想要什么，不去懂得客户遇到的现实问题和挑战，他们永远不会和客户“感同身受”。

3）减少产品管理过程中的摩擦

在以往的产品管理过程中，决策建议往往由产品经理提出，高层拍板，其他部门执行，这样出现的最大风险就是“决策过程被高度垄断和黑箱化”，而一旦出现问题，产品经理往往就会成为被指责的对象。

很多产品经理都遇到过这样的情况，产品都已经开始开发了，团队中竟然还存在“要做什么”的争议和异议。

无论从哪个角度看，这一定都是一种不正常的现象，但也从侧面印证了一点，决策的过程是一定要放到台面上的。

我们都知道，产品经理是在管理着一个“跨职能”的团队，而“跨职能”团队表现好坏的一个重要特征就是“协作化质量”如何。

而协作质量如何，其中一个重要的标志就是：团队在完成工作的时候要分而治之，而在做决定的时候一定要团结一致。

因此，把相关的团队成员纳入到“产品探索”的过程中，可以保证我们整个团队在面对客户和他们的需要做出必要决策的时候能够是一次“圆桌会议”。

总之，在理想情况下，“产品探索”是整个团队的协作任务，这样每个成员都可以从收集到的反馈中学习，站在同一个平台上，用一致的“共情”开展相应的工作，努力解决客户的问题。

2、“产品探索”团队的组织形式是什么样的

从我个人的体会来说，“产品探索”团队的组织形式并非是一种固化的状态，产品经理要根据产品的目标和计划而进行灵活的组织。

比方说在谷歌，就有所谓的“THE TRIO”，通常翻译为“产品三人组”，大家看图6：

但是，还是我说的，一切要以你的产品目标和计划来确保“产品探索”团队有合适的人选。

比方说，前面我们提到的，如果你负责的是一款财务软件，那么，团队中就得有一名财务专家，同样，如果你做的是一款人工智能产品，那AI专家就必不可少。

其实这个道理很容易理解，我曾经在《4+2，产品经理需要搞定的六大领域知识》这篇文章中提到，产品经理需要六方面的知识构成，大家看图7：

要求是有了，但现实的情况是，没有一个产品经理能做到对这些知识的完全掌握和精通，但是，缺乏这些知识中的某些部分，是不太可能做好产品的，因此，才需要各个专业领域的人才组成一个“跨职能”的协作团队，由产品经理领导完成产品的目标。

“产品探索”是一切产品发展的起点，缺乏专业人才的参与，势必会影响我们客观、全面、深入的发现客户的需要。

那么，“产品探索”团队到底应该怎么来组建呢？

通常我们会根据不同成员参与的时间性和深入性分为三类，每一类下有对应的角色，大家看图8：

三类分别是：永久性成员；临时性成员；支持性成员。

在每一类下，都有对应的职位，简单介绍一下每类成员主要的职责是什么。

永久性成员（核心团队）：这类下的角色容易理解，就是完全参与“产品探索”的全部过程，并根据产品探索获得的信息和知识，对解决方案进行设计，并通过客户的验证。

临时性成员（具有关键技能/资源的个体）：这类下的角色主要是根据“产品探索”的阶段性目标以及产品所处的阶段目标有条件的参与，主要的职责是向永久性团队提供必要和足够的支持，比方说销售代表就需要协助产品经理完成产品概念的测试。

支持性成员（利益相关者）：这类下的角色主要是向以上两类角色提供必要的资源支持和协调工作关系，以及提供具有共享性质的信息和支持，比方说其它产品团队就需要通过必要的形式（例如，PMG）向你的产品团队提供和你的目标客户有关的知识。

至于团队规模有多大，这个由产品经理来决定，通常核心团队成员控制在3-5人即可。

不过在我看来，以上这些内容都不重要，最重要的是：

“产品探索”团队由谁来领导？

这个就不客气了，通常是由产品经理来领导，但也可以由高级领导，比方说CPO来领导，但无论由谁来领导，千万记住一点：

这个领导一定是和业务紧密相关的，如果由涉及太多职能管理的来领导就要慎重了。

总之，对于“产品探索”团队的组成，我们还是要以两个确保作为团队质量衡量的标准：

1）确保团队能够根据自己的节奏产生见解并做出决定。通过减少对中央部门的依赖，产品团队可以从共享他们的研究或验证工作中受益。要让产品团队最终拥有整个过程，并且感觉自己被授权并对结果负责。

2）确保对于客户需要的认知不存在偏差，在整体上处于一个平衡的状态。不同领域团队的成员会为整个团队带来一套独特的解释和观点。要让每个团队成员感觉到每个人的观点是被受到重视的，是用来探讨而不是引发矛盾的，这是一种避免“前期不说，后期乱说”的团队沟通方式。