打造产品团队的十大方法（一个成功的产品团队）

打造产品团队的十大方法（一个成功的产品团队）(1)

正好一年前我被邀请至布达佩斯，在Craft Conference中做了一个演讲，我谈论了十点关于产品团队会失败的原因。

我主要讲述了为什么许多团队如此效率低下，尽管他们认为效率很重要。大部分的产品管理在任何有意义时期都很难“敏捷”起来，因为总体上来说，管理仍然是“瀑布“的方式。会议组织者今年又把我请回来了，去继续讨论这个话题，去讨论更多我所知道的——最好的团队是如何工作的。

上个星期我上传了这个演讲，所以这篇文章是一个叙述版本。

在第一次演讲之后，有相当多的人联系到我，问了更多关于选择的东西。除了推荐他们去读我的书，或者参加一个为期2天的研讨班之外，我想不到一个更满意的回答。所以，它激发我去更深入的思考，一个强大的产品团队中最重要的特征是什么，我终于强迫自己想出了十点我认为最重要的特征。

持续探索与交付

正如我讲述了瀑布模型环境下的十大弊端，我也讲了在持续探索与交付模型（同样以“双轨敏捷”著称，或者叫“探索短跑交付冲刺”）环境下成功团队的十大属性。

成功的关键

1. 授权产品团队

所有最重要的特征是强大产品团队的绝对基础概念。但那到底是什么意思呢？

首先，重要的是团队的持久性；这意味着团队成员不能像棋子一样被移来移去。如果他们想要实际创新，他们需要时间来了解彼此，了解他们的技术、客户以及行业环境。

其次，团队成员之间的情感共鸣是关键。这意味着理解并足够尊重彼此，每个团队成员在贡献、提建议的时候都感到很舒服，挑战自我，促进彼此做得更好。

第三，这意味着团队拥有必要的多样性技能，这些技能常常是指产品管理、用户体验设计以及开发，许多情况下我们还得用上数据分析和用户研究。

最后，尽管对于许多公司这是一个敏感的话题，也很难去争论co-located(同处一室)团队的优势。co-location指的是产品经理、产品设计师、工程师（或者至少是技术领导）全部彼此坐在一起。我们不可能所有的团队都实现co-location，但是我们在尝试。同时需要清楚的是，团队跨地点并没有什么问题，只有当单个团队被分裂，导致了速度尤其是创新上的消极影响时才是问题。

2. 产品愿景以及战略

为了使产品团队实际被授权并且行为有一定意义的自主性，团队必须对更广泛的行业背景有一个深入的理解。这从一个清楚并有吸引力的产品愿景开始，我们通常把这条实现产品愿景的途径称之为产品战略。

产品愿景描述的是我们正努力打造的世界，通常介于2-5年（对于硬件工作则更久）。

产品愿景必须是鼓舞人心的，如果做得好，它将是我们最有效的招聘工具之一，激发人们每天来上班。强大的技术人员会被一个鼓舞人心的愿景所吸引，他们想做一些有意义的事情。

产品战略是指在实现愿景的道路上我们计划输出的产品次序。尝试用一个产品就取悦所有人，这样的策略是十分愚蠢的。相反，对于市场、地理以及人群，我们应该有一个优先列表，我们专注于实现适合每个市场的产品／市场。

你拥有的团队越多，越是需要一个统一的愿景和战略，以便每个团队都能做出好的选择。

最重要的是，产品愿景应该是鼓舞人心的，而产品战略应该是有非常有目的性的。

3. 专注于业务成果

为了能够做出好的决定，一个被授权的、有自主性的团队所需要的业务环境的第二部分，是设置业务目标的优先顺序。OKR系统（Objectives and Key Results）正好有助于促进这些。

OKR反映了团队正在解决的详细业务问题列表。这些不是功能，功能只是这些问题的潜在解决方法，启动一个功能不是一个团队的成功，解决真正的商业问题才是。

这些绩效管理技术背后的两个原则是：首先，如果你给团队的是你需要他们解决的问题，而不是给他们解决方法的话，团队将会表现得更好；其次，用结果衡量团队，而不是产量。在路线图中输出功能是产量，解决业务问题则是结果。

4. 合格的产品经理

可悲的是，许多工程师从未有一个机会和一个有能力的产品经理一起工作。那些有过的工程师们坚信他们团队中有这样的产品经理。糟糕的是，许多的工程师甚至不知道产品经理应该给团队贡献什么。

这样考虑吧。为了产品团队解决复杂的业务问题，仅仅是技术上的解决方案是不够的，客户喜欢也同样是不够的，最困难的是，解决方案必须真正为你的业务工作。

