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

零基础学产品,BAT产品总监带,2天线下集训+1年在线课程,全面掌握优秀产品经理必备技能。了解一下

本篇文章是笔者以自己的亲身经验为例,总结了毕业后一年做产品所踩过的坑,希望可以大家有所帮助,并且能一起讨论学习。

前言

踏入产品坑一年有余,经验尚浅,只有微信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等;获取用户授权信息必须通过点击事件触发等等,这些我们都要清楚地知道。

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

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

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

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

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

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

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

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

 

本文由 @从小吃米饭 原创发布于人人都是产品经理。未经许可,禁止转载

题图来自Unsplash,基于CC0协议

给作者打赏,鼓励TA抓紧创作!
5人打赏
评论
欢迎留言讨论~!
  1. 深有感触,不忘初心,努力成长。

    回复
  2. 请教下,有没有比较适合产品经理的技术类书籍可以推荐,相对比较浅显一点的。

    回复
  3. 作为半路出家的产品经理,并且完全不懂技术的人,我来说几句吧。
    1、看到楼主讲述的经历,自己也是略有感触,对于不懂开发技术的人来说,确实很依赖开发,所以好的开发人员,公司应该多珍惜,想办法留住人。我之前从事手机行业,现在转战物联网行业,做智能设备,接触的软件开发不仅仅是APP,还有FAE、WiFi模块开发等,每次搞都是三方联调,比做纯APP苦逼多了,任何一方出现问题都会导致所有人停工。。。之前公司用的是某外包平台公司,开发质量呵呵呵,好在现在的APP开发用的是虚拟团队,可以理解为有几个大神专门给我们做项目,实在是省心到不行,都是30K以上的月薪级别大神,我从来不需要担心技术问题,从来不需要担心开发会搞出篓子,反而他们做事得心应手,对于产品经理提出的东西,都能够理解透彻,所以说好的开发人员,对于项目开发是十分重要的。我只能说楼主前东家开发不怎么样了,不是说技术不行,也许是心态问题。为啥别人可以做,你不能做,这个问题是可以问的,开发可以说出原因,我觉得大家有什么问题都是可以沟通的,当然问的时候,也要改变下,例如为啥别家实现了这个想法,咱这边是因为什么限制,导致不能实现吗?可以这么问,毕竟开发才真正知道原因,当然他也可以忽悠你。取决于人。与开发合作,注重沟通!注重沟通!注重沟通!足够尊重!足够尊重!足够尊重!
    2、关于需求:其实并不是所有的项目都要完完全全写好BRD、MRD、PRD、DRD什么的整套,主要看实际需求,如果我只有一个星期来处理需求,我是不可能全部都写好的,需求写完之后,还得验证,我个人习惯是使用表格方式写功能需求,每个模块下有什么东西,什么功能,加上功能说明,可以写的非常清晰、明了,开发一看就知道你这个有啥东西,配合高保真原型图和交互说明,基本2个文档搞定。如果对后台了解,可以在表格中把后台需要的东西也标注上,一般后台开发喜欢看Word文档,我个人超级讨厌写Word文档,我觉得不仅浪费时间,看的还特别烦,开发都不一定看完,明明简简单单几个功能,写完之后自己都懵逼。。。我习惯原型图与功能需求同时进行,原型图可以把需求具象化,让我更好理解功能、交互、排版及使用。
    我认为需求文档是给开发看的,所以只需要写清楚你开发这款APP是为了干嘛,都有哪些东西,用于哪些场景、怎么使用、通过什么方式实现即可。还有更重要的是:便于阅读理解、便于迅速了解功能结构、方便查询。文档的作用就是为了让其他人明白你要干嘛,就是这么一回事,至于形式、格式、用什么写,都不是特别重要。
    3、关于原型图,我所搞过的项目中,无论是外包,还是自己的团队,都认为我写的需求非常详细、清晰,我是通过电子表格来列出功能的,需求其实就是多个功能的组合,来满足某个需求,用电子表格来写也没有什么问题,反而功能共容易量化,对于开发评估、外包报价都是非常方便的。
    原型图画的约详细、越清晰,开发对功能的理解就会越透彻,经验丰富的开发只需要看到你的图,就知道你想干嘛了,或者能够对需求了解七七八八了。原型图要尽可能画完整,可以不够精细,但是绝对不能少,原型图也可以把业务流程体现出来的,还有就是UI有可能因为你少画了原型,就不画漏的界面了,跟外包接触过,我深有体会,你后面想再加,就特么按照新需求,要收钱了。所以我不同意楼主说,不应该在原型图上浪费太多时间这个说法,在我自己的经历中,反而原型图带给开发的帮助非常大。我之前做过UI设计师,所以我出的原型图都是达到UI的水准,即使UI设计师没能及时完成设计,开发也可以按照我给的高保真原型进行开发,后期再更新UI,也是很方便的。
    4、身兼多职,专注不够,这个确实有影响的,我在上家公司,身兼产品、UI、交互身心疲惫。。。当然到了现在这家,也差不多。。。不过重点还是在产品这块,平时也得做做设备引导GIF图什么的,时不时还得自己修改UI设计。。。不过身兼多职也是有好处的,我相信你自己也能感受到。
    5、关于抄袭,互联网产品还好,物联网产品就比较普遍,为啥?因为APP功能都是根据硬件来定的,大家大同小异,我自己就把主要精力放在视觉、交互、用户体验上面,至于运营啥的实在接触的少。不管是什么产品,有时候为了策略,适当的也需要抄袭的,像你说的,不能盲目抄袭,这一点我是同意的,出发点不同,同样的功能,也会存在实用性不同。但是目前产品同质太严重了,有重合的功能也是很正常,正确看待这个问题即可。
    5、老生常谈,产品要不要懂技术:当然懂更好啦,我要是会敲代码,我还做个屁产品,3~5年开发工资高了去了,我朋友后台服务器开发,3年经验,24K税后工资,还是搞技术的混饭吃长久。说真的,问问自己,真的会做一辈子产品经理吗?我其实对自己也是抱着怀疑的态度的。
    懂技术可以更好的开展项目,至少你知道哪些功能可以实现,不需要再跟开发沟通,当然不懂技术就不行了吗?不是的,不懂技术就需要多跟开发沟通,我个人就很喜欢跟开发聊这些问题,虽然我不懂,但是他们也很愿意跟我聊,我认为你抱着学习、尊重的姿态去跟他们沟通,其实他们还是很乐意跟你聊得,毕竟谁不喜欢被崇拜?对吧。一个团队的工作气氛融洽,工作效率也会高很多,同样的沟通成本也会下降,沟通也会更加顺利。
    个人经验,有什么不对的,欢迎指正,希望也能告诉我正确的方式,让我有所成长。

    回复
    1. 我也和外包接触过,那个原型图还真的要写全,不写全的后果除了撕逼不说,是真的要加钱!!!!原型图花少点时间,并不是说不写全,业务逻辑梳理清楚之后会画的更快。另外由于我们都是通过原型去沟通,该写的都写得写,否则有遗漏就是自己的锅了。感谢你的分享,有一些经验深有同感🙌

      回复
    2. 以后多多交流,互相学习,哈哈

      回复
    3. 本小白看完以后~觉得很受教~很赞

      回复
    4. 大家都是互相学习啦,多分享点坑,啊哈哈

      回复
  4. 挺好

    回复