作者将产品之路分为四个阶段，并对各个阶段做了详细的说明。如果我们把产品之路比作升级打怪，那么你现在在哪个阶段战斗着？
0-2岁的产品er大部分处于这个阶段，执行上面的想法，推动产品方案上线落地。这个阶段对于产品的好与坏的评判标准，基本是基于自己作为小白用户的视角。
如何避免在这个阶段被开发吐槽：
1.1 想清楚
方案idea可能是上面拍的，但方案细节是你自己定的，想清楚每一个交互细节和异常流，不要说想不全，可以拿着方案先和架构开发测试简单聊聊。
1.2 写清楚
写清楚的意思是每一个流程每一个步骤都写的条理清晰。拿一个普通的展示页面来说：
流程说明，主流程、分支流程、异常流统统写明；
跳转说明：点击返回/编辑/保存/取消等，分别触发什么。弹框是怎么进入怎么消失的。toast显示几秒，停留在当前页还是返回上一页；
显示规则，这个页面包含哪些元素，都是哪些字段，格式大小要求是什么，是否换行全部展示，过长或过短怎么展示，异常输入怎么显示、空态页显示什么等等；
排序规则：第一排序优先级是什么，第二排序优先级是什么，正序还是倒序排列等等；
分页规则：一页最多展示几个，一次拉取几个。下拉还是上滑刷新，是全页刷新还是半页还是指定区域刷。
等等等等………这还只是一个普通的前端展示页面，涉及后台逻辑的细节可以写的更多。建议：把评审会上被开发问住的点都记录下来，整理起来，以免下次写文档有所遗漏。同时可以多看看身边优秀的产品经理写的文档。
1.3 讲清楚
每次开发评审少则7、8人，多则30多人，紧张怯场一次两次可以谅解，长此以往就要反思自己。声音是否洪亮，是否照顾每个听众的反应，是否准备充分，把该强调的细节都强调了？文档要写的条理分明，评审要讲的逻辑清晰。例如：这个页面涉及哪几个功能，需要哪些开发支持，主流程是什么，异常分支是什么，特殊的规则和要求是什么。建议：自己讲完可以邀请关系好的开发复述一遍，就知道哪些地方要着重再讲一遍。另外，多观摩观摩别人是怎么评审的。
1.4 沟通沟通
沟是方式，通是结果。结果不对，方式肯定错误。那什么是好的沟通方式？不卑不亢。产品经理和项目组所有人都是平等的，你不是指挥他们干活的，也不用刻意讨好。平等的意思是，发自内心的尊重，耐心聆听的理解，相处自然舒服不添乱。
刚入行时，向技术提需求也会买零食请吃饭撒娇卖萌。后来渐渐发现，最佳的“讨好方式”是成为一个靠谱的产品经理。
之前有个同事，是清华计院毕业的产品er，他曾笑言，某次提需求时，开发说实现不了，他当场指导开发怎么去写代码 = =！
听得我好生羡慕，吭哧吭哧跑去学html学python，走了不少歪路。
产品需要写代码很牛逼么？不需要。产品需要懂技术实现吗？需要。
这是两回事，一个优秀的产品经理不需要会写代码，但要清楚技术的实现方案，以及，能够从业务角度，专业的回答很多个为什么为什么。
建议：
每次需求评审完，技术们都会私下再碰定下接口。产品er为何不索性再拉个技术方案评审会，听下前端客户端服务端是怎么商量确定接口，一来了解各自分工，二来了解数据流转。别觉得开发定接口和产品没关系，这直接关系到产品实现的交互细节。
大公司的产品er估计拿不到线上数据库权限，但可以私下找开发要开发环境或测试环境的数据库权限。要了数据库权限，不是用来装逼的= =！ 请看下你所负责的项目，共涉及哪些表哪些字段，这些数据的调用、流转、更新是怎么样的。
以上，简单来说：看看API文档；看看数据库表结构；看看架构图；听听开发讲下各系统的依赖关系。
这一块是我至今都没有吃透的，只谈谈自己近期的体验。
3.1 怎么确定具体功能？
多研究竞品和优秀的app，把appstore各个类目榜单前20名的app，都下载体验一遍。并问问自己，这个app吸引自己的是什么？它核心用户和场景是什么？它的缺陷和不足是什么？怎么优化？产品经理如果能做到多问自己为什么，并且都能给自己一个满意的回答时，就离靠谱不远了。
多和一线业务人员沟通，最好能亲身体验几天。例如做客服系统的和客服聊，做O2O业务的和运营、销售、B端合作方聊聊。注意，聊天过程，他们经常会习惯说“我要XXX功能”，产品经理要做的是引导他们说出他们背后实际碰到的问题，去想方法解决他们的问题，而不是去执行他们提出的功能。
3.2 怎么做产品决策？
通过优先级去决策，如何判断需求的优先级？用成本收益比去衡量。就是这么简单粗暴。一个需求上线后能产生多大价值，完成这个需求需要多大的成本。成熟期的前端型产品优先级可能会根据运营的阶段和规划，即使是运营的规划，也是这次运营活动能带来多少数据，而数据就能折算成收益，上线运营活动的人力时间就是成本。
3.3 什么是产品模型？
我在上一家公司时，只做线上产品，纯前端体验型产品，我那时候觉得，项目成功的决定性因素就是“产品做得好”。后来我跳槽来了现在这家公司，开始接触O2O业务，我忽然发现，项目成功的决定性因素是“产品运营做得好”。现在，这个O2O业务已经上线跑了一阵，数据不是很好，我才意识到，项目成功的决定因素是“产品模型要搭建得好”。什么是产品模型？我很赞同纯银v的一个理论：产品模型=商业模式+产品架构+运营体系。
怎么理解？每个项目在上线之前，它会死还是活，它生命周期的上限，盈利能力的上限，产品数据的上限，基本都已经敲定了。产品运营最多只能优化到无限接近于这个上限的理论值，除非市场发生突变或新技术产生，否则绝无可能超过这个上限理论值。而这个上限理论值就是由项目的商业模式决定的。
再举个更具体的例子，同事之前创业做过一个项目，是智能硬件，关于儿童体温计。上线3个月销量过万，毛利润算20*1w*4=80w/年。单个硬件20元利润算不错了，销售数据对于新产品来说也不错了，但一年80w足够么？完全无法cover产品研发以及后期迭代和维护的成本。毛利润80w/年，按净利润算，一年就要负几百万了。
而他们团队的目标是一年净利润5000w，即使这个智能硬件的工业设计多棒，对应的APP使用体验多好，运营多用心，这个5000w的目标能达成吗？按照目前这个细分市场对于儿童体温计的需求强度和频次，是绝对不可能达成5000w/年的净利润。不算研发销售等人力成本、办公成本以及渠道分成等，哪怕是5000w的毛利润，也至少要20w的月销量啊。而儿童体温计这个市场，目标用户群不超过3亿，其中城市用户大约1亿，再除去传统水银体温计、品牌体温计、各类测温仪等竞品，还有社区医院、小门诊也会拿走一部分用户。剩下的用户能支撑20w的月销量吗？再者，儿童体温计属于一锤子买卖，复购周期极长且复购率低。
小米手环也是个很好的例子。毛利薄，79元的售价几乎接近工业成本。需求强度低，核心功能是计步和睡眠，还有心率、来电提醒、闹钟等辅助功能，不算强需求。需求频次低：长期带手环超过一个月的人很少，所以小米运动APP留存低，用户粘度差。市场小，竞品和可替代产品多。所以这个产品项目永远也无法成为独角兽，甚至无法依赖自身而完成商业闭环，只能依附小米手机以及其他智能家居，成为整个棋盘里某一颗棋子，有点像是“兵”，“帅”需要时“兵”要冲锋，必要时就牺牲。
这两个例子，其实想强调的是，产品模型最核心的是商业模式，其次才是产品架构运营策略，而这个才是优秀产品经理真正的价值。
第一阶段和第二阶段，只是产品经理对用户价值的体现。第三阶段是产品经理对商业价值的体现。那第四阶段才是传说中能改变世界的产品经理，有理想有情怀有眼界有格局，手中的产品项目已经不仅仅考虑用户价值和商业价值，而更在乎它有没有产生正向的社会价值，例如滴滴改变用户出行习惯并创造300w就业机会，淘宝推动零售业、流通业、制造业的巨变并催生各类新行业，这就是一个产品对社会的价值。
