《启示录》教会我们的知识（上半部分）

本书的作者是硅谷知名产品集团创始人Marty Cagan。里面介绍了产品经理的职责和产品管理的流程，很多案例都可以跟我们身处的环境（不管好的还是坏的）对上号，阅读的价值还是很高的。

本书出现频次最多的话也是本书的核心，产品经理负责研发出：有价值的！可行的、可用的产品。

一、阅读这本书的时候，不如先翻到书的最后看“产品经理的反省清单”，反省一下自己真的了解产品经理的职责到底是什么吗？自己有在做产品应该做的事情吗？

1、你的产品能吸引目标消费者的关注吗？

2、产品的设计是否人性化，是否易于操作？

3、产品能在竞争中取胜吗？即使面对未来风云变化的市场，依旧有把握取胜吗？

4、你了解目标用户吗，你做的产品是否得道了目标用户的认可？

5、产品是否有别于市面上的其他产品？你能在两分钟向公司高管清楚的阐明这些差别吗？能在一分钟之内给客户解释清楚吗？能在半分钟内向经验丰富的行业分析师解释清楚吗？

6、产品能正常运行吗？

7、产品是否完整？用户对产品的印象如何？销售业绩如何？销售任务是否能顺利完成？

8、产品的特色是否与目标用户的需求一致？产品特色是否鲜明？

9、产品值钱吗？值多少钱？为什么值这么多钱？用户会选择更便宜的产品吗？

10、你了解其他团队成员对产品的看法吗？他们觉得产品好在哪里？大家对于产品的观点是否一致？

产品经理的思考非常重要，好好思考这些问题。这些问题也侧面反应了产品经理的工作方向。

书中所阐述的“产品管理”概念，不管是从人员配置还是资源调度、产品流程都是教科书式的、或者也可以理解成为“理想状况下的”，国内大部分公司和创业型公司，不管在思想还是资源、可能都无法支持书中的模式，而且国内大部分产品经理所做的事情可能都不是“产品经理的工作”，或者理解成，产品经理一人肩负多职，没时间去思考“产品经理该做什么”。

重要的事情再说一遍，书中主旨：打造有价值的、可行的、可用的产品。

二、有价值的

有价值的：不难理解有价值的。。。额。。就是有价值的，但是每个公司的目标和衡量指标不同，因此对于“有价值的”标准也不同。

1）例如：对于有些公司来说，公司赚钱了，那就是有价值的，有一些则是解决了核心用户的难题，也是有价值的。

2）再例如：对于创业团队，如何打造一个能吸引大量用户入驻的新产品也是有价值的。

如何判断产品是否有价值是“产品一生当中的第一步”，书中的方法是：

评估产品机会。

1、很多时候或者说大部分公司提出产品idea的人不是产品经理，而是boss、高管、或者合作伙伴，不管是谁提出的idea，这时候产品应该是是一个脑补的蓝图、虽然没有实际形状，但是大家可能心里都有个数知道他应该，可能是什么。这时候需要产品经理需要解决以下10个问题。

1）产品（这个idea）能解决什么问题？（价值）

2）产品为谁解决这个问题？（市场）

3）成功的机会有多大？（市场规模）

4）怎么判断产品的成功与否？（指标、收益指标）

5）有哪些同类产品？（竞争格局）

6）为什么我们最适合（要做）这个产品？（竞争优势，我们的能力、资源）

7）时机合适吗？（市场时机）

——————————————优先级分割线—————————————

8）如何把产品推向市场？（营销方案）

9）成功的必要条件是什么？（解决方案要满足的条件）

10）根据以上问题，给出评估结论（做 or 不做）？

ps：其实这些也是MRD所需要囊括的内容。

往往在这个阶段，大家都各自说出自己的想法，产品经理这时候不仅要参与讨论，同时也要在心里默默的思考基本的解决方案。产品经理的思维比大家快一步，是好的，解决方案也是衡量产品最终做还是不做的重要因素，如何无法解决，那么就算“产品”再有价值，可能我们也要忍痛放弃。

这里面最难答的问题其实是第一个问题。——产品价值。好多人针对这个问题都是所答非所问，只能泛泛的回答出“产品“特色和功能什么的。如果作为产品经理的你，能在此时此刻总结思考出，产品的价值，不仅仅会让ceo对此产品是非有信心，支持你做下去。也会让参与工作的同事信心倍增。

三、可行的、可用的

发现机会并不难，难的是寻求解决方案，在这个阶段，产品经理需要分析各种创意、广泛收集产品需求，了解如何运用新技术，全局思考产品方向。包括以下几方面的工作

可行的：当确定了产品的雏形，和蓝图，下一步就是定义产品了，定义出来的产品，我们要确认他是 “可行的”，就是兼顾功能性与设计性的产品，并且，我们的开发人员可以在预期的时间内可以做出来。

可用的：这两块可以放在一起说、可用的就是保证，我们的产品能满足大部分用户使用习惯，如果定义的产品让用户找不到东南西北，那产品无疑是失败的。

这是一个过程：作者把他成为“探索产品”（定义产品解决方案）这个过程有这么重要的几步：

1）需求调研    2）市场调研     3）产品人物角色  

