前eBay高级VP告诉你为什么你的产品会失败

【文章摘要】我见过大多数公司的工作方式，并注意到他们的工作方式离顶尖的公司的实际方式还差的很远。我得警告你这个讨论可能会有点令人沮丧，特别是你感到中枪了的时候。如果是这样的话，我只能说加油，hold住。

本文作者为Marty Cagan, 是享有世界声誉的产品管理专家，曾经担任网景副总裁、eBay产品管理及设计高级副总裁. 这篇文章是他最近给Craft Conference和 Mind The Product的设计师和开发者的演讲的叙述版本.

我见过大多数公司的工作方式，并注意到他们的工作方式离顶尖的公司的实际方式还差的很远。

我得警告你这个讨论可能会有点令人沮丧，特别是你感到中枪了的时候。如果是这样的话，我只能说加油，hold住。

让我们从大多数公司仍用来创造产品的方法谈起。我暂时先不会评论，让我们先描述一下那个过程。

所有的一起都是从点子开始的。在大多公司里，它们可能是来自管理层，关键相关人员，企业拥有者或者是大客户（或潜在用户）。但不管怎样，他们都是一大堆业务的不同部分想要我们做的一些事儿。

然后多半公司会把这些点子列出优先级画成roadmap，他们这么做原因有两个。第一，他们想要我们先做有价值的那些事。第二，他们希望能够预测什么时候事情能准备好。

为了这样做，几乎肯定会有某种形式的季度或年度计划会议，让领导们来考虑这些点子和讨论产品raodmap。但是为了划分优先级，他们先得需要每个项目的某种商业案例。

一些公司会做一个正式的商业案例，有些也是非正式的。但是不管怎样都是总结为每个点子需要知道的两件事：1)我们能赚多少？2)金钱和时间的成本是多少？这些信息通常都被用在了roadmap里，一般都是制定出下一个Q或者有时能多到下一年的。 到这个点上，产品和技术组就得到他们的行军令了。他们一般从高优先级的项目开始做。

一旦一个点子列到了优先级表的顶部，第一件事就是产品经理和各个相关者解释概念然后对出一些“要求”。

这些可以是用户事例或看起来就像是功能列表一样的东西，不过它的目的就是和设计师及工程师交流要做一个什么样的东西。 当需求收集起来后，UE团队（如果公司有的话）就需要提供出交互设计和视觉设计，在实体硬件的情况里还有工业设计。 最终需求和设计详细被送到工程师那里。一般这时敏捷开发就登场了。

总之，工程师一般会把工作分成一系列的迭代—Scrum开发里称为冲刺（Sprint）。大概1-3个冲刺就可以构建完一个点子。

QA测试最好能是这些冲刺的一部分。不过如果没有，QA团队会跟进做一些测试来确保新概念和宣传的一样有效，同时保证它不会引发新的问题。（称作退化‘regressions’）

一旦QA这边开绿灯了，这个新的点子就实施给真正的客户了。

在我第一次见过的许多公司里，不管大小，这基本就是他们怎么工作的，或曾经这么做过很长时间。不过同样是这些公司也在不停的抱怨缺乏创新和从点子到客户手里花的时间太长。

你可能注意到我提到了敏捷开发。尽管今天几乎人人都在谈敏捷，我刚才描述的更像是瀑布式流程。不过对工程师公平一点，他们在瀑布模式的大环境下这已经是他们能做到的最敏捷的做法了。

OK，这就是大多数团队的做法，不过为什么这会可能成为这么多问题的原因呢？

我现在要做的就是给你理清楚为什么这种常见的工作方式是多数产品失败的原因。

我真的可以一整天谈论这个流程的各种问题，不过我在这里先分享我认为这个流程有的最严重的10个问题。先说清楚，我说的这10个问题每一个都非常严重，其中一个就有可能使整个团队脱轨。但很多公司都有不少甚至全部10个问题。

1. 我们先从顶部开始—点子的来源。这种模式会导致销售额驱动的特例和利益相关者推动的产品。关于这点可以讲很多，不过现在我只能说这种方式不是很好的点子来源。另外一个结果就是这种方法不会给团队太多权利，他们就是来实施的。是佣兵。

2. 接着我们来谈谈这些商业案例里的致命缺陷。先说清楚，我是很喜欢做商业案例的，至少是为值得更进投资的点子做。但是在现在多数公司为了想出优化过的roadmap，做商例的方式简直可笑。原因是这样的。记得每个商业案例最关键的两个输入值是什么吗？能赚多少和得花多少？真相是在这个阶段，我们根本无从知道这些，也不可能知道。

我们无法知道能挣多少钱因为这很大程度上取决于最终解决方案出来能有多好。如果团队做的不错，这可能会非常成功并真的能改变你们公司的方向。另一方面，事实是很多产品点子最后结果是没有任何有意义的产出。这不是夸张，真的啥都没有。不管怎样，产品里最重要的一课就是知道我们不知道什么，我们就是没法在这个阶段知道产品能赚多少钱。

