金香槟运营社群

作为只有两年经验的产品小白,我都踩过哪些坑?

本篇文章作者以自己的亲身经验为例,告诉大家作为一枚产品经理可能会踩到的坑,希望大家能够一起讨论学习。


本篇文章作者以自己的亲身经验为例,告诉大家作为一枚产品经理可能会踩到的坑,希望大家能够一起讨论学习。

作为只有两年经验的产品小白,我都踩过哪些坑?

前言

不知不觉已入产品坑两年有余,一直从事着B端的产品设计。

虽时间不长,但在两年的工作中,踩过一些坑,也填过一些坑,就在这样踩坑填坑的过?#35752;?#36824;是有些许进步。

本文也就这两年遇到的坑做一个整理,也是希望能对自己这一段时间的工作做一个总结。

当然由于受限于自己的经验和知识,本文定有不完善之处,也希望借此分享出来,能和同行有个更好的交流机会。

一、产品经理的核?#21738;?#21147;,并非是要原型画的好

记得我最开始接触产品经理这个行业时,很迷茫,不知道该从何处下手,更不知道产品经理究竟是要做什么?核?#21738;?#21147;是什么?#21487;?#33267;一度以为产品经理就应该画好产品原型,越高保真越好。

第一份工作在一家创业公司,当时主要是使用sketch来绘制原型。

由于这款工具的便捷性,更是沉迷于绘制高保真原?#25237;?#26080;法自拔,一度让UI很无奈——因为是创业公司,需求临时变动是家常便饭。夸张的是:我们经常接到需求,没有业务梳理,也没有需求评审,就直接开始绘制原型,最后丢给前端开发,造成延期返工的问题;或者当前版本实现成本较大,不仅浪费太多工作时间,而且需求的经常变动和需求的不合理性,会让开发情绪低落,?#38405;?#22833;去信心,必然也会?#38405;?#20170;后的工作造成很大困难。

而造成这样的问题,便是一开始接到需求后,没有对需求和业务有个很好的梳理?#25512;?#26512;;以及结合市场和当前版本对需求进行优先级排序,规划好版本计划。

更是要清楚?#22909;?#27425;的版本迭代会牵涉到哪些功能,后续迭代中是否易扩展等;甚至要绘制流程图或泳道图,来更好的阐述业务。组织相应的开发同学,对此版本的需求进行评审;最后再根据达成一致的方案,绘制相应的原型?#24049;?#32534;写文档。

而作为产品经理,应该在绘制原型上要投入较少的时间,更多的时间和精力投入在前期的产品思考中;理清产品逻辑,让每个功能都能形成闭环,最后才会有较少的返工;也会增强团?#26377;?#20316;的信心,提升工作效?#30465;?/p>

二、产品底层逻辑很重要,请不要忽视它

之前我有个习惯:在设计一个产品时,很容易把更多注意力和精力放在业务?#24076;?#32780;忽略产品的底层逻辑。如:账户体系、权限体系等。

但是这些底层的逻辑,?#35789;亲?#37325;要的——尤其是一个新产品,在第一个版本,就应该设计好这些底层逻辑,保证在未来很多个版本中不会去改动它,甚至可以?#20013;?#21040;产品停止更新的时候。

前期投入更多的精力在这一块,也是为了避免有太多坑没有考虑到,到最后一点点的改动,会影响到整个产品其他功能的改动。

比如:设计一个账户注册的功能,需要设置登录密码。

在开始设计时,就要确定好密码的长度是否有限制,支持字符的类型有哪些;如果一开始没考虑清楚,没有做出限制,后面版本你再对密码长度进行限制,那么之前用户设置的密码因为此次的限制要求的可能就无法登入?#20302;常?#20320;可能还需要其他办法来进行补救。

所?#36816;登?#26399;设计好产品底层的逻辑,会为后面的产品迭代工作省去很多不必要的麻?#22330;?/p>

三、要自己多思考,别让开发来替你做决定

平时要自己多思考产品的方方面面,尤其在跟开发交流中,尽可能给对方的是你深思熟虑后的确定答案;而不是你留下了太多的坑,在项目进行中,让开发来询问你怎么解决。

当然能在开发过?#35752;校?#36935;到不清楚的问题还同你交流的问题,真是好的开发,应该好好谢谢他。

我曾经遇到的开发,真是原型或文档是什么就开发什么,遇到疑惑也不会找产品?#20302;ā?#24403;然最后产品验收肯定过不了,可这毕竟不是开发的锅,这锅是产品背毋庸置疑了。