在这期间产品经理会得到各个部门或者各个同事的”帮助“，伴随而来的是雨点一般密集的需求和意见。大部分公司停留在这个阶段的时间最长，频繁的开会，频繁的讨论，频繁的头脑风暴，但往往有时候，这些会议毫无意义，浪费时间，讨论不出实质性的结果，甚至随着需求和争议越来越多，最后定下来的产品回到起点，回到最初那个最简单的版本。最可怕的弊端是频繁又没意义的争吵会影响团结。作者认为这种问题产生的原因有三个：

1、每个同事对于产品都有自己的看法。

2、大家都很在乎产品

3、每个人都觉得自己比其他人了解产品和用户。

四、这时候书中提出两个概念工具：

一、制定“产品原则”（确定什么是最重要的）

产品原则是对团队信仰和价值观的总结，用来指导产品团队做出正确的决策和取舍。它意味着对于产品来说什么最重要、什么不重要，哪些是战略性的，哪些是战术性的。

制定产品原则有助于让团队在认识上保持一致。让大家在以下几点达成共识：

1）究竟要解决什么问题？

2）为那些人物角色解决问题？

3）产品要达到什么目标？

4）每个目标的优先级是什么？

二、产品评审团（制定产品决策）

在产品管理中，产品经理并不能做到一手遮天，当面临制定产品决策时，也就是“拍板”的时候，需要有产品评审团的帮助，评审团通常由各部门主管和高管组成，这里难度在于：产品经理在组织产品评审团的时候，要明确表示产品评审团只做决策，不参与设计工作。同时产品评审团也兼顾总结，监督的工作。

ok 我们回到探索产品的过成中去，当产品完成了调研和分析的工作后，就要与视觉设计师和交互设计师，一起设计“产品原型”，大部分公司或者说没有条件的公司，这个工作可能都是产品经理自己完成，首先这是不对的，画原型产品绝对没有设计师专业。或者有的公司可能都没有设计师。。。

总之原型一定是产品和设计师通力完成，最好在这期间找一个技术好的同事或者技术经理一起参与进来，这样的好处是：既可以把控设计是否是可行的，又可以提前了解功能需求，为接下来的开发任务指定提前做好准备。这也是书中作者推崇的“敏捷办法”中的一条。

五、敏捷办法粗糙描述

可能国内大部分公司或者说不了解产品管理的公司，产品的流程是这样的:

老板把需求给到产品------->产品自己分析需求，画出低保真原型图------->交给设计或者美工做出设计稿、产品写出详细产品文档------->美工做好设计稿给开发人员开发------->开发完测试------->有问题重新设计或者直接在程序上改------->艰难开发出1.0版本.

作者认为这种模式是十分错误的，而且会带来很大的问题。因为每个工作环节的闭塞的，单向的，必须等到上一环节完成才能进行下一个环节，一旦哪一个个环节出现问题，可能还要追朔之前的环节重新调整。这样闭塞的结构，必定效率很差，发现问题也很晚，往往创业型公司就是因为这种模式拖到资金消耗殆尽而死亡的。

书中作者推荐的流程简单描述下是这样的：

得到需求------->产品把控、分析需求------->与设计和技术通力合作做出可行的、有价值的、可用的高保真原型（甚至是囊括后台数据的交互demo）------->原型测试------->调整原型------->开发

单单在流程上可能看不出第二种方法的优势。

第二种方法把前期大量的精力放在设计原型上，且原型是高保真的，并且在设计过程中信息和进度是共享的，不闭塞。这样做的话，在产品不同阶段工作衔接时，会节省掉大部分时间，同时我们可以用原型去做“用户可用性测试”，目的是测试原型的交互设计和视觉设计是否符合用户要求，如果不符合，那么我们可以在没开发之前进行调整。不会像第一种方法频繁的改需求打消开发人员的积极性。这种方法，我们能保证的是交给开发人员的原型（后者说是需求），绝对是有价值的，可行的，，可用的。而不是不确定的，需要频繁改动的。不会轻易耗费开发资源，在开发结束后，只需要测试功能就可以了。

另外一点，作者认为这种方法用高保真原型，代替了纸面文字的产品需求文档。这也是是极好的。

我们先来说说纸面文档的缺点：

1、互联网产品单纯用文字和图片，很难完整的表达需求。

2、文档没办法表述用户体验，视觉效果等一系列细节问题。

3、开发人员不喜欢看文档（现实）。

高保真原型的优点：

1、能清晰的体现出产品的功能需求、信息架构、用户体验、交互设计、视觉设计。

2、最主要的是可以用于测试。

3、高保真原型不仅仅能让开发人员受益：清晰地看到了真正的产品说明。测试也可以受益：终于知道什么样的测试结果是正常的。市场部门也会受益：很高兴提前了解到了产品。管理层、老板也会受益：给投资商或者董事会展示的时候 原型远比ppt有用。

ps：如果说实在高保真原型代替纸质文档的缺点可能就是：

需要开发人员动点脑子想一想，有些开发人员在提供了高保真原型的时候，还要求要产品说明文档，强烈要求说文档写的我看得懂，原型我看不懂，那这名技术人员职业操守绝对有问题，或者是推脱不想工作的理由。