做有灵魂的产品经理，不能只是知其然，不知其所以然。做一个打字员，传声筒式的产品经理，这不是产品经理。产品经理也是有灵魂的。产品经理是研发队伍中最主要的岗位。产品的质量和产品的进度，最能直接的影响是产品经理。你不能觉得进度，而是开发的事儿，质量是测试的事儿，这是不对的。比如说产品的质量产品经理，假如你不知道透彻的，详细的业务。比如说，我们最近搞的车购税申报的需求，二手车是不是需要交车购税？那么二手车的车购税的申报方式是什么？和新车是否一样？在金三里边儿使用的模块和新购置的汽车有没有区别？是否了解？如果你不了解，那么开发的他不会考虑二手车的事儿。那将来用户使用车购税申报这个功能的时候，那时候在用终端的时候填入车，用咱们的功能申报二手车的车购税会产生什么样的后果？这个是不可以预知的，项目风险很高。再就是，在金三里边儿，如果产品经理都不知道应该怎么申报？应该怎么作废？应该怎么查？那么让开发的去了解这些吗？测试人员测试的时候再去了解一遍？运维人员再去了解一遍？反之，假如产品经理在需求整理阶段，已经把车购税的申报业务了解的很透彻，已经在金三等生产系统，把相关的功能都操作了一遍，同时把取得的经验的总结，然后转交给开发给大家进行讲解培训，那么开发在开发阶段。是不是可以很轻易的找到测试数据，而不是像现在这样盲写代码？开发能及时找到测试数据，是不是可以保证进度。又可以保证质量。假如说你说你们说时间紧。那可以，先把知其然不知其所以然的第一版的需求交给开发去开发。同时并行的产品经理需要去及时的了解，详细的业务，了解透彻。
再说跟测试的关系。产品经理你是对需求了解的最透彻的。是对用户的诉求感触最深的。产品经理是全职学习分析业务的。相对开发和测试来说产品经理对系统中，重点功能容易出现的错误，系统可能出现的，业务上的风险点，产品经理是最了解的。产品经理需要把这些传递给开发传递给测试，这样才能保证质量，保证进度。就是你一篇需求是50页，容易出现问题的关键的业务，那可能是一页文档就能描述清楚的，产品经理需要把这个提炼出来。如果产品经理认为只是想需求，然后进度跟产品经理是没有关系的，质量跟产品经理是没有关系的，这不是一个合格的产品经理，也做不好一个产品经理。
产品经理是做业务的。是关注重点关注业务的。是对业务了解的透彻的。那么你的产成品是什么？难道只是一个需求文档吗？应该是你对业务的分析总结。是对业务了解的经验，而这些经验需要传递给开发测试和运维人员。
