首页 > 代码库 > 产品经理的四个阶段(分享会笔记)
产品经理的四个阶段(分享会笔记)
提笔画流程,上马定需求,进可稳迭代,退可跪开发。
我把产品经理分成四个阶段:
1)产品执行&用户体验
2)产品架构&技术实现
3)产品决策&产品模型
4)产品格局&社会价值
第一阶段:产品执行&用户体验
0-2岁的产品er大部分处于这个阶段,执行上面的想法,推动产品方案上线落地。这个阶段对于产品的好与坏的评判标准,基本是基于自己作为小白用户的视角。
如何避免在这个阶段被开发吐槽:
1.1 想清楚
方案idea可能是上面拍的,但方案细节是你自己定的,想清楚每一个交互细节和异常流,不要说想不全,可以拿着方案先和架构开发测试简单聊聊。
1.2 写清楚
写清楚的意思是每一个流程每一个步骤都写的条理清晰。拿一个普通的展示页面来说:
1)流程说明,主流程、分支流程、异常流统统写明;
2)跳转说明:点击返回/编辑/保存/取消等,分别触发什么。弹框是怎么进入怎么消失的。toast显示几秒,
停留在当前页还是返回上一页;
3)显示规则,这个页面包含哪些元素,都是哪些字段,格式大小要求是什么,是否换行全部展示,
过长或过短怎么展示,异常输入怎么显示、空态页显示什么等等;
4)排序规则:第一排序优先级是什么,第二排序优先级是什么,正序还是倒序排列等等;
5)分页规则:一页最多展示几个,一次拉取几个。下拉还是上滑刷新,是全页刷新还是半页还是指定区域刷。
等等等等………这还只是一个普通的前端展示页面,涉及后台逻辑的细节可以写的更多。
*
建议:把评审会上被开发问住的点都记录下来,整理起来,以免下次写文档有所遗漏。同时可以多看看身边优秀的产品经理写的文档。
*
1.3 讲清楚
每次开发评审少则7、8人,多则30多人,紧张怯场一次两次可以谅解,长此以往就要反思自己。声音是否洪亮,是否照顾每个听众的反应,是否准备充分,把该强调的细节都强调了?
文档要写的条理分明,评审要讲的逻辑清晰。例如:这个页面涉及哪几个功能,需要哪些开发支持,主流程是什么,异常分支是什么,特殊的规则和要求是什么。
*
建议:自己讲完可以邀请关系好的开发复述一遍,就知道哪些地方要着重再讲一遍。另外,多观摩观摩别人是怎么评审的。
*
1.4 沟通沟通
沟是方式,通是结果。结果不对,方式肯定错误。那什么是好的沟通方式?不卑不亢。
产品经理和项目组所有人都是平等的,你不是指挥他们干活的,也不用刻意讨好。平等的意思是,发自内心的尊重,耐心聆听的理解,相处自然舒服不添乱。
刚入行时,向技术提需求也会买零食请吃饭撒娇卖萌。后来渐渐发现,最佳的“讨好方式”是成为一个靠谱的产品经理。
第二阶段:产品架构&技术实现
之前有个同事,是清华计院毕业的产品er,他曾笑言,某次提需求时,开发说实现不了,他当场指导开发怎么去写代码 = =!
听得我好生羡慕,吭哧吭哧跑去学html学python,走了不少歪路。
产品需要写代码很牛逼么?不需要。产品需要懂技术实现吗?需要。
这是两回事,一个优秀的产品经理不需要会写代码,但要清楚技术的实现方案,以及,能够从业务角度,专业的回答很多个为什么为什么。
建议:
1)每次需求评审完,技术们都会私下再碰定下接口。产品er为何不索性再拉个技术方案评审会,听下前端
客户端服务端是怎么商量确定接口,一来了解各自分工,二来了解数据流转。别觉得开发定接口和产品没
关 系,这直接关系到产品实现的交互细节。
2)大公司的产品er估计拿不到线上数据库权限,但可以私下找开发要开发环境或测试环境的数据库权限。
要了数据库权限,不是用来装逼的= =! 请看下你所负责的项目,共涉及哪些表哪些字段,这些数据的调用、流转、更新是怎么样的。
*
以上,简单来说,①看看API文档;②看看数据库表结构;③看看架构图;④听听开发讲下各系统的依赖关系。
*
第三阶段:产品决策&产品模型
这一块是我至今都没有吃透的,只谈谈自己近期的体验。
3.1 怎么确定具体功能?
1)多研究竞品和优秀的app,把appstore各个类目榜单前20名的app,都下载体验一遍。并问问自己,
这个app吸引自己的是什么?
它核心用户和场景是什么?
它的缺陷和不足是什么?
怎么优化?
产品经理如果能做到多问自己为什么,并且都能给自己一个满意的回答时,就离靠谱不远了。
2)多和一线业务人员沟通,最好能亲身体验几天。例如做客服系统的和客服聊,做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就业机会,淘宝推动零售业、流通业、制造业的巨变并催生各类新行业,这就是一个产品对社会的价值。
产品经理的四个阶段(分享会笔记)