进阶: 产品启示录
点击上方
阅读本文前，请您先点击本文标题下面的蓝色字体“与数据同行”再点击“关注”，这样您就可以分享一个大数据从业者的真实数据生活，独家数据观点！
在我个人工作的时间里，无论是以前经分中的一些项目，还是现在从事大数据工作后开始接触的大数据产品，对于产品经理的概念一直是模糊的，比如它的具体角色，具体职责，与项目经理的区别等等。而合作过的挂着产品经理头衔的合作伙伴却不少，有满腔热情但是毫无经验不知道怎么做产品的愣头青，有精于用户体验与设计以质量至上却忽视了项目进度的个人主义，但是更多的是中规中矩办事稳健却缺乏创意的螺钉。
Marty Cagan的《启示录》是一本献给产品经理的书，这本书有三个特点，决定了它在产品领域经典书的地位，一是经验涌现，二是点到为止，三是行云流水。这本书不仅适合一个新人去初步理解所谓“产品经理”，更适合“老产品”在对工作产生困惑和迷惘时去重复翻看。
也许很多人不爱读这本书，因为各种产品经理相关的公众号甚至国内的书籍都喜欢写一些更具体的文章，比如《产品经理面试需要注意些什么》、《如何设计一个完备的积分体系》，甚至是苏杰的《人人都是产品经理》，但《启示录》显然更加宏观和通用，就像是你的父母对你说，“你要做一个诚实勇敢的人”。
这本书还很短，短短几小时就读完了，读完却有些豁然开朗的感觉，此时写下摘要和感想，大家一起来进阶吧。
Part 1
流程
如何全面评估产品机会
产品解决什么问题？（产品价值）
为谁解决这个问题？（目标市场）
成功的机会有多大？（市场规模）
怎样判断产品成功与否？（度量指标或收益指标）
有哪些同类产品？（竞争格局）
为什么我们最适合做这个产品？（竞争优势）
时机合适吗？（市场时机）
如何把产品推向市场？（营销组合策略）
成功的必要条件是什么？（解决方案要满足什么条件）
根据以上问题，给出评估结论。（继续或放弃）
以上十问，牢记心里，虽然做产品驱动力无需十全十美，但至少要做到心中有数，比如大数据产品中就经常要考虑，为什么我们最适合做这个产品呢？数据有优势吗？
尊重却高于用户、市场需求
特约用户：如果公司不允许你直接与用户交流，或者你没有机会接触到用户，就另谋高就或放弃这个产品，的确，自信和想当然往往是失败的前奏。
市场调研：合理利用市场调研工具和方法，回答以下关键问题：
谁是目标用户？
用户会怎样使用产品？
用户能想明白怎样使用产品吗？障碍在哪里？
用户为什么选用你的产品？
用户喜欢产品的哪些特点？
用户希望如何改进产品，增加哪些功能？
虽然市场调研结果可以作为研发产品的依据和参考，但不能决定产品研发的方向，不要指望从市场调研中发现下一个FaceBook、Google、eBay。深以为然，感觉以前做项目或产品，大家都觉得只要找到需求人就可以了，似乎将调研结果简单的转换成需求甚至设计就OK了，事实上，基于此之上的产品经理的深度思考、提炼才是第一位的。
用高保真产品设计替换文档
不要再写传统的价值不高的纸质文档了，效果最好的产品说明文档，应以高保真原型为主，由它体现产品的功能需求、信息架构、用户体验、交互设计、视觉设计，为什么？
产品说明文档应该完整地描述用户体验，不只是用户需求，还包括交互和视觉设计，用户需求和用户体验不可分
产品说明文档必须准确的描述软件行为，文字的表达能力实在有限
产品说明文档的受众较广-开发、测试、客服、营销、运维、销售、管理层等等，因此产品说明文档必须以某种直观的方式告诉所有人
撰写产品说明文档过程会出现许多衍生物，比如按优先级排列、线框图、实体模型、但需要有一个主体代表产品，避免混淆不清
只有高保真产品原型才能满足要求，如今使用工具创建高保真原型既简单又快捷，没有理由不这么做，笔者以前也做过偏重客户体验的项目，比如自动化取数工具，的确返工的太多了，更关键是，高保真产品原型使得开发人员等各类角色都是直接受益者，他们终于看到了明确有效的产品说明。
由于需求调研和产品设计是相互影响的，应该同步展开，作者不提倡老式的瀑布式开发模型，产品经理先完成需求调研，然后交给交互设计师设计，其实业界已经认识到这是一种陈旧的产品开发思路，就好比很多软件开发团队已经尝到了开发与测试交叉进行的甜头，这是巨大的进步，还是少做毕其功于一役的事情。
其实如果按照直觉，也会觉得出一个原型远胜过一堆文档，但现实中往往受制于开发传统、习惯的力量、僵化的流程及对于原型设计的时间恐惧。
务必进行产品原型验证和测试
产品验证是指在正式开发产品前，验证产品说明文档描述的产品是否符合预期要求，证明产品的价值、可用性和可行性。
可行性测试：明确在现有技术条件下，能否成功开发出产品，邀请架构师和开发人员深度参与技术调研，寻找可行的方案
可用性测试：能发现原本被忽略的产品需求，需要请真实的用户来试用可用性原型，产品经理和交互设计师能从设计和使用原型中掌握大量信息，但不能代替真实用户的作用
价值测试：可用性测试重在观察用户如何设法完成必要的操作，而价值测试重在观察用户是否喜欢这些功能，是否满意功能的具体实现方式
恩，让真实用户验证产品设计，是产品经理最为重要的工作。
敏捷产品开发的原则
有一些要点，我觉得也蛮好的，特此摘录分享：
产品经理即是产品负责人（product owner），他代表了客户的需求。
使用敏捷方法绝不等于省略产品规划。产品经理仍然要明白产品的方向和目标，设定衡量产品成功与否的标准。只不过在敏捷环境里，规划周期应该适度缩短，反复迭代，采用轻量级的机会评估方法替代冗长的市场需求文档。
产品经理和设计师的工作进度应该比开发团队领先一两个迭代周期。
尽量把产品设计工作拆分成独立的部分，但也不能拆得太细，目标是设计出符合基本要求的产品。
产品经理的主要任务是定义有价值、可用的产品原型和用户故事。
让开发人员自主划分迭代周期。
产品经理和交互设计师必须出席每天的站会。
除非达到了产品经理的要求，否则不要轻易发布新版本，过度频繁更新版本会让用户感到不安。
在每次迭代完成后，产品经理应演示产品现状，以及下次迭代的产品原型，让大家看到工作成果，加深对产品的理解，增强团队对敏捷开发方法的信心。
在团队内展开敏捷培训。只有每位团队成员都真正理解敏捷方法，你才能把工作重心放在执行上，否则敏捷方法就只能停留在教条式的理论层面。
Part 2
人员
关键角色及职责
产品经理：主要职责为评估产品机会；定义要开发的产品，产品创意来源很多，但应用有人严格审核这些创意，判断是否值得采纳，一些公司称之为需求文档，这里称之为机会评估。
用户体验设计师：最关键的是交互设计师（也称为信息架构师、用户界面设计师、用户体验架构师），交互设计师负责深入理解目标用户，设计有价值的、可用的功能，以及用户导航和产品使用流程。
项目管理人员：核心任务是制定计划和跟踪进度。，可以由不同角色承担，可能是专职项目经理，也可能由开发经理兼任，甚至产品经理披挂上阵。
开发团队：负责开发产品，更多的是指为外部客户开发和维护产品的团队，为内部员工提供技术支撑的一般称为IT团队。
运维团队：运维团队保证服务正常运行，虽然可以让开发团队负责，但运维需要一系列专业技能，不建议由开发团队单独承担。
产品营销人员：负责对外发布信息、宣传产品、为拓展市场销售渠道、组织重点营销活动、促进产品销售和提供支持，有些公司让一个人同时负责产品管理和营销，两项工作差距巨大，的确不明智。
产品管理与产品营销
产品经理的工作是从细节上定义开发团队开发什么产品，市场营销的职责是对外宣传产品，两项工作天差地别。在企业内，我们常常希望市场营销人员负责收集产品需求，甚至提供一个模板，然后直接交给开发团队开发，这种方式忽略了收集详细产品需求的步骤，回避探索产品的艰难决策过程（也绕开了用户体验设计）。但实际上，这类营销人员也许能提供市场营销资源，制作数据表格，培训销售队伍，但是一旦涉及产品定义的具体工作，他们就显得无能为力了。
这个区别也让笔者豁然开朗，以前感觉有一类工作两边都没法靠，比如设计报表工具，市场人员只能提简单的需求，但大量的展现细节不可能由调研得到，而项目经理只是被动的接受需求，然后扔给开发人员直接上马，开发人员似懂非懂的开工，花了好长时间终于开发出一个界面，主管一看，只能抱怨和感慨：“好差的团队，连基本的体验都不考虑，只知道实现一个功能，我自己做算了”。曾经也有领导感慨，凡是管理分析型的项目（也可叫作奢侈品，做好了当然好，但做不好最多没人用，天也不会塌不来那种），都很难成功。
还有一个是我们似乎经常将营销的职责也赋予产品经理身上，认为产品经理最懂，项目上线后让产品经理做好宣传，到处培训，甚至还带着营销，产品经理疲于奔命，琐事一大堆，到头来产品体验和持续的改进倒放到次要地位了，以为的人员万能变成了无能，关于人员复用这个事情一定要慎重。
Part 3
传统公司的产品外包
随着移动互联网及大数据到来，很多传统公司都在转型，尝试自己进行产品的开发，这些产品与以前不同，都将面对真正的外部客户，但由于传统企业以前的开发基本外包，因此面临着非常大的抉择，在有限的自我团队人员面前，到底产品工作能否外包？怎么外包？如何解决燃眉之急？
这本书给出了答案，我认为很对，公司再困难，如果想做产品，产品经理、交互师不能外包，为什么？
深入理解用户非常费时间，需要多个项目的经验积累。
产品经理、交互设计师必须现场深度参与项目开发，从立项到产品发布。开发和测试过程中会出现各种细节问题，必须迅速作出决定。
产品的用户体验是公司的核心竞争力，必须在内部完成。
再次强调，开发人员、运维人员、视觉设计等都可以外包，但产品经理、交互设计师必须是自己的，没有也要自己培养，如果产品还涉及数据分析，那么数据分析师也不能外包，否则就是扯淡的事情。
Part 4
成功产品十规律
不能认为富有创意的产品来自偶然，成功的产品都遵循一定的规律，以下是作者总结的十条规律。
产品经理的任务是探索产品的价值、可用性、可行性。
探索（定义）产品需要产品经理、交互设计师，软件架构师通力合作。
开发人员不擅长用户体验设计，因为开发人员脑子里想的是实现模型，而用户看重的是产品的概念模型
功能（产品需求）和用户体验设计密不可分。
产品创意必须尽早地、反复地接受目标用户的试用，以便获取有效的用户体验。
为了验证产品的价值和可用性，必须尽早地、反复地请目标用户测试产品创意。
采用高保真的产品原型是全体团队成员了解用户需求和用户体验最有效的途径。
产品经理的目标是在最短的实践内把握复杂的市场/用户需求，确定产品的基本要求-价值、可用性。可行性。
一旦认定产品符合以上基本要求，它就是一个完整的概念，去掉任何因素，都不可能达到预期的结果。
Part 5
结语
读这本书的过程中不断映照自己接触过的项目，大部分时候都觉得作者讲得非常到位，中肯实在。作者在大公司呆过这么长时间，深谙大公司之病，提出了许多有用的方法，令人点头称道。
对于这样一部本应相见恨晚的作品，我却觉得恰逢时机，因为以前都是在做内部项目，面向的客户是自己的，但隐隐感觉到很多非纯生产性的项目往往做得不尽如人意，现在笔者也面临对外探索大数据产品的契机，一些困惑在这里找到了答案，特别推荐有一定工作经验的同学来读这本书。无论是管理也好、产品也好，开发也好，只要是做产品或类似产品的相关干系人，都应该知道真正牛逼的产品经理是怎样的，至少在说某产品做得不好的时候要给出实在的理由，以理服人。
实际上，产品经理的很多理念可以应用到一切涉及到客户服务和体验的领域中。
邮箱：fuyp@zj.chinamobile.com
如何访问？请关注"与数据同行" 微信公众号，点击历史文章菜单或者右上的按钮-查看历史消息
走自己的路，谈运营商数据人的坚持
中国移动进军大数据征信，一个具有旅程碑意义的事件
黑客帝国的前奏：工业大数据的崛起
大数据时代，你应该知道的生活真相（上）
数学中的“罗辑思维”
阿里金融帝国的早晨：大数据金融的逆袭
互联网广告：大数据变现的颜值担当
数据说谎的艺术
数据分析师的自我修养
艰难的抉择，阿里“小前台、大中台”的解读
用心找书，大数据的思想书籍推荐
“数据化”与“差不多”先生，浅谈数据量化决策
从“男人比女人孝顺”和“百度医疗竞价”说起，大数据需要科学和正直的品格
看上去很美, 谈谈阿里云的大数据平台「数加」
DPI大数据之战，运营商的艰难抉择
浙江移动大数据平台践行之路（上）
浙江移动大数据平台践行之路（下）
重读《大数据时代》：关于大数据的再认识
天龙八步：传统企业大数据运营的一些思考
七剑下天山，谈谈我认识的精准营销
涅槃？高效报表开发人员的五件武器
普及、开放与平台：大数据价值运营之路（上）
普及、开放与平台：大数据价值运营之路（中）
普及、开放与平台：大数据价值运营之路（下）
六把武器？谈谈DT时代的大数据资产管理（上）
六把武器？谈谈DT时代的大数据资产管理（下）