做产品的这一年里,我都踩过哪些坑?

2018年11月03日 人人都是产品经理


作者:从小吃米饭

全文共 6278 字,阅读需要 12 分钟


———— / BEGIN / ————


踏入产品坑一年有余,经验尚浅,只有微信H5和小程序C端经验,没有App和B端经验;但是笔者认为产品都是相通的——只是由于平台属性的不同,设计和运营策略也有所不同罢了。


由于毕设主题就是交互设计,于是对产品工作产生兴趣。


我毕业之后就一直在做产品工作,没有专业导师大牛带路,踩过很多坑,比如原型考虑不周,理业务流程了解不深入,导致开发出来的产品达不到预期,运营和技术也稍有抱怨,根本原因都在于自己没有屡清业务逻辑并呈现出来。


最终,在经过一年的摸索,有了一些进步,但是路途仍漫长。


由于近期的工作将告一段落,所以对这一年多的产品工作做一个总结。


由于各方面的经验都不足,必定有不完善之处。


本文仅是笔者对自己踩过的坑梳理一番,和大家共享一下。


常见问题


1. 问题考虑不周全


记得我刚开始接触产品经理这个岗位时,一度以为产品经理就是画好产品原型,能画出高保真原型的都是牛逼大神,特别崇拜。


但是,产品经理的核心能力不是画原型,而是业务逻辑能力。


我最常见的问题就是问题考虑不周全,经常有遗漏。


当初我第一次拿到需求时,也是直接开始画原型(略过了业务梳理、竞品分析和用户调研,更没有对当前版本进行优先级排序和做好版本规划)。


原型画好之后也没有需求评审就直接丢给了开发,直到验收时才发现流程不完善的地方或者开发出来的和自己设想的结果大不相同。


更夸张的是,需求临时变更也是常事(这其中也有我的问题,把控不佳)——不知道是不是创业公司都有这个毛病。


最后造成延期返工修改的后果,或者当前版本改动成本比较大,只能放到下一个版本去修改优化。


从而导致团队工作效率极低,而且由于需求经常变动和不合理性,让开发情绪波动大,为什么临近上线才来改改改,早干什么去了,这是谁的锅呢?


只能是产品的锅,最严重的后果就是对往后工作的开展造成很大困难。


小结:作为产品经理,应该在绘制原型上要投入较少的时间,更多的时间和精力投入在前期的产品思考以及底层逻辑上面问题要考虑周全。


结合需求理清产品逻辑,把各个对象之间的关系缕清,从哪里来到哪里去,让每个功能都能形成闭环,最后才会有较少的修改;做好版本规划,每个版本涉及什么功能,为后续迭代预留空间。


组织相应的开发人员,对当前版本进行评审,根据最终达成一致的想法落地成原型和文档,以防出现后期被告知需求不能实现或者实现成本过高;沟通的时候保持同理心,增强团队协作的信心,提升工作效率。


2. 没有思考地照抄竞品


竞品分析是产品经理的常规工作,竞品分析的目的是:从商业模式,迭代思路和运营策略等方面来对竞争对手做到知己知彼,从而提出针对性的策略来提高自己产品的竞争力;选取竞品可借鉴的地方,对本品做出改进等等。


但是竞品分析工作我很少做,由于在创业公司,也没人要求我去做,因为需求本身就很多,没有那么多精力去写竞品分析报告,不过我经常到各种论坛上看别人写的竞品分析,偶尔会动手写,频率不高,一般是两个月1篇。


虽说竞品分析报告没写,但是竞品还是会长期关注的。在产品设计的过程中千万不能盲目照抄,应该是基于自己思考的前提,在理解竞品定位和背后逻辑后再根据自己产品,设计出符合我们产品的功能。


记得我设计第一个产品时,某些功能和交互设计参考了竞品。在写原型PRD时,由于图方便,直接备注XX交互参考XX产品,你猜UI和开发看到这样的描述是什么反应?或许是这产品确定带脑子了?现在回头想起也是觉得自己特别傻!


比如电商商城的商品详情页的商品收藏和加入购物车两个按钮是否都要同时存在,别人家都有这2个功能,所以我们也要加上?


