东东推荐：回想自己的产品经历，再对比本文作者的反思，是否有似曾相识的感觉。从0到1的过程，肯定避免不了挖坑，学会了反思总结，可以加快成长的速度。
吐槽归吐槽，冷静之下，还是要结合自身状况，深刻反思。
还记得三年前，参加pmcaff线下沙龙，听着台上牛人的分享，激起自己一腔热血，冲动从运营岗转做产品。一路走来，有过迷茫，也有成长。有幸经历产品的从0到1，从1到N。互联网是一个风险极高的行业，虽说激情四射，但是能够沉淀下来做好产品的，少之又少。这次，就历数下自己犯过的错。
经常给下游环节的小伙伴埋各种各样的坑。原型制作只给到UI主界面，弹窗、判断、交互等细节甩手丢给UI，甚至在时间紧急的情况，给个草图了事；需求说明只给到开发主流程，分支、异常、极限和特殊需求考虑不周，致使开发小伙伴频繁沟通、拉长开发时间。
明知有问题、设计不完善，硬是不深究，测试上线后漏洞百出。
一旦为小伙伴们埋下了坑，填坑可就是件苦恼的事情，不单单是责任追究的问题，更是耽搁产品进度，严重的导致返工，白忙活。
我的口头禅是用户可能是这样想的，用户想要的是这个功能...可等到功能上线，才发现，这些功能竟都是为自己设计的。经常脱口而出的需求，猜测性质巨浓，就算是通过用户调研，也会不由自主的让调研结果倾向于自己的设想。
伪需求源于对业务的不熟悉，对市场的不明确，对用户的不了解，在“快速迭代”的口号下，肆意意淫和歪曲用户的诉求；只看到表面的反馈，却挖不出用户背后的需求。产品做着做着，就越发偏离用户的目标，到最后发现，这产品完全是为自个儿做的。
下游小伙伴最讨厌的就是开发过程中，频繁的变更需求，如若考虑不周的小细节，还好处理，但往往发生的是，一个小细节牵涉到太多其他的细节，改一个动全身，致使最后上线时，已与最初设计的是两个模样。
当一个产品对需求失去控制的时候，是最失败的行为。对需求的范围、工作量、进度和团队资源等预估不足，加上来自各方加急要求的处理不当，变更可能导致灾难性的后果。
为了避免2和3的情况，就要花60%的时间在需求分析和需求设计上。同时在跟进上，灵活应对。
做产品没有不固执的，因为坚持是有理由的。但是，如果出发点就错了，那么再一味的坚持，就是空耗和徒劳。当你很难说服团队时，就应该冷静下来，思考，回到原点，找到可以支撑自己的论据，如若无法验证，就另辟蹊径，寻找新的解决方案，千万不能死磕在一个点上。
刚入产品时，很难听取团队或上级的建议，总是冲动的为自己辩解。不要试图去让别人接受你的方案，而应抱着开放的心态，积极听取各方建议，合理的采纳之，不合理的说清楚你的考虑。学会取舍，需求设计没有好坏之分，只有可行与不可行，在现行条件、资源下，只有最合适的设计方案，没有最完美的解决方案；同时，注意平衡好各方诉求。
这是我犯的最本质性的错误。在需求评审时，自己都说不出一个一二三，如何让团队相信你的这个设计，是有价值的。拿其他产品说话，是最没用的策略。
从一开始，我就身陷在功能设计上，一直未能跳出功能设计的怪圈，以为功能可以解决一切。其实更重要的是，要在一开始就要想透彻为什么要做这个需求，做了之后对用户、对运营有何价值，能达到什么样的预期。功能设计的背后，或者前提是对业务、流程、规则和相应机制的持续完善。
无效沟通，是最伤人的。从产品这个节点出发，担着承上启下的角色；沟通不到位，会害了整个链条上的小伙伴。
对上的沟通：不明白的就摆在桌面上，掰扯清楚为止，不要想着会后，我再琢磨琢磨；老板的理念，不理解，就不要先下手去做无谓的设计，至少要在老板的指引，踩在正确的点上，一步一步走对路。
对下的沟通：基于原型和需求文档，要完整的阐述你的设计方案，突出重点，强调细节，不遗漏，可拓展。
这个跟心态有关系，如果不认真对待自己负责的需求，就容易滋生应付的行为，在需求设计的时间、质量和范围上随意处理，结果可想而知：难达预期，严重的是坑了这帮好兄弟。
这个不多说了，只描述一个场景：当老板让你抄一个产品时，你不能只抄表面，要搞明白对方这么做的初衷、解决了什么问题，抄也应该是抄这个。
这个是我正在迈的坎了，往往是点面思维，简单讲就是凡事，只想一个个独立的点，没能串成面的思考；当整体考虑的时候，又不能系统的去解决问题。
这个是我的短板。我想大家都遇到过这样的公司：要么老板是传统行业，要么老板是互联网出身，前者自认为摸打滚爬多年，没有人比他更懂客户、更懂市场，后者抱着一腔热血在实打实的业务上栽了一个又一个的跟头。对业务的透彻理解，决定了你的产品是否能真正解决用户的问题。
