专栏名称: 91产品
91产品致力为产品新人、产品经理等广大产品爱好者打造一个全方位的学习交流平台,分享产品设计、交互设计、产品运营干货。
目录
相关文章推荐
人人都是产品经理  ·  先用后付,专坑用户? ·  2 天前  
人人都是产品经理  ·  没有产品经验,求职产品被拒N次,我终于上岸了! ·  1 周前  
51好读  ›  专栏  ›  91产品

我是如何避免制造“产品事故”的

91产品  · 公众号  · 产品  · 2017-07-29 21:06

正文


91运营社群招募中,勾搭小编微信号:lizheng-2017入社群

  • 每周91公开课,91风暴,全员参与,实际案例实际分析

  • 问题答疑,你提问题我解答

  • 行业专场,互联网金融,电商,新媒体运营等专场

  • 各地分站交流

  • 资源及人脉共享

  • 其他的。。。。

欢迎各行业互联网运营达人加入我们91运营大家庭,会运营的人都来这里了!

导读:在不长的产品生涯中,也曾遇到过大大小小的“产品事故”,下面将分享一段经历,以及在这件事情上自己的一些思考给大家。

正文

对于一家互联网企业来讲,服务器并发未处理好导致宕机,那属于“技术事故”,商城首页的商品和价格对应不上,那属于“运营事故”,错误的执行了错误的产品设计,造成用户流失,那属于“产品事故”。


在我不长的产品生涯中,也曾遇到过大大小小的“产品事故”,下面我将分享一段经历,以及在这件事情上自己的一些思考给大家。


我经历过的“产品事故”


2015年,我在腾讯旗下某2B软件的代理公司做CRM,当时是个小研发团队,加上项目经理18个人。


项目经理是腾讯下来的,高度提倡敏捷开发,一周一个小迭代,两周一个大迭代,通常是上一个迭代内容刚测试完成,下一个迭代内容就开始宣讲了,团队的研发人员一直处于工作量饱和,节奏快得工作状态。


正式在这种开发背景下,促成了一次严重的事故,当时那个需求的重要性很高,所以是产品总监牵头负责的。


我们的需求评审通常是各部门Leader一起参加,该需求最初是Boss直接提出的,在评审的时候发现产品功能与期望的需求有偏差,因此产生了严重分歧。


进一步导致技术实现上也产生争论,10个人参加的需求评审,出现了10种不同的声音。


那段时间开了无数次的碰头会,搞得大家都很精疲力尽,所以到最后也没有出现一个“大家一致认可”的方案出现,感觉总有漏洞,但是时间紧迫,没办法只能“跟着感觉走”让开发做了一个心里没谱的版本上线。


刚上线一天,大量数据涌入,严重的缺陷瞬间暴露,造成公司那一天的退款订单比平时一个月都还多。


Boss大发雷霆,产品总监事后主动辞职。


这次事故让我明白了什么?


首先要说服自己


我对PRD文档的理解,其实里面的内容是给自己看的,写的过程其实是,帮助自己梳理思路的过程。


一个PRD文档,上午写完趁热看,感觉很完美,下午再来看一遍,就会发现问题。


一个点,也许会被自己推翻很多次,只有当自己也推翻不了自己的时候,才说明那个点已经可以曝光给其他人了。


自己还没想清楚,就别拉着大家开会


开会的目的无非就是向一群人详细的表达自己的想法,或联合一群人来头脑风暴,需求评审会议明显属于前者,别把评审会开成了”大家来帮你思考的讨论会”。


频繁交流


产品经理是“无冕之王”,我们是没有实权但是又可以是站在公司最耀眼的地方的人,我们能驱动公司的资源来帮助落地我们脑子里的想法,靠的不光是思考,还有沟通。



“思考再多,不说出来等于不思考。”



持续跟踪


需求交付给设计和开发以后,应该持续跟踪,以保证实现的方式跟需求是吻合的。


人与人之间交流,内容传递是一个衰减的过程,你想的和你说的,以及对方听到的,可能内容都不一样。


那么,该如何避免制造事故的?


需求采集阶段


需求一定是采集来的,而不是自己凭着主观意识和想当然的同理心去设想出来的,采集需求一定要客观,只有客观才能最贴近真实需求,只有贴近真实需求,才能保证接下来的工作路线是正确的。


运营部反馈了一个问题:



用户觉得这个地方字太小,内容又多,操作起来很麻烦,看久了眼睛又花又累。



如果单纯听取运营部的想法,以及主观思考来分析,很容易“误入歧途”的认为,只要“通过优化UI清爽界面,或把一个页面的功能拆分为两个页面来完成” 就能解决用户这个需求。


其实只有去拜访用户,面对面交流,观察以后,才会发现用户的真实需求为:在Web端上开发出这个功能,因为能用电脑操作,屏幕大。


如果把产品经理的工作看作是修路,终点是“满足用户需求”,那么需求采集阶段就是修路的第一段,我们的理解和看法,产生的思考结果,将决定这条路的方向。


思考实现的方法,实现的路径,实现的难度,资源的分配,就如盘上公路一半,S型的蜿蜒盘旋,绕过一个又一个的“雷区”。


只有思考的越透彻,那后面的杂音才会越小,落地的速度才会最快。


分析与设计阶段


需求分析与设计,是产品工作中很重要的一部分,这里产出的内容,将决定公司接下来的营销、运营、研发等资源的调配与消耗,所以需求分析一定要谨慎,产品设计一定要匹配。


  1. 学会频繁的梳理自己的PRD文档,也许每过一遍,就会修复一些逻辑缺陷,或者产生更好的想法来调优方案。

  2. 拿捏不准的和概念模糊的,学会请教相关的人,描述想法给他人,以验证对方案的设想是否正确,只有得到验证才好大胆的去实现。

  3. 对自己批判性思考,学会问自己“首先是这是不是真实需求,其次是这样解决的可行性如何?最后是这种解决方案在逻辑上是否合理”。

  4. 开需求评审会以前,尽量先跟参会的关键人员们通通气,分歧和不统一的意见,尽量放到台下来解决,减少会议上的杂音。


今年年初,我牵头负责了我们产品“钱包”功能的重构设计,以下是这期间我的大致工作流程:


如果前期我“听风就是雨”,做的验证不够就拿到台面上来宣讲,那么带来的结果:


  • 可能与财务系统有冲突。

  • 可能技术实现有困难。

  • 可能不符合公司运营方案的策略。

  • 产品思路有问题,缺陷明显。

  • 上线后问题暴露,伤害用户,造成损失。


作为产品的第一负责人,只有严谨的做事方式去避免出现“产品事故”,才能有机会站在台上,被众人所注目,被聚光灯所照亮。


如果只能做螺丝钉,也要做一颗有思想的螺丝钉。


本文由 @Palowlto 原创发布于人人都是产品经理。


据说,只有打赏的才是真粉丝哦,8块8请小编喝杯咖啡吧,长按二维码勾搭小编微信(lizheng-2017)加入91运营社群,全年100多场免费公开课,定期问题答疑等着你,会运营的人都在这里了!

欢迎关注91运营网旗下垂直账号:


91产品:(微信ID:chanpin91)

致力于为产品新人、产品经理等广大产品爱好者打造一个全方位的学习交流平台,分享产品设计、交互设计、产品运营干货。    


91运营网:(微信ID:yunying-91)

专注于互联网产品运营干货,聚焦互联网产品策划,电子商务,网络营销,移动互联网,融资创业等领域经验分享。