答案是:不一定。如果产品定位是二手电商商城,用户发布的商品一般数量都是极少,一般是1件,收藏后商品已经送出了,有可能就是白收藏了,前期可以先设计购物车功能,后面业务需要的话再加上收藏,并不是每个产品都要做成京东、淘宝那样大而全,也并不是所有公司的资源都能支撑你做很多事情,我们需要根据产品定位和业务需求来设计合适的功能,不能盲目照搬!


别人家的产品一定是出于他的业务需求和产品定位去做的,背后的逻辑和我们的一定有所不同,在你自己都没有深思熟虑的剖析出别人家产品和自家产品的差异点,以及优劣势时就直接照抄,是非常不可取的。


虽说“天下文章一大抄”,但是要有自己的思考,抄出不同才是可取的。


我非常认同一句话:


好的产品,都是有灵魂的,做产品即做人,体现的全部都是人性。


这句话伴随我工作了一年,然而刚开始做的产品并没有灵魂可言,就是画原型仅此而已。


后来我慢慢发现,无论你是不是真的参考了其他产品,在和别人沟通的过程中,一定不要说“参考XX产品”、“XX产品就是这样做的”,因为一旦说出这种话,就暴露出你的不自信以及你对业务需求理解不到位,间接说明你的能力还不到位。


3. 沟通协作问题


产品经理在工作过程中,大部分工作都涉及协作问题,和运营、设计、开发等部门都需要保持密切关系。


首先,在产品设计的过程中,需要考虑拉新、留存、促活、转化等问题,所以在开展工作之前,需要和运营沟通好需求,明确目的和意义,并不是一个人就能做好的事情。


一个功能的实现方式有很多种,目的不同,设计的方式就会有所不同。


其次,在业务需求梳理好之后,需要和开发沟通如何更好地去实现,保证各方对需求的理解都是一致的。


尤其当自己并不是非常懂技术的时候,就更应该谦虚的去咨询开发同事,最后给出最合适的原型设计给到UI和开发执行落地。


切记,一定要和开发同事及时沟通好需求,不要想当然,天真的以为只要开发按着原型做就没问题。你能保证你的原型没有任何漏洞,完美到极致吗?你能保证双方的理解都是一致的吗?


所以沟通不及时或者需求理解不一致都可能导致协作失败,最严重的后果就是后期验收的时候不断地改改改,在开发眼里就是你不断的变更需求。


对于你来说,只是换个样式、调整一下顺序或增加个字段而已,但是对于开发来讲,他们要调用不同的接口,查n个表,增加n个字段,换一种算法才能满足你当前的需求甚至是重写,于是产品同开发的撕逼大战就会开始。


以前我总是傻逼地认为市场上都能实现的功能——那肯定都是能实现的。


确实都能实现,开发还放话:只要给时间,都能实现!但是能实现的背后不代表着实现好,更不能保证流畅度和体验度都能和阿里腾讯媲美,不是每个程序员都能很牛逼,不然早去BAT了,来创业公司待着干嘛?


所以我忽略了这些,能不能做应该去和开发沟通过后再做决策,做产品首先是要考虑全局,需要考虑团队资源情况、上线时间等个种因素,要学会衡量,做取舍,在合适的时间做正确的事情。


最后,原型落地后如何有效地和UI沟通?我们应该让UI清楚地知道产品的定位,根据产品给出合适的风格,否则你让UI自行去发挥,到最后跟你预想的不符合,又得开撕。


有时候,专业的事情就要留给专业的人做,特别是配色方面,如果你不擅长视觉,就不要乱指点。


更重要的是设计规范是一定要有的(比如色值,使用场景,布局,字号大小等),避免开发完后怎么看怎么都不对劲,但是又说不出具体哪里有问题,无法标准化,后期改了又改,UI和前端同学可是会发飙的,特别是有些组件是公用的,一改就不是一个页面。


4. 身兼多职,专注度不够


由于我们是创业公司,我刚开始进入公司的时候,主要是接触运营方面的工作,帮助公众号写推文,后面帮助老大整理需求,将老大梳理好的业务逻辑和流程步步落实成原型文档。


由于人手不够,我除了做产品还做过很多事情,新媒体运营,社群运营,测试,我全都干过,就差不会写代码了。


我的CEO有一段时间一直把我归类为运营体系,因为公司没有产品部。


