产品经理必读 – 产品失败的10大根源

本文介绍了大多数公司采用的产品开发方法,文中指出了这其中的问题,并剖析了导致产品失败的十大根源问题。最后提醒了至今还采用这种产品开发方法的公司,固守成规必然会被新时代的初创公司或是竟争对手所超越,应该居安思危,尽快转型,否则会被时代所抛弃。

0
530

原作者介绍:
Marty Cagan 产品经理圣经《启示录》的作者,曾经在 eBay, AOL, Netscape, Continuus 和 HP等财富500公司和创业公司任高级管理职位。主要负责商业策略,产品设计,用户体验和产品研发。

译文:厉晓明    原文:https://svpg.com/product-fail/

失败的产品

注意: 之前我分别在Craft Conference和Mind The Product Conference上为开发人员、产品经理和产品设计师演讲过本文中的内容,这篇文章是演讲内容的叙述版本。

在本文,我将讨论导致众多产品失败的根本原因。

我在大多数公司都看到了相类似的工作方式,同时,我也注意到,这种工作方式与优秀的公司所具有的工作方式大相径庭。

我先提醒一下大家,接下来的讨论可能会令人失望,特别是当你也有类似经历时,我希望你能坚持看到最后。

首先,我们来看看被大多数公司所采用的产品创建过程,对于此过程我稍后再发表评论,先看产品创建过程:

一切从一个创意开始。在大多数公司,创意来自高管、关键利益者、企业主、大客户(或潜在客户),但无论如何,总有一大堆事情等着我们去做。

然后,大多数公司都会把这些创意放入到产品路线图中,对他们进行优先级排序,他们这样做主要有两个原因:1)他们希望先做高价值的部分,2)他们希望能够预测创意何时可以实现。

为了做到这些,几乎总是会有某种形式的季度或年度计划会议,在会议上,领导们会考虑这些想法,并对产品路线图进行讨价还价。为了确定优先级,他们总是需要一些商业计划才能做出判断。

有些公司会做正式的商业计划,有些则是非正式的,但不管怎样,每个创意的商业计划都必须包含两个关键元素:1)这个创意最终能赚多少钱? 2)要实现这个创意,要花多少钱或时间?
这些信息随后被用于制定产品路线图,通常是为下个季度制定的,但有时长达一年。

产品和技术团队通常会有自己的节奏,一般来说他们会按照路线图中工作项的优先级自上而下领取工作,开始实施。

针对优先级最高的工作项,产品和技术团队的首要工作就是让产品经理与相关人员进行沟通,将想法具体化,并提出一组“需求”。

这些需求可能是用户故事,也可能某种形式的需求规格说明书,其目的是与设计师和工程师沟通需要构建什么。

一旦需求准备停当,用户体验设计团队(假设公司有这样一个团队)就会被要求提供交互设计,视觉设计,以及工业设计(如果涉及到设备)。

最后,需求和规格说明书交给了工程师,正是从此时起,进入了敏捷开发过程

工程师通常会对需求展开近一步的拆分,并将拆分的任务分配到多个迭代中(在Scrum中被称为“冲刺”),最后确定也许需要1-3个迭代才能实现这个创意。

好一点的团队中,QA和测试会和开发人员一起完成冲刺。但如果不是,QA团队将持续跟进并做一些测试,以确保这些新的创意会像预期的那样工作,并且不会引入其他问题(称为回归测试)。

一旦测试和QA都给出了通过的结论,这个新的创意最终会部署给实际的客户。

在我遇到的大大小小的公司中,这基本上就是他们延续了多年的工作方式。但是,同样也是这些公司一直在抱怨缺乏创新,认为从一个创意到客户手中需要太长的时间。

也许你会意识到,我在上面也提到了敏捷,尽管今天几乎所有人都声称自己是敏捷的,但我刚才描述的是一个非常典型瀑布过程。为了对那些辛苦工作的工程师们公平一点,应该说他们已经在可能允许的范围内最大限度的采用敏捷了。

那好,以上可能是大多数团队的做法,但我们如何认定这就是造成问题的根源呢?

我现在想把这些点串接起来,让大家能理解,为什么这种非常常见的工作方式反而是导致产品失败的罪魁祸首。

这些问题足够我们讨论一整天,但在这里我只想分享十个我认为最严重的问题。需要明确的是,我认为这十个问题中的任何一个都能导致整个团队脱轨,而实际上很多公司都存在这些问题。

1. 让我们从源头开始——创意的来源问题

以上模式是以销售价值导向和利益相关者驱动产品的开发。关于这个关键话题还有很多东西要讲,但现在我只想说,这不是产品创意最好的来源方式。这种方法的另一个后果是缺乏团队的授权——在这种价值导向的模型中,他们只是在那里执行,只是服从命令的雇佣兵。

2. 商业计划中的致命缺陷

需要澄清的是,我实际上很喜欢做商业计划,至少对于那些需要大量投资的创意,商业计划书是非常必要的。但是,大多数公司为了制定一个优先级排序的路线图而做的这些商业计划是非常荒唐的,至少对于这个路线图所处的时间点而言。还记得那两个关键输入吗?你能赚多少钱,要花多少钱? 那好,残酷的是,在这个阶段,我们对这两个问题都没有任何线索,我们还不可能知道这两个问题的答案。

我们不知道我们能赚多少钱,因为这很大程度上取决于解决方案的好坏。如果团队做得很好,这可能会非常成功,并真正改变公司的发展进程。另一方面,事实是,许多产品创意最终完全没有价值。这并不夸张。真的什么都没有。无论如何,在产品中最重要的一课就是知道了我们不知道的东西,在这个阶段其实我们并不知道能赚多少钱。

