Marty Cagan谈产品探索的意义和流程

文 / Marty Cagan  译 / 林航,王烨,吉绚

Marty Cagan是享有世界声誉的产品管理专家,曾担任网景副总裁、eBay产品管理及设计高级副总裁。本文是他回顾自己二十多年来从事软件产品管理工作和经验 的总结,分享了探索产品的流程和方法。

产品开发宁缺勿滥​

有没有见过这样的情形?开发团队刚刚完成手头上的项目闲了下来,可产品经理一想到程序员们自在逍遥,就怎么也坐不住了。为了让他们马上开始新项目, 产品经理没日没夜地制作新项目的产品需求文档(PRD),以求速成。这样的事情在产品团队里时常上演,成为产品失败的罪魁祸首。

开发团队就像“嗷嗷待哺”的婴儿,胃口特别大,却分不清哪些该吃,哪些不该吃。只要产品需求文档到位,不论产品好坏,他们就马不停蹄地开始新一轮的 产品开发。后果可想而知。

追根溯源,这种现象的产生是因为产品开发团队里的程序员聘金不菲,公司不乐意看到他们闲着,只有“物尽其用”,才会让公司觉得安心。可聪明反被聪明 误,这种短视的行为,给产品的失败埋下了祸根。这种行为还会掩盖开发团队真正的价值。开发团队被公司异化成生产代码的机器,而不是共同探索、打造出成功产 品的“战友”。
只让开发人员负责软件的开发,明显低估了他们的价值。正确的做法是先通过产品探索定义出基本产品,确定产品是有价值的、可用的、可行的,然后再交给程序员 去开发。强迫开发团队满负荷工作的公司,显然是管理理念出现了问题:代码好不等于产品好。当然,这种现象和企业文化也脱不开关系。

不可否认,好的项目经理确实能保证产品的交付进度。但不能因此就盲目地让项目管理在公司里唱主角。进度安排合理、资源得到了优化配置不意味着产品就 能取得成功。通常,我会建议项目经理在产品探索阶段安静地坐在“观众席”上,等到确信设计的产品值得开发了,再粉墨登场率领团队开发产品。采取这套方案 后,收效不错。但如果产品探索阶段,团队里缺少能一统全局的主帅,这套方案就不适用了(在今后的文章中我再讨论这种现象)。

如果开发团队闲了下来,而新一轮产品探索还没完成,该怎么办?其实选择很多。

产品经理给开发团队预留一个月左右的任务。这样即使手头的项目卡了壳(比如原型测试中,用户的反馈意见很糟糕),在想到新方案之前,你的开发团队都 有事可做。

开发团队无事可做,还有可能是项目团队里开发人员和产品经理及设计师的比例失衡造成的。如果开发人员过多,那么产品设计团队永远跟不上进度,开发团 队必然会“档期”不满。

要记住,产品经理的使命是确保团队开发有价值的产品。让开发团队盲目开发未经验证的产品,也是一种浪费。

产品探索计划

为了不让程序员闲着,产品经理把本该花在产品探索上的时间都花在了赶写产品需求文档上。可这样的产品探索毫无价值。时间再紧迫,也不能牺牲那些创造 价值的关键步骤。而有些公司非常重视产品探索,却没有对这个过程做出合理的规划,不能保证每天做的都是有用功,自然无法快速开发出基本产品。所以,宝贵的 时间就这么白白浪费了。

产品探索规划是否详细,取决于公司的文化氛围和产品探索人员的能力。很多公司(特别是大规模公司)中,团队需要一个产品探索计划,明确项目必须实现 的内容、需要的资源,并给出粗略的进度安排。

我将列出常见产品探索计划的组成部分。但这不是模板,不要照着里面的内容生搬硬套,做些不需要做的事情。我列举的每个部分分别解决不同的问题,你可 以根据你要解决的问题,选择合适的探索计划。作为产品经理,你要审查这个计划并确保团队按计划执行。

制订计划只是产品开发中的一步,更重要的是保证产品探索确实是朝着满足基本要求的产品方向努力。另外,将这两步结合起来后,什么时候能真正开始构建 产品也是关键。这个过程的监督工作包括两个部分。

首先,我认为,产品的负责人(如产品经理或首席用户体验师)需要对这项活动尽到监督责任,他们积极的监督会对定义产品起到积极的作用。这里要说明一 点,这里的“监督”指的是每周至少询问一次产品探索团队下面这些问题。

其次,产品经理也有监督其他事务的职责,比如在项目管理方面,需要确保产品探索计划的实施情况,做好开发的一切准备工作。具体来讲,这包括保证开发 团队有足够的资源开展工作,明白项目时间限制及做好时间管理,确保开发者、产品管理者和设计者之间的良好沟通,根据计划从整体上推动进度,以及确保项目中 的时间都被有效利用。

项目经理的确可以督促大家完成项目,但要确保先确定基本产品,而不能仅写些开发文档。
不管怎样实施计划,如果公司很开明,允许你在探索产品上花时间,而不是仅仅撰写需求文档,那么我希望你不要浪费产品探索中的每一天。如果你已经花了很多工 夫,但仍感觉到很难开发出好产品,你应该尝试制订产品探索计划。

产品探索日记​

产品经理和设计师们放弃原有的线性、瀑布式的开发流程,转而采用我倡导的这种更具迭代性、探索性的流程后,通常需要花一些时间才能适应它的快节奏, 掌握产品探索的韵律。

这篇文章将再现产品探索的情景,让大家了解其核心内容。

因为产品的开发过程涉及的因素太多(如产品类型、投入的精力等),做这样的概括并不容易。我尽量使用比较典型和普遍的情景。为了覆盖尽可能多的要 点,我构思了以下情景。

第一周

周一

周二

周三

周四

周五

第二周

周一

周二

周三

周四

周五

第三周

周一

周二

周三

看完以上日记,希望你能明确以下10点。

当然了,实际项目不一定完全与我的描述相同,我希望传达这样一种观念:在把产品理念展示给真正的用户之前,不应该花两周时间撰写产品文档,更不能花 三周时间制作初期产品原型。

产品探索有特定的节奏和规律,它以构思产品设计、原型制作、用户测试,以及最重要的一点,反复学习为基础。如果你还没有亲身体验过探索产品的过程, 那么我希望这篇文章可以让你大致了解产品探索是什么,以及它与直接开始撰写产品文档的做法的区别。

Marty Cagan,作为负责定义和开发产品的高级经理人为多家一流企业工作过,亲历了个人电脑、互联网、电子商务的起落沉浮,致力于通过写作、演讲、培训帮助客 户打造富有创意的产品。

本文节选自华中科技大学出版社《启示录:打 造用户喜爱的产品》一书和作者的博客。该书从人员、流程、产品三个角度介绍了现代软件(互联网)产品管理的实践经验和理念。特此感谢华中科技大学出版社与 Marty Cagan先生授权。

Labels: webdev.