虽然身兼多职,我也没忘记自己的初衷,我总是和我老大强调,我可以辅助运营工作,但是我的职业规划是产品,后面我慢慢的专注于产品工作,但是前期做了很多事情,有新功能上线时,推广文章都是由我自己来写的,甚是无奈。


所以你要明确自己的目标,专注自己所想做的事情,杂事也无法阻挡你喜欢做的事,甚至会推动你成长,别人也才不会一直让你做很不属于你的事情,千万不要忘记原来的初衷,否则你在杂事中将会无法脱身。


我离职后,公司也成立了产品部,认可了产品的重要性。


做正确的事,把握主动权


学会做正确的事情,平时要自己多思考产品的方方面面,将所有的流程全部放到脑子里过N多遍,尽量保证最后拿出的原型是完善的,不要给团队埋坑。


在跟开发交流中,开发问你的问题,你都要清楚准确地回答,不能给出模棱两可的答案,更不要轻易让开发帮助你做决定。否则,在后期合作过程中,开发会容易按照他自己的想法来做,你就渐渐少了话语权,做产品要把握主动权才能推进项目。


我们公司开发前期是直接按照原型来开发的,甚至是1:1,分毫不差,这时候你要是真的由于某些流程考虑不周而导致延期返工,这就是你的失误了。


如果开发非常了解业务,这就会好办一些,他们还能给你一些反馈。所以无论何时何地都要做正确的事情,时刻主动关注开发进度,实时跟踪,不断地和开发进行沟通,才能使产品更加完善。


我之前在设计一个拼团领取免邮券的功能,自以为某些判断开发会加上,但是开发并没有加上,导致验收时需要花时间修改,本质原因还是我没能提前沟通备注好。虽然后面把坑填上了,我也是体会到了要学会做正确的事情,把握主动权。


不要以为开发清楚就不备注,除非你和他强调过这些,不然开发有时候也会忘记的,有时候忙着上线,任务重,并不是人人都能面面俱到的,要互相体谅。


及时解决问题


在产品工作中,我们会遇到各种各样的问题,发现后就要及时提出并解决,问题越早发现,解决越简单,如果一直弃之不理,后面有可能是个定时炸弹。


我们需要具备解决问题的能力而不仅仅是提问题的能力。问题的来源有很多,主要有如下:


1. 因为自己的疏忽没能考虑到,开发过程中或者验收时才发现,提出来可能会被大骂一通,但是自己的失误就要勇于承担,自己踩的坑,就算哭也要填上,这是工作态度问题。


我第一次接触UGC时,只考虑了一般用户的正常流程,而忘记了发布者本身,忽略了不同角色的商品详情页面的操作按钮需做不同判断。


那时候没有任何人指出这个问题,我是测试时才发现问题(公司没有测试,所有的测试都是我们自己来)。


于是后来我就直接告诉开发,这是我的问题导致的,修改所有bug之后麻烦帮我加上判断,所幸我态度比较好,开发帮我加上了,也及时上线了。


2. 因为上级或老板非常严格,一心坚持自己的想法,提出的建议经常被批评或者否决,于是选择默不出声,完全按着领导说的做。


如果你的目标不是做好一个执行者,而是想做决策者——你可以准确的把握时机,合理清晰的阐述自己的观点,该决策的学会拍板,决策不了的就表明自己的观点,也可以组织团队讨论给出最后决策,但是最后的决策还是在老板手里,我们说到底还是搬砖的。


但是我遇到的老板是很好的,当你可以提出比较好的方案时,他会认可你的方案并同意执行。


刚开始工作的时候,某些想法不是特别成熟,也有可能是表达能力欠缺,没有很好的将自己的想法勇敢地提出来。


在做拼团功能时,老板说在拼团页面,新用户通过分享链接进入,直接弹出新人福利弹窗,这样的流程其实是不友好的,因为这样会被分流,用户看到弹窗就会进入新人福利页面,可能到达不了拼团页面,也就达不到拼团助力的效果了。


其实可以调整为在拼团助力之后再弹出新人引导弹窗,达到拼团助力也同时起到新人引导的作用,在用户拼团助力过后还能领取额外的奖励,这个用户体验才是比较友好的。但是当时我可能是没有完全想好,所以没提出来,导致测试时发现体验度非常差,后来还是决定在下个版本进行了优化。


