做产品经理久了，回头来看，产品经理的成长除了离不开基础技能的成长外，更多的是要在职场中借势生长。
新人通过拿到好绩效成绩，才能获得晋升和高薪。
趁着周末时间，我想分享我在产品经理8年工作期间所犯过的那些职场错误。相比硬性技能之外，这点软实力更加重要，同时也少有人分享。
下面这些职场选择，如果你提前看了，相信你也可以避免，甚至还能省不少钱，欢迎阅读。
回过头看做产品经理的那些时间，最遗憾的、或者最大的损失就是跳槽错过了年终奖。
和许多人一样，我曾经因为新机会入职时间，就只能在年前提前离职走。不少的互联网公司会在春季前发放年终奖，但是每年跳槽时间除了金三银四就是集中在金九银十。
而如果呆着不开心，要么就等着第二年的三四月份，要么就只能今年提前走。
而我建议你，如果不赶时间，真的没有到呆不下（只是因为闲得很），真的要拿到年终奖再走，至少白嫖几个月的工资有什么不香呢？
除非说你现在手上的机会特别好，遇到了大厂或者薪资涨幅翻倍（涨薪一点），否则就别考虑了。别计算每个月多拿几千块钱，就错失那年终奖。
许多和我一样的人，在工作若干年后都会说，要是晚点走现在还能多拿几个月钱，毕竟钱真的不是那么好赚、好等的。每次工资都是一个月才发一次
在工作时候，产品经理会因为某些公司创新激励政策，参与到一些新领域、热点行业的项目孵化，而很多时候，这实际上和部门的考核没有任何关系。
而作为一个公司，每个部门都会有自己的任务目标，通过公司管理层制定年度、以及拆分到季度的任务目标，部门主管会拆分到个人或者小组领导。
而如果你参与的项目是没有纳入其部门考核的，那么就要引起注意了，因为即使做的再好，可能也只是保证一个平均绩效成绩。
所以在公司里面，越是部门考核任务相关的，里面的人员都是受到领导重视的人员加入，不积极或者与之不相关的，就不会被选进去。
在一些大厂里面，为了同事之间的关系相处。领导还会用“边缘化”的形式，将你放在非核心任务的小组里，这样保证了其他人的权益，还能够让你埋头在一个错误的方向，你也不会影响其他的工作。
所以当你参与到一个全新的项目，在经过一个季度后发现绩效并没有变好，其本身也不是公司今年的考核目标，那么就可以放弃了。
即使项目是你的心血，也别犹豫。有的产品经理会有主人翁的意思，想着能够把项目做上线或者持续运营一段时间给自己涨涨经验。
如果你有这样的想法，除非你年龄在28岁以内，否则千万不要轻易这样做，因为相比项目经验，更重要的是稳定的在公司里面有收入，以后项目至少还会有。
如果因为绩效成绩垫底，次数多了后，就会被进行淘汰甚至是取消合同。
这一点看起来好像很容易避免，因为有公司领导帮你给出任务优先级。但实际上是不少产品经理都容易走进的一个误区。
因为几乎所有的产品经理都做对自己有利的产品设计方案。
有一些业务功能比较复杂，同时对于未来求职、跳槽经历没有太多用，他们会选择性的将这类核心业务功能延后。
这里的延后不是等于瞒着老板，而是在整套设计方案的时候故意增加需求，将需求变得“复杂化”，通过增加一些通用功能，来提升自己的“experience”。
而研发中如果没有把核心功能提前做出来，把产品研发时间拉长了后就容易造成后续公司重心已经不在这个项目上了。
所以，非常容易造成自己绩效成绩差，在职场里一定要早点出成绩，
最后变成了和第二个一样的情况。
因此，在接收到了需求，产品经理应该首先先把核心功能完成，并达到成绩再说通用功能（加需求），保证自己的优良绩效成绩。
如果自己没有足够的资源，就一定不要轻易合作。
尤其是在大厂里面，产品经理为了竞争拿到好绩效成绩，都会希望自己孵化的项目尽快跑出来，得到领导更多关注获取更多资源，所以往往会在半成品事开始对接合作，甚至把合作的需求接入打乱了原有的产品研发计划。
比如，要做后台的第三方能力合作，就一定要有足够的后台开发资源，保证自己的能力是正常的，同时还能够提供给合作方业务需求的技术支持，否则结果是灾难性的。
比如曾经我们给做其他业务部门做某中台能力支持，结果实际上线后，对方的用户存在并发量要求，而我们的系统所提供的接口能力是远远不能达到的，在测试不通过后，对方对接上线后也无法给用户使用。
这就让对接没有任何意义，还浪费团队时间，也失去了别人的信任。最重要的是还让别人部门领导背锅，毕竟别人是看得上咱们能够帮助他，结果花了时间，反而没有任何帮助，还砸了自己的脚。
跨部门合作前一定要自己有足够的“实力”，保证系统能够有对接方案。不要太心急的把产品推出去曝光，这样反而会起反效果。
在拿到需求任务后，不少产品经理就直接开始埋头干原型设计和需求文档了。
这是非常错误的。
有经验的产品经理，会拿到需求后，在大脑里有初步的方案后，在原型设计之前就和对应的技术负责人讨论。
若是前端需求，则是和前端，若是后端则是给后端人员。
小程序的数据指标
比如微信小程序能够获得用户的什么信息，数据计算能不能做到实时等等相关技术实现问题，这些提前讨论好了后，再做产品设计方案，会省下不少的时间，还会减少非常产品和开发之间的矛盾。
这个就有点好理解了，即不要实打实的，甚至压缩时间来汇报研发需求。一定要给自己增加一些弹性时间，因为相比总会比实际推迟上线。所以这样预留了后，就避免自己的绩效成绩受影响，还有修复问题的时间。
有充足的时间也会让开发、设计团队工作有足够的时间进行打磨，和替换新任务，团队之间的工作也会更加和谐。
有的产品经理为了在领导面前争风吃醋，故意实打实的汇报上线时间不考虑冗余时间，导致团队氛围非常紧张。
因为这不仅会导致需求下游同事讨厌，如果项目成功没有成功，那就是里外不是人。
数据KPI也是这样的，当你达到数据指标后，下一阶段的数据指标只会要求更高。因此给团队、自己多一些冗余时间、指标、项目效果，不要一股脑的给最大值数据，要给最小值范围下的更小值，而不是最小值。
同样的还有立项时候要多要资源，也是这个原因。
-转自36氪
