作为只有两年经验的产品小白，我都踩过哪些坑？思维导图

记得我最开始接触产品经理这个行业时，很迷茫，不知道该从何处下手，更不知道产品经理究竟是要做什么？核心能力是什么？甚至一度以为产品经理就应该画好产品原型，越高保真越好。

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

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

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

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

而作为产品经理，应该在绘制原型上要投入较少的时间，更多的时间和精力投入在前期的产品思考中；理清产品逻辑，让每个功能都能形成闭环，最后才会有较少的返工；也会增强团队协作的信心，提升工作效率。

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

但是这些底层的逻辑，却是最重要的——尤其是一个新产品，在第一个版本，就应该设计好这些底层逻辑，保证在未来很多个版本中不会去改动它，甚至可以持续到产品停止更新的时候。

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

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

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

所以说前期设计好产品底层的逻辑，会为后面的产品迭代工作省去很多不必要的麻烦。

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

当然能在开发过程中，遇到不清楚的问题还同你交流的问题，真是好的开发，应该好好谢谢他。

我曾经遇到的开发，真是原型或文档是什么就开发什么，遇到疑惑也不会找产品沟通——当然最后产品验收肯定过不了，可这毕竟不是开发的锅，这锅是产品背毋庸置疑了。

这只是个例，大多数时候产品和开发还是会不断进行沟通的；可是由于你没能提前想到这种情况，而在沟通中表现的一脸懵逼。而这时你若是拍脑袋给出一个解决方案，极大可能是不完善的，会让你显得更加焦虑，同时你的能力在开发心中可能要打上一个问号了。

久而久之，开发再遇到一些问题，可能就会按照他认为的直接去实现。最后会造成你在团队中渐渐的没有了话语权，而这种开发出的产品，会让你去背更多的锅。

工作中难免会遇到各种问题，这也是在正常不过了，工作的大多数时间不正是去解决这各种各样的问题吗？其实问题越早发现，反而越有利于解决。

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

就这样久而久之，很多问题都没能及时提出来，只会越积越多，突然在某一天爆发，甚至会引发很严重的后果。

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

不管大公司还是创业公司，产品评审这样的会议是必不可少的，也绝对不是走个形式或者是为产品和开发撕逼诞生的；一定是聚集了各相关人员，对产品从各个角度去提出质疑。

这也是为了规避在开发过程中少踩一些坑——能当场解决的就当场解决，解决不了的就记录下来，排出优先级逐项去落实解决。

在整个产品过程中，从设计到研发再到发版上线，产品经理就像一根线一样串联每个环节，也要像开发review代码一样，要对我们的设计进行自检。

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

竞品分析对于每个产品经理都不陌生，即使是个外行也知道竞品分析大概是怎么回事。

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

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

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

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

如果直接抄袭，甚至表里面的每个字段都要一样，一旦开发说某个字段的数据我们是没有的，那不就尴尬了？

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

一个没有话语权的产品是可悲的，或者说：一个没有话语权的产品能做好他的工作吗？

当然我们知道：产品经理并非是真正的经理，更多时候你没有权利去拍板；但是我们的工作却时常又需要去做出决策，那我们的话语权从哪里来呢？

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

如果再加上我们良好的沟通表达能力，在某些时候是完全可以去拍板执行的。

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

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

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

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

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

我便经常这样去做：该决策的我一定会去拍板，决策不了的就表明自己的观点，最后由领导去决定，而最后我一定按照最终决定的要求去执行。

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

不过话多说一句，如果你的工作只是帮助老板绘制原型，我建议是可以离职了——可能你的原型工具会越来越熟练，其他方面不会有太多的提高了，永远是个执行者兼背锅侠。

如果你的领导真的有能力并且经验丰富，我想对于刚毕业的你来说还是多听取他的建议，不要对自己太迷之自信；很可能你的想法大多数都是错误的片面的，而你的领导站的高度不一样，往往会考虑的更久远也更正确。

我并不是技术出生的产品，应该有很多同行也跟我一样，并非技术出生，也不会写代码。

因为不懂技术，也就经常被开发怼。

当然做产品也并非是要去学习写代码，况且学会写代码也并非一朝一夕，编程语言学习成本太大。

你学会html可能还要去学习css，学会css可能还要学JS，学会JS可能还要学习PHP，学会PHP可能还要了解数据库。这样延续下去，时间长短不说，等你学会了你就已经迈向了程序员的大门了。

产品经理要懂技术，是希望在提产品需求时能用开发思维去考虑，而不会出现“主题色随着手机壳的颜色而自动变化”这样的需求。

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

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

还比如：你要设计一个地址簿管理的功能，那这些地址是保存在服务端还是本地；是保存全部还是仅限于最新添加的地址才会被保存，保存时间是多久，排序如何排列等，你都要很清楚的去告诉开发。

而开发最怕的是：产品给到的需求和定义不清晰，模棱两可，开发中也只能找产品经理反复确认。

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

开发可能还要发时间向产品经理解释二者区别，甚至有的开发就直接按照自己的想法来做了。

所以说产品还是要懂一点技术的，准确说产品经理要具备开发思维，而这也是为了更好的同开发交流，在互怼的时候，不至于处于下风。

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