想一想这意味什么。想象你正在为Uber、Airbnb工作，你必须面对复杂的法律、工会以及贸易组织。或者eBay，不得不面对一些重大的限制条件，来被归类为市场而不是一个电子商务网站。或者Tesla不得不面对自动导航仪的责任问题。每个公司都有一个关于这些限制条件类型的列表。

有法律限制，金融限制，销售和定价限制，品牌和市场限制，隐私限制，安全限制，合作契约条件等等。

不幸的是，很多情况下唯一能够完成这项工作的人是CEO，这样的话你就可以想象，为什么他或她真正授权给团队做决定会感觉到不舒服。

那团队应该如何做呢？有三种选择：一是CEO或者其它的执行人员决定一切；二是无能的产品经理安排一个大的会议，邀请高管们参加，让他们讨论出结果——这就是所谓的由委员会设计——他们一贯产生糟糕的结果；三是产品经理做好自己份内的工作，学习这些限制条款，把它们带入团队，以便产品团队能够明白解决问题的最好方案。

结合对技术的深入理解、对用户和客户的深刻认识，你就能够明白为什么这是一个艰难的工作。这也同样是一个强大产品团队的关键，尤其是如果团队想要任何意义的自治的话。

5. 协同驱动（collaboration-driven）解决方法

我在这里不是将”collaboration”作为一个流行语在讲。我这样说的意思不是指一个产品经理整合需求（“requirements”），一个设计师设计漂亮的东西，工程师在那里写代码，相反的是指三种技能——产品、设计和开发——真正协同起来解决问题。这是因为有了好的解决方法，技术驱动功能和功能驱动技术是一样的。技术能动设计选择和设计驱动技术选择是一样的。设计指导驱动功能和它反过来也是一样的。

关键在于技术、用户体验设计以及功能全都十分错综复杂，只有在这三者之间反复交换意见才能得出一个好的解决方法。

协同驱动（collaboration-driven）解决方法是co-located团队能够持续胜出分布式团队的唯一最大理由。

6. 产品发现：快速学习

许多伟大的产品归结于团队快速试验大量想法的能力。我们想要快速的将好想法从糟糕的想法中分离出来。产品发现是一套广泛的方法，旨在帮助我们快速学习哪些想法能飞，哪些想法不那么好。一些想法是大的，一些想法是小的，一些是冒险的，一些是昂贵的。有时候我们需要论证，有时候我们只是需要证据。

很多人用不同的方式描述这个产品发现，一些人喜欢将其描述成“成功之前先假装成功（fake it before you make it）”，一些人则喜欢强调“做事从小事做起（build things that don’t scale）”。关键在于我们需要快速学习、减少浪费。

用开发团队来创建并发行一个真正的产品来试验一个想法，是一种最慢、最昂贵的学习方法。

7. 关注关键风险

关于产品发现，这里有两个重要的点需要强调一下：

首先我们需要关注四大关键风险：价值风险——会有人买或者选择使用它吗？可用性风险——他们能够明白如何使用吗？可行性风险——我们的工程师能用已有的科技、时间和技术实现它吗？以及项目干系人（stakeholder）风险——公司不同部门的人同意这个解决方案吗？

在产品发现期间，我们将为这四个问题找到好的答案。如果找到了，我们就有了我们让研发团队花费时间创建并提供一个高质量产品并衡量解决方法的证据以及自信。

8. MVP的角色

MVP的概念是产品中最重要的概念之一，同时也是最受虐最容易误解的概念。

概括总是有风险的，但是我将在这儿冒着风险，提出“MVP不应该是一个产品”。在每一个我遇到的案子里，当团队花费时间和钱去建立一个真实的QA’d产品作为他们的MVP时，我总是能在事后为他们展示如何用更少的成本和浪费来完成同样的学习。

所以，MVP是一个实验，一个测试。它是常用的原型样式之一，通常是一个用户原型，有时是一个实时数据原型，有时是一个可用性原型。有时它们是会混合在一起。在每个案例中，它只是真实建立一个真正产品的一部分。

9. 产品交付：释放信心

我站在这里不是告诉开发者如何去建立并发布软件。正好相反，在上一个问题（团队用开发部门来创建这些MVP产品）所带来的问题之一，是开发团队经常被迫发布一些他们知道不是他们真正应该发布的软件。这不是他们站在后面感到舒服的产品。也许是主要的可靠性问题，或者比例问题，或者性能问题。但产品经理总是说：“这只是一个MVP，所以放松点！”

我在这里建议，当客户实际依赖于这款软件来经营自己的业务时，你不应该妥协。我们有很多好的产品发现技术测试MVP’s，这些方式能保护我们的客户，我们的收入，我们的声誉和我们自己的员工。

因此，使用您的最佳实践，并且只有当您对该版本具有必要的信心时，才能将真实产品发布到生产环境。