坑一：“我觉得…”
内心戏： 我觉得页面上这点小改动（合理需求）不会影响到用户正常使用的…因为绝大多数用户使用移动应用都比较熟练。 就算少部分用户留意到这个小改动，只要摸索一下就知道如何使用了。结局：然后然后它就上线了。上线后，不少用户打客服咨询此问题，客服邮件给技术部排查问题，领导都被惊动了… 总结： 此坑暴露出两个问题：没有需求评审、客服不知情
- 即使不会影响到产品主流程的细小改动，也要进行内部的需求评审。这里评审可以是一个人，也可以是多个人。目的是确定此需求实现方案是否合理。上述的问题虽然是个小改动，本以为不会有多大影响，但事与愿违。所以仅根据自己主观的判断方案的可行性，这种需求评审的方式太过于草率。
- 细小改动的内容未通知客服，这个不符合功能发布的正常流程。如果客服知情的话，那么至少在用户反馈时，客服能第一时间告知用户具体操作方法，安抚用户情绪。这样既可以减少用户不满情绪，又能降低排查问题的成本。
坑二：“没问题…”
情景还原： 我：这个需求这个月能完成上线吗？ 开发大神：没问题，这个月肯定可以上线的。 内心戏： 开发小哥哥技术实力杠杠的，他说没问题的，这个月可以上线的。那后面我就不操心这个事了。结局：月底就这么到来了，开发小哥哥一脸悲伤的告诉我，这个需求还没做完。此时我内心是崩溃的… 总结： 此坑暴露出一个问题：没有进行项目管理
- 产品汪必备技能之一就是项目管理，而此坑不是项目管理能力不够，是根本没有进行项目管理。按理在开发过程中，产品汪应积极主动了解需求最新动向，如需求实现是否遇到难度；上线时间能否按期完成等等。只有积极主动的跟进，才能第一时间掌握项目动态，做到胸有成竹、风险可控。而不是等到上线前被动接收结果。
坑三：“做做做…”
情景还原： 运营小姐姐：前面巴拉巴拉说了一大堆，这个需求很简单的，因为有不少用户反馈没收到提示，所以只要在这个页面加个指引就可以了。 我：噢噢，那就按你的想法做做做吧。下次发布就加上。。。结局：需求评审会上我提了此需求和此实现方案，结果被喷了。。。 总结： 此坑暴露出一个问题：没有需求分析
- 由于业务部门提出的需求足够的小，以至于业务部门都给出解决方案了。而作为产品汪缺没有重视这个小需求，故而没有对这个小需求进行有效的分析。按理产品汪没有第一手接收到用户反馈的此问题，所以需要知道有多少用户反馈此问题？用户原始的说法是什么？然后分析用户的需求是否合理？如何来解决此类用户的需求？而不是根据需求大小来区别对待。对于产品汪而言，大需求、小需求都是需求，都应该按照正常的流程进行处理。
坑四：“很简单…”
情景还原： 我：这个需求很简单的，只要这样做就行的。你实现起来不难的，敲敲代码就搞定了… 开发小哥哥：……（各种争论）结局：需求被简化，差点还打起来了（此处是玩笑…哈哈哈） 总结： 此坑暴露出两个问题：沟通方式不恰当、没有技术可行性评估
- 沟通的目的应以结果为导向，而不是各种漫无目的的争论。我比较主张心平气和的和别人沟通，不要带有个人情绪，往往因为个人情绪，最后事情没解决，同事关系还很尴尬。。
- 需求分析不仅要考虑满足用户需求，还需要考虑自家技术实现的可行性。如当前的技术架构是否能支撑？技术实现是否有难度？需要付出多大的开发成本？综合之后，再给出合理的需求实现方案。
总结：
以上是自己和别人在产品路上遇到的四个“坑”。仅供参考学习，总结的内容比较浅，重在说明“坑”是什么，目的是提醒刚入行的产品汪勿入此四“坑”。 本文原创作者董小白。【转载说明】 若上述素材出现侵权，请及时联系我们删除及进行处理：8088013@qq.com
