同樣，你給一個研發經理說：你設計的產品有問題！研發經理會說：怎麼可能，是你不會用吧，我們可是專業的人精心設計的，你知不知道目前主流的交互習慣和工程學？但是如果你讓研發經理自己到客戶現場，看客戶使用產品的場景——研發經理心理就會想：我艹，又傻X了，這個地方回去要改。
從溝通的角度：
層層反饋註定會是失真的，各種資訊機構用爛的一張圖，再次秀給大家。所以到一線去，聽聽客戶真實的需求是什麼，看準目標比盲目努力，更事半功倍。
此外，專注於研發的研發經理，經常會困擾於市場方向產品經理的一個個需求：我要這麼這麼做，這個地方加個按鈕，一按就有什麼什麼效果，或者加個功能，實現什麼什麼功能。這種描述，是產品經理個人的明確要求，我要什麼，我告訴你怎麼做，你就去研發吧。實際上，客戶本身的需求，可能有很多的實現方式。而產品經理，往往因爲種種原因，選不到最好的方式，甚至選擇的實現方式，在框架上會和很多業務邏輯衝突。要相信，研發人員在自己的領域裏面都是聰明人，研發經理會找到更好的解決方案，所以，只需要把研發經理和客戶，放在一起，然後產品經理充當翻譯器和買單者就ok了。
從管理的角度：
打破山頭主義和小圈子，調崗是必須存在的事兒。
前段時間，業內一個朋友諮詢我一個問題，一個業務領域的前後兩個團隊，大家互相抱怨彼此的交付質量差，要不要建立詳細的操作手冊，檢查表，去規範兩個團隊的交付件。我回答他說：沒有必要——看起來嚴格的檢查和流程，會讓大家就事論事，區分責任歸屬，但實際上會讓兩個團隊的對立情緒越來越重，最後導致厚重的牆。我建議兩個做法：針對基層員工，開會宣導合作和互幫互助，並且自己帶頭不說抱怨的話，只做積極的事兒。如果發現有基層員工有抱怨和推諉，第一次私下談話，第二次點名批評，依次升級。如果中層管理者有抱怨，則立刻兩個人輪崗，既然你說別人做不好，那麼你自己過來做一下看看，是不是有不得已的苦衷？
華爲的輪值制度很大程度上打破了部門牆，所以與其讓研發經理一次次的抱怨一線的朝夕變化，還不如讓研發經理走到一線去，看看爲什麼會有這種現象？說不定一個技術宅，就能更好的解決了這個問題呢？
溫室裏面，培養的不僅僅是嬌嫩的花朵，也培養了嬌嫩的產品，經受不起市場的風吹雨打。
所以，尋找解決問題的真正答案吧，而答案，永遠在現場。
