作者将产品之路分为四个阶段,并对各个阶段做了详细的说明。如果我们把产品之路比作升级打怪,那么你现在在哪个阶段战斗着? 第一阶段:产品执行&用户体验 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就业机会,淘宝推动零售业、流通业、制造业的巨变并催生各类新行业,这就是一个产品对社会的价值。