同样，你给一个研发经理说：你设计的产品有问题！研发经理会说：怎么可能，是你不会用吧，我们可是专业的人精心设计的，你知不知道目前主流的交互习惯和工程学？但是如果你让研发经理自己到客户现场，看客户使用产品的场景——研发经理心理就会想：我艹，又傻X了，这个地方回去要改。
从沟通的角度：
层层反馈注定会是失真的，各种资讯机构用烂的一张图，再次秀给大家。所以到一线去，听听客户真实的需求是什么，看准目标比盲目努力，更事半功倍。
此外，专注于研发的研发经理，经常会困扰于市场方向产品经理的一个个需求：我要这么这么做，这个地方加个按钮，一按就有什么什么效果，或者加个功能，实现什么什么功能。这种描述，是产品经理个人的明确要求，我要什么，我告诉你怎么做，你就去研发吧。实际上，客户本身的需求，可能有很多的实现方式。而产品经理，往往因为种种原因，选不到最好的方式，甚至选择的实现方式，在框架上会和很多业务逻辑冲突。要相信，研发人员在自己的领域里面都是聪明人，研发经理会找到更好的解决方案，所以，只需要把研发经理和客户，放在一起，然后产品经理充当翻译器和买单者就ok了。
从管理的角度：
打破山头主义和小圈子，调岗是必须存在的事儿。
前段时间，业内一个朋友咨询我一个问题，一个业务领域的前后两个团队，大家互相抱怨彼此的交付质量差，要不要建立详细的操作手册，检查表，去规范两个团队的交付件。我回答他说：没有必要——看起来严格的检查和流程，会让大家就事论事，区分责任归属，但实际上会让两个团队的对立情绪越来越重，最后导致厚重的墙。我建议两个做法：针对基层员工，开会宣导合作和互帮互助，并且自己带头不说抱怨的话，只做积极的事儿。如果发现有基层员工有抱怨和推诿，第一次私下谈话，第二次点名批评，依次升级。如果中层管理者有抱怨，则立刻两个人轮岗，既然你说别人做不好，那么你自己过来做一下看看，是不是有不得已的苦衷？
华为的轮值制度很大程度上打破了部门墙，所以与其让研发经理一次次的抱怨一线的朝夕变化，还不如让研发经理走到一线去，看看为什么会有这种现象？说不定一个技术宅，就能更好的解决了这个问题呢？
温室里面，培养的不仅仅是娇嫩的花朵，也培养了娇嫩的产品，经受不起市场的风吹雨打。
所以，寻找解决问题的真正答案吧，而答案，永远在现场。