这只是个例,大多数时候产品和开发还是会不断进行?#20302;?#30340;;可是由于你没能提前想到这种情况,而在?#20302;?#20013;表现的一脸懵逼。而这时你若是?#21738;?#34955;给出一个解决方案,极大可能是不完善的,会让你显得更加焦?#29301;?#21516;时你的能力在开发心中可能要打上一个问号了。

?#26522;?#20037;之,开发再遇到一些问题,可能就会按?#36134;?#35748;为的直接去实现。最后会造成你在团队中渐渐的没有了话语权,而这种开发出的产品,会让你去背更多的锅。

四、遇到问题不要藏着,尽早提出来

工作?#24515;?#20813;会遇到各种问题,这也是在正常不过了,工作的大多数时间不正是去解决这各种各样的问题吗?其实问题越早发现,反而越有利于解决。

我想这一点我们都很清楚,但我们实际工作中有时并非会这样去做。

  1. 可能是因为自己一开始的疏忽没能考虑到,过?#35752;性?#21457;现,提出来可能就会被批?#26469;蛄常?#29978;至会影响到绩效?#24049;耍?#20110;是我们决定对发现的问题视而不见;
  2. 也有可能是因为我们的领导不仅很严厉而?#19968;?#19968;意孤行,每?#25991;?#25552;出的建议,往往是先批评一番,于是你此次发现问题不管?#29616;?#19982;否,你都选择默不出声;
  3. 也有可能这个问题事不关己,锅也无需你?#24120;?#29978;至提出来可能还会得罪同事,就显得得不偿失了。

就这样?#26522;?#20037;之,很多问题都没能及时提出来,只会?#20132;?#36234;多,突然在某一天爆发,甚至会引发很?#29616;?#30340;后果。

比如涉及到整个产品的架构要调整;比如某一个业务流程要重新设计;甚至在产品还没有发版本,就需要修改需求,这也便成了费工费时并且打击团队成员信心的一件事情。

不管大公司还是创业公司,产品评审这样的会议是必不可少的,也绝对不?#20146;?#20010;?#38382;交?#32773;是为产品和开发撕逼诞生的;一定是聚集了各相关人?#20445;?#23545;产品从各个角度去提出质疑。

这也是为了规避在开发过?#35752;?#23569;踩一些坑——能当场解决的就当场解决,解决不了的就记录下来,排出优先级逐项去落?#21040;?#20915;。

在整个产品过?#35752;校?#20174;设计到研发再到发版上线,产品经理就像一根线一样串联每个?#26041;冢?#20063;要像开发review代码一样,要对我们的设计进行自检。

可能当初比较好的设计,现在已不适用了;去发现和收集需要改进优化的问题,排出优先级,并再次组织相应人员组织评审,最后落实下去。

五、千万别说“别的产品就是这样的”

竞品分析对于每个产品经理都不陌生,?#35789;?#26159;个外行也知道竞品分析大概是怎么回事。

记得我刚毕业工作那会,设计第一个产品时,当初也是在竞品分析后,有些功能的设计参考?#21496;?#21697;。在写PRD时,由于对自己不是很自信,于是我傻不拉几在文档?#34892;?#36947;“在参考某某竞品后,得到…”。内部评审时,老大看到我这样的描述,评审都没有继续进行,而直接打回去让我重新整理。

也因为这件事情让我明白了:不管是否有真的参考某些竞品,还是在跟开发?#20302;?#26102;,一定不要说“某某竞品也是这样做的”——此话一出,足以表明你的不自信。因为你对自己的产品还未真正的理解,还停留在别人有什?#27492;?#20197;我们也必须也要有什么的阶段。

当我们还未能真正了解自己的产品,只是?#30475;?#30340;去抄袭,那么我们在受到质疑时,必然会被开发和设计怼。

?#35789;?#25105;们是要做竞品分析,也要先理解透别人的产品定位及背后的逻辑,再根据我们的产品,设计出符合我们产品的功能。

如果直接抄袭,甚至表里面的每个字段都要一样,一旦开发?#30340;?#20010;字段的数据我们是没有的,那不就?#38480;?#20102;?

所以一定要理解透彻了先,再开始设计。

六、没有了话语权的产品

一个没有话语权的产品是可悲的,或者说:一个没有话语权的产品能做好他的工作吗?

当然我们知道:产品经理并非是真正的经理,更多时候你没有权利去拍板;但是我们的工作?#35789;?#24120;?#20013;?#35201;去做出决策,那我们的话语权从哪里来呢?

这便需要我们在工作中证明自己的能力,并且可以得到开发、运营、设计和?#20064;?#20204;的信任,从而才能为我们争取到更多的话语权。