同理,我们也不知道实现这个创意要花多少钱。在不知道实际解决方案的情况下,对整个实现过程来说也是很难预测的。大多数经验丰富的工程师在这个阶段甚至会拒绝给出一个估算,有些人会被迫采用“T恤尺码”的估算方案——至少让我们知道这是“小号、中号、大号还是特大号”的创意。

但是从公司的角度而言,这些路线图是必须的。为了能够产生这些路线图,他们采用某种投票机制,并开始大玩各种估算游戏。

3. 更大的问题—路线图让所有人兴奋不已

我看过无数的路线图,其中绝大多数都是按优先级顺序排列的特性列表。市场营销需要这个特性来开展营销活动。销售人员需要为新客户提供这个特性,比如:提供与PayPal的集成,你懂的。

但问题是,这本身可能就是最大的问题。我称之为“关于产品的两个不容忽视的事实”。

第一个事实是:我们至少有一半的创意是行不通的。有很多理由让一个创意行不通,最常见的是,客户对这个想法并不像我们那样兴奋。所以他们并不会使用它。有时他们会想使用,但他们试用后发现是如此的复杂,相比带来的价值,这只能为用户带来更多麻烦,最终结果还是一样:用户不会使用它。有时候,问题是客户虽然喜欢它,但事实是这个特性比我们想象的复杂得多,最终我们发现根本无法负担实现这个特性的成本。

我敢保证,路线图上至少会有一半的内容不会如我们所期望的那样被实现。顺便说一下,真正优秀的团队认为,至少有四分之三的内容不会如我们所期望的那样被实现。

如果上面的第一个事实还不够,那么第二个难以忽视的事实是:尽管这些想法确实被证明具有潜力,通常也需要经历数次迭代,创意的实现才能达到真正交付真实价值的程度。我们称之为“Time to Money”。

有关产品开发最重要的认知是,不管你有多聪明,这些问题都是无法避免的,我有幸与许多真正优秀的产品团队合作,这些问题无一例外都存在,区别在于他们如何对待这些事实。

4. 产品经理的错位

事实上,我们甚至根本不把这个角色叫做产品经理,因为实际上就是一个项目经理。在上面的过程中,更多的是收集需求并为工程师记录这些需求。在这一点上,我只想说以上的管理方式与现代产品管理的工作方式相差甚远。

5. 设计师的错位

这个过程中,设计师介入的时间有点太晚了,已经无法帮助团队定位创意的价值所在。设计师在这种情况下只能“粉饰太平”。损害已经造成了,现在设计师只是想给这团乱麻涂上一层漂亮的彩妆。设计师知道这解决不了问题,但他们会尽量让它看起来很好、很一致。

6. 工程师介入得太晚

在IT行业有这样一个说法:如果我们的工程师只是用来写代码,那我们只获得了他一半的价值。产品开发的秘密是,工程师其实是产品创新的来源,但实际上他们都被排挤在外了。

7. 敏捷开发介入得太晚

以上面所说的方式使用的所谓敏捷方法,团队其实只获取了敏捷方法实际价值的20%。上面的过程中仅仅在是在交付过程中引入了敏捷,而组织的其他部分和周边环境则完全不是敏捷的。

8. 项目化管理

企业已经习惯于针对项目进行投资并配备资源,推动这些项目通过审核,并最终启动项目。不幸的是,项目重视的是产出(output),而产品开发要的是结果(outcome)。采用项目制管理可以预见导致各种孤立的交付物。我们确实最终发布了些内容,但它们不能帮助企业达成目标,那么这样做到底有什么意义?无论如何,项目制管理模式都是非常严重的根源性问题,与我们追求的产品开发模式大相径庭。

9. 风险都在最后

也许你听说过精益创业方法,这就是现代产品开发的核心思想。精益思想的核心原则是减少浪费,浪费的最大表现形式就是费了大量精力设计、构建、测试和部署一个特性或产品,结果却发现它不是客户所需要的。具有讽刺意味的是,许多团队认为他们正在应用精益原则进行尝试,但却是用了以上这种极其错误的管理模型。所以我必须说的是,他们实际上是在用一种最昂贵、最慢的方式尝试创意。

10. 机会成本

最后,当我们忙着遵循这个流程,浪费我们的时间和金钱时,最大的损失是组织失去了市场先机。这件事本来可以更快做好,也完全可以做好,但问题是世间没有后悔药,所有的时间和金钱都付之东流了。

如此多的公司花费了大量的时间和金钱,得到的回报却少之又少,这对我来说并不奇怪。我在前面提醒过大家,这些分析可能会让你失望。

好消息是,我向你们保证,最好的团队不会像我刚才描述的那样运作。

我已经写了很多与产品开发的文章,这些文章都阐述了最优秀的团队是如何工作的。产品的探索过程,其实是我们如何找到解决方案的过程。探索是产品、用户体验设计和工程之间积极、持续的协作后产生的结果。持续探索和持续交付是同时进行的。我们需要的不是产品路线图上的特性(output输出),而是商业问题的解决方案(结果outcome)。最终的目标是使产品和市场具有更好的契合度。

如果您的公司仍然在遵循这个老掉牙且过时的流程,那么希望您能够意识到问题的严重性,并开始向未来过渡。我特别希望看到的是,在你被一家动作更加迅速的竞争对手打乱阵脚之前意识到这个问题,并作出应有的改变。

- leansoftx.com -