3. 有些问题和我们关系不大,但是为产品好的,我们都应该提出来。我们不要怕得罪同事,就事论事,不针对个人,这样做出来的产品才不会让你抑郁。


比如视觉界面设计时,我看UI怎么看怎么不顺眼,但是我在这方面并不专业,于是我去看了其他大厂的设计基本规范,一般配色都只是一个主色调,一两个辅色,而我们的颜色却过于丰富。


我没有直接质疑UI,而是把规范文档发给她之后,后来在和UI协商过后,进行了修改。


如果当时我认为那是UI的工作,不关我的事,那最后成品不佳也是有的责任,还是自己的工作不到位。


只要本心为产品好的,你愿意提出你的建议,你才是真正的产品人。


在整个产品周期里,从产品→设计→开发→上线,产品经理就担任着非常重要的角色,要实时跟进,更要对自己的产品设计进行检查。


但愿大家都能少踩坑,发现问题能马上解决的就赶紧解决了,当前版本改动太大,就记录下来放到下个版本去解决。


做产品还是要懂技术的


我是电子商务专业,学过一些基础的技术知识,但是只能勉强考试及格,实际操作还是不太懂,更不会写代码,我记得当时的html5和C#的作业考试还是从网上东拼西凑完成,很多原理都不太清楚。


我刚开始的时候甚至听不懂“打印”、“写死”这些技术黑话,因为不懂技术,我也经常被开发怼过,甚至被质疑脑洞清奇。


编程学习成本很大,但是基本的技术知识,我们一定要懂,否则在沟通交流时会很吃力,开发告诉你不能实现,你不知道为什么?


我记得当时我有一个很好笑的回答:“为什么别人就能做出来,你们却实现不了?”开发直接回怼:“那你找他们去呀,找我干啥?”


如果产品懂技术,就不会有以上对话。


为什么产品经理要懂技术?因为这样我们在提产品需求时可以有一定的同理心,能用开发思维去考虑问题,减少自以为实现很简单而频繁改需求的情况。


比如我们公司产品主要是微信小程序,我就需要搞清楚微信小程序开放的接口是否支持我想要设计的功能;兼容性是不是支持视频播放,能实现的话用户体验如何?每个字段参数代表什么,可以获取什么用户信息(地理位置,微信头像昵称、微信运动步数等),数据从哪里来?模板消息如何发送?


说实话,我一开始真的不知道小程序的formID的有效期只有7天,而且是触发一次只能发一条,导致后面开发说通过这种方法并不能保证每条消息都能发送给用户。


除此之外,还需要了解的是有什么微信组件可以为我们所用,不需要重复去设计。


比如地址可以直接调取微信地址,不需要设计,如果想提供更好的体验,可以同时提供自己设计的地址功能和调用微信地址。但是前期项目比较赶的话,可以直接用现成的即可。


另外,由于建立在第三方平台,你要时时刻刻关注微信小程序规则,例如微信分享机制有变动,不能直接获知用户是否分享完成,也无法在分享后立即获得群ID等;获取用户授权信息必须通过点击事件触发等等,这些我们都要清楚地知道。


如果这些只有开发知道,你却不知道,那在产品设计上就会不符合规则,后面则要返工修改。


这些还好,如果是产品给到开发的需求和定义不清晰,模棱两可,那才是要命的。


没有用开发思维去思考问题,停留在前端问题上而忽略了实现逻辑,脾气好的开发还会找产品经理反复确认,但是有些开发为了节省时间就会直接按照自己的想法去做。


比如你想按照状态来区分,链接是同一个,而前端有可能做成两个页面而并非按照你想的来做,这些你在前期就要和开发同学交待清楚,包括新用户的定义和其他条件定义等。


所以说产品还是要懂一些技术的,这样有利于沟通交流,更好地实现需求。


产品经理是一个极具挑战的岗位,只有你不停地学习和思考,才不会落后。尤其在互联网下半场,除了懂技术,你更要懂运营。


产品这个岗位是要为公司赚钱的,流量是运营的基础,不断地学习,才能跟上社会的步伐。


做产品的这一年里,感触颇多。产品这条路对我而言还是很漫长的,不忘初心,努力成长,希望能有和各位产品朋友有交流互相学习的机会,万分感谢!


———— / END / ————


点击“阅读原文”下载APP

收藏 已赞