如果再?#30001;?#25105;们?#24049;?#30340;?#20302;?#34920;达能力,在某些时候是完全可以去拍板执行的。

信任其实就像是金字塔一样慢慢积累起来的,一旦某些决策失误也会造成我们彼此建立的信任会?#28010;?#22240;此及其考验我们的产品决策能力,不过话说回来,产品不就是这样一步一步成长起来的吗?

其实在真正的工作中,没有话语权的产品还是蛮多的。

有的产品经理只是负责绘制原型,帮助?#20064;?#23436;善想法,所有都需要按照?#20064;?#30340;要求来;有的是刚毕业工作,还没有太多的经验,如果又遇到比较强势的老大,那很可能作为小白的你是没有太多话语权的。那我们?#36855;?#20040;去打破这个瓶颈呢?

其实我们的工作方式很多时候也是跟我们本身的?#24895;?#26159;极其相关的,每个人都会善于利用自己最熟悉的方式去工作。

如果你是那种死磕到底的人,那你就坚持自己的想法,抱着大不了被离职的想法去工作;如果你是那种本身内向的人,能够接受当前的环?#24120;?#37027;就做好一个执行者——当然你也可以准确的把握时机,合理清晰的阐述我们的观点,但?#20146;?#21518;的决策是由交由我们的领队去决定。

我便经常这样去做:该决策的我一定会去拍板,决策不了的就表明自己的观点,最后由领导去决定,而最后我一定按照最终决定的要求去执?#23567;?/p>

谁让产品经理本身也是打工的呢!拿钱办事而已。

不过话多说一句,如果你的工作只?#21069;?#21161;?#20064;?#32472;制原型,我建议是可以离职了——可能你的原型工具会越来越熟练,其他方面不会有太多的提高了,永远是个执行者兼背锅侠。

如果你的领导真的有能力并且经验丰富,我想对于刚毕业的你?#27492;?#36824;是多听取他的建议,不要对自己太迷之自信;很可能你的想法大多数都是错误的片面的,而你的领导站的高度不一样,往往会考虑的更?#36855;?#20063;更正确。

七、做产品还是要懂一点?#38469;?#30340;

我并不是?#38469;?#20986;生的产品,应该有很多同行也跟我一样,并非?#38469;?#20986;生,也不会?#21019;?#30721;。

因为不懂?#38469;酰?#20063;就经常被开发怼。

当然做产品也并非是要去学习?#21019;?#30721;,况且学会?#21019;?#30721;也并非一朝一夕,编程语言学习成本太大。

你学会html可能还要去学习css,学会css可能还要学JS,学会JS可能还要学习PHP,学会PHP可能还要了解数据库。这样?#26377;?#19979;去,时间长短不说,等你学会了你就已经迈向了程序员的大门了。

产品经理要懂?#38469;酰?#26159;希望在提产品需求时能用开发思维去考?#29301;?#32780;不会出现“主题色随着?#21482;?#22771;的颜色而自动变化”这样的需求。

那么,开发思维在实际产品设计中怎样应用呢?

比如你要负责微信公众号的开发,你就要先搞清楚微信开放的接口是否支持你想要的功能;每个字段参数又是指代什么,数据是从哪里来?

还比如:你要设计一个地址?#31455;?#29702;的功能,那这些地址是保存在服务端还是本地;是保存全部还?#22681;?#38480;于最新添加的地址才会被保存,保存时间是多?#33579;?#25490;序如何排列等,你都要很清楚的去告诉开发。

而开发最怕的是:产品给到的需求?#25237;?#20041;不清晰,模棱两可,开发中也只能找产品经理反复确认。

很多时候没有带着开发思维去考虑需求,产品经理可能就是说要保存地址,但为啥要区别保存在本地还是服务端?产品经理就没有去深入考虑。

开发可能还要发时间向产品经理解?#25237;?#32773;区别,甚至有的开发就直接按照自己的想法来做了。

所?#36816;?#20135;品还是要懂一点?#38469;?#30340;,准确说产品经理要具备开发思维,而这也是为了更好的同开发交流,在互怼的时候,不至于处于下风。

产品经理是个需要不断学习的岗位,在发展这么快的一个行业,原地踏步就等同于退步,也是希望自己在学习新知识的时候,也能够定期对工作做个总结。也希望能跟同行非同行的朋友有个交流互相学习的机会,谢谢!

 

本文由 @?小火柴大男孩 原创发布。未经许可,禁止转载

题图来自 Unsplash ,基于 CC0 协议

原创文章,作者:金香槟运营,如若转载,请注明出处:http://www.ptffy.club/47776.html

征服者入侵APP下载