同样的，我们根本不知道要花多少钱。不知道具体解决方案的情况下，开发是很难做预测的。多数有经验的工程师在这个阶段拒绝给出预估，不过有些迫于压力会给出经典的T恤承诺—“S, M, L, XL”。 但是公司真的很想要份优先级排好了的roadmap。要想得到一份他们就需要某种系统来给点子评级，所以大家就玩商业案例的游戏。

3. 下面这个问题更大。公司做出了roadmap，他们为此还很激动。我见过无数roadmap，大多数实际上就是功能优先级表单。市场要这个功能做活动，销售要这个功能获取新用户，路人甲想要paypal整合进来。。。你懂得。

不过这就是问题了，而且可能是的问题。我称为“产品的两个不堪事实”。

第一个是这些点子里至少一半是不work的。一个点子行不通的原因很多。最常见的就是用户不像我们那样为这个点子激动，所以他们就不用了。有时用户想用但是试过以后发现不值得，太麻烦了，最后也是一样的结果—用户选择不去使用了。有时问题是用户很想要这个但是发现要做它比我们像的还要复杂，于是我们就简单决定我们花不起这个钱和时间去实现它。

所以我向你保证你roadmap里的点子至少一半是行不通的。顺带一提，好的团队会假设3/4的点子不会按预想的表现。

如果这样还不够糟， 第二个不堪的事实是及时在你证明的有潜力的想法里，一般也要好几个迭代来落实这个想法，直到它能真正产生所需的商业价值。我们叫它“时间金钱比”。

关于产品我学到的最重要的东西之一就是这些事实你是没法摆脱的，不管你多聪明。我曾有幸和许多出色的产品团队工作。真正的差别是你如何处理这些事实。

4. 接下来咱们讨论一下这种模式里的产品的角色。实际上我们根本就不把这个角色叫产品。它其实是一种项目管理。在这种模式里更多的是收集需求和把需求文档同步给开发。我只能说这个现代产品管理差十万八千里。

5. 设计的角色也是很相似的情况。让设计产生价值的阶段太晚了，基本所做的事是我们称作“给猪涂口红”的模式。损失已经造成了，我们只是在试图粉饰一个一团糟的东西。UE设计师知道这样不好，不过他们还是试着尽可能把它做好看做流畅一点。

6. 也许这种模式里失去的机会，是开发带入进来的太晚了。我们讲如果你只是用你的程序员去编程，你只获得了他们一半的价值。产品里的一个小秘密是工程师一般是最好的创新来源，但是这个流程里的party部分甚至就没邀请他们。

7. 不仅开发带入的太晚了，敏捷开发的原则和好处都入场太晚太晚了。用敏捷开发的团队可能只用到20%的实际价值和潜在敏捷开发方法。你所见的就是只有交付部分是敏捷的，而组织剩下的部分和大环境都根本和敏捷无关。

8. 整个流程都以项目为中心。公司一般为项目出资，招人，在组织里推动项目并最终启动项目。不幸的是，项目是产出而产品只关心结果。可预见的是这个过程会产生孤儿项目。是的，总算发布了一个东西，可是如果它无法达成目的那有什么意义。不管怎样，这问题很严重而且离该怎么做产品差远了。

9. 老式瀑布流程的问题一直且仍然是，所有的风险都集中在了终端．这就意味着用户验证发生的太晚了．

你可能已经听过精益创业的方法，这些方法基本是另辟蹊径方式的的核心．关键的原则是减少浪费，而浪费的形式就是设计，建造和实施一个功能或产品结果发现它根本不是我们想要的．讽刺的是很多团队相信他们遵从着精益原则，却做着基本上就是我上面描述的过程．然后我会给他们指出他们实际上在用已知的最贵最慢的方式来试他们的电子．

10. 最后，当我们做着这个流程并浪费着时间和金钱，的损失是组织原本可以或应该去做的事的机会成本．我们是收不回那部分钱的．

对我来说很多公司投入那多时间金钱，收益却入此小时不意外的．我警告过你这可能有点扫兴．

好消息是我向你保证最好的团队一点都不像我上面描述的那样工作．

我写过很多关于最好的团队合作各个方面的文章．＇产品发现＇是我们如何发现我们正在攻坚的问题的取胜方案．＇发现＇是一个主动且持续的产品，ＵＥ和开发之间的合作．＇持续发现＇和＇持续呈现＇是平行发生的．Roadmap上的功能（输出）被待解决的商业问题（结果）替代．目标就是产品和市场契合．

如果你们公司仍在运行这样的又老又过时的流程，那希望你听了这个能亮盏灯并在未来做出转变．而且希望你的转变能在一个创业公司或竞争对手搅局的之前最快最有效的完成．