作者／Andy-pm@PMCAFF 產品經理社區原創專欄，以下為作者第一人稱描述。
世界上最可怕的人是什麼? 是老闆。誰都有老闆。但懂得和老闆打交道的產品經理才能成功。 老闆要面子，但老闆更想賺錢。顯而易見的是，你的產品不都是做給你老闆用的，所以大多數 PM 在「老闆說」之後，或者變了需求，或者偏了方向，或者改了進度，或者啥啥啥的。你要想當個成功的產品經理，學會怎麼聽從「老闆說」，或者學會怎麼與老闆打交道，是個非常重要的本領。
- 為什麼會有「老闆說」現象出現？
我個人總結了以下幾點，供參考：
1. 老闆總認為你不夠專業，覺得它比你懂的更多，所以「老闆說」—老闆自認更專業。
2. 老闆看到雛形後，總覺得這裡不好、那裡不好，所以「老闆說」—老闆得意。
3. 老闆通過周圍人群回饋，非專業的點評，直接告訴你市場好多人回饋這裡不行，那裡不好，所以「老闆說」—所謂的市場回饋。
4. 老闆想的比較多，有些老闆比較多變，某某人說下，這個覺得對，那個覺得對，然後就出現結論，所以「老闆說」—老闆善變不堅定。
5. 老闆覺得女性產品女性做會更好，如果是大老爺們做的，缺少很多，結果來了個女性相關人員，所以「老闆說—老闆認為異性無法做好相關產品。
6. 老闆希望產品能快速賺錢，產生收益，然後就指指點點，所以「老闆說」—這就是老闆。
7. 公司沒有規範制度和流程，各種工作無標準、無制度，所以「老闆說」—無流程規範難有序。
- 「老闆說」現象出現說明了什麼問題？
前期工作未做好：上線就出現一堆問題，是否沒有進行需求功能前的調查研究和分析？如果沒有，那麼已經上線了，應該找用戶群體進行溝通，然後快速改善。
PM 未發揮其作用和職責：老闆說是常態，畢竟人家是老闆，這是特權；但是 PM 是幹啥的？為什麼沒有進行協調？沒有說服老闆？計畫在哪？時間在哪？PM 需要發揮自己這塊的職責和能力來有效解決。
無標準和規範，浪費工時：說明沒有標準或者規範的產品流程和規則，那麼需要趕緊制定，否則只會讓大家繼續白費力氣。
研發前工作不可省，很重要：說明溝通、協調很重要，在研發前解決一些不必要的問題研發前的成本最小。
- 如何解決「老闆說」現象
可能大家覺得要解決「老闆說」現象，還是得多和老闆溝通、周旋。但是我不這樣認為，這種只能解決一時的問題，而無法從本質解決，我覺得要想根本解決還是要從流程規範、需求前期調研、完善的功能評審機制來解決。首先，我認為需求功能點的搜集源需要統一。
在公司中，各個階層、各個人員、各個部門、老闆都會經常提出一些想法、訴求，為了避免他們的這些想法、訴求不被遺漏、能進行有效的記錄和跟蹤，我們需要一些專案管理工具進行統一管理。例如禪道、MantisBT 等。
我們現在使用的是自己做的一個小系統，支援使用者發表自己的想法、採取投票來決定是否實現，以及在哪個版本實現，想法更改次數和時間來驗證想法的有效性。投票中包括：認可、採納、不採納。（我本人技術出身，所以直接貼表結構了，有興趣的可以看看）
其次，我認為需求功能澄清到移交到技術團隊需要有規範的流程，任何人都應該遵守。我只想強調需求功能實現在前期過程不能減少，在前期解決問題成本代價最小，下圖則反映了此現象：
目前我們需求的流程如下：
大家提出的想法記錄→提出人講解和說明→投票表決及實現版本→產品輸出原型設計→
和 UI、老闆第一次原型溝通→召集技術進行評審→修改評審結果及更新→移交技術團隊實施
這裡我重點說明和技術團隊的評審，一般我會提前 1 天發出版本的原型評審範圍及時間，然後技術相關人員填寫評審記錄，正式評審的時候針對技術提出的問題進行解答和溝通。因為一切需求功能不管你設計的再好，再完美，技術不能實現都是天方夜譚，所以功能移交技術團隊一定要達成一致。
下圖是我們需求功能技術評審的範本，供參考：
再次，我認為需求功能實現的驗證，從而保證功能被正確的實現。
這個我們在每一個功能實現完成後進行內部測試人員的測試之後，產品一定要再次測試，然後進行修復 BUG，解決 BUG 的迴圈，都解決後才正式發佈上線。按照 TDD 的思想，在需求功能移交給技術團隊的時候，這個需求功能就是一個 BUG，不斷解決到這個功能無 BUG 的時候就可以發佈了。
總之，我覺得「老闆說」現象經過規範的流程、嚴格的需求評審之後，「老闆說」也不在是萬能的了，資料、方式、流程多方面、多維度的把控，規避「老闆說」現象，讓需求功能正確的執行。
之前我發佈了一篇〈拒絕不靠譜的需求：怎樣確定需求才是正確的？〉裡面表達了我的大部分觀點，也希望大家來一起溝通和交流，杜絕「老闆說」現象，讓需求功能正確的執行，這也是我們每一個產品人員的職責和使命。
PM 少一些常規問題，讓老闆無話可說？
我想以此標題來表達我的觀點，「老闆說」現象出現既有老闆的原因，也有我們自己的原因；我總相信一句話，既然我們不能改變別人，我們只能改變自己，任何時候我們應該先從自身反省，找出自我的不足改正，提升自我實力，實現共贏。
- 一些 PM 的常見的問題
想當然
這個是 PM 經常所犯的最大錯誤了。我們接到一個需求，我們想了想，然後就認為自己想的是對的。因為我們用過很多同類產品，想過很多類似的事情，等等。我們也想去做市場調查，但漫長而經常不靠譜的市調結果，往往讓我們更加不知所措。所以我們反思：除了想當然我們還能幹嘛? 也就只能想當然了。
為了不讓自己想當然，我們找目標使用者聽取需求，我們繪製使用者模型，我們頭腦風暴，我們力爭讓自己的每一步都顯得比較靠譜，希望最終的結果證明我們不是在想當然。唉，我們不容易啊。 當然，我們都不想想當然。如何去除在項目初期的想當然成份，就是 PM 的巨大課題。
溝通不足
產品經理，作為一款產品的精神領袖，我們需要把我們的想法，讓團隊中的每一個人都清清楚楚明明了了。這時，溝通顯得極為重要。你做投影片、寫文件、文件中圖文並茂還配影音 ; 你一而再再而三地開會，你每時每刻都在強調產品的核心功能與特色功能。但你無數次悲哀地發現：漏斗原理絕對是特麼的真理。甚至你無可奈何地想起存在主義的信條：他人即地獄。 是的，沒有人能完全瞭解另一個人。
幸好，做一款優秀的產品不需要完完全全瞭解你 Team 中所有人。溝通本身是有很多技巧的，每個人都可以學會。 呃，其實溝通有件法寶。那就是，永遠不要覺得自己牛逼而別人傻了吧。傾聽一直比表達重要。
忽視原型
我傾向於任何產品，都需要有原型階段。原型階段是個思維和驗證階段。最近兩三年的經驗是，我們大家都知道做原型，但原型並沒有發揮出真正的用途，沒有讓我們發現產品中潛在的問題。每當這時，我就無比崇拜那些獨創出遊戲的人如宮本茂、Sid Meier、Peter Molyneux 等人。只有好的、徹底的、令人興奮的原型，才能讓他們成就萬千玩家的歡樂。 原型不是用來交差的啊。
需求變更
人無完人，我們更不可能強求每個人都是偉人。所以，我們也有犯錯的時候。我們經常會發現自己想錯了，我們需要改變原來的需求。但是，在原型階段之後步入實施，也就是思考階段完畢進入構造階段，需求真的已經不是我們一個人的事兒了，你這一拍腦袋，設計師、前端、後端、UE 都得跟著你變啊。
據不完全統計，所有失敗的產品，60% 的原因是需求變更太頻繁導致實施人員心灰意冷無以為繼。 做產品跟建房子真的就是一回事。當你畫完建築圖紙，然後開始施工了。這時你想把衛生間從東移到西把書房從南移到北，嘿，還真不是件簡單的事情。 當然不是說不能變。我相信認真負責的產品經理，需求越變更未來產品會越好。但不能太隨意了。
對 PM 來說，有一種災難，叫「老闆說」
老闆說不喜歡紅色。老闆說這產品是給老年人用的。老闆說登錄框放到左邊很醒目… 世界上最可怕的人是什麼? 是老闆。誰都有老闆。但懂得和老闆打交道的產品經理才能成功。 老闆要面子，但老闆更想賺錢。顯而易見的是，你的產品不都是做給你老闆用的，所以大多數 PM 在「老闆說」之後，或者變了需求，或者偏了方向，或者改了進度，或者啥啥啥的。 你要想當個成功的 PM，學會怎麼聽從 「老闆說」，或者學會怎麼與老闆打交道，是個非常重要的本領。
未能有效地整合資源
我把所有你在專案行進過程中，所要調配的人力、物力都叫作資源。你最頭疼的肯定是人員問題了。那位工程師死活聽不懂你的話。那位設計師一直對你臭臉。而你覺得他們能力真的有問題。你想換成配合更默契的人。你得找人事經理，或者直接找老闆。你能否成功，就歸結為你的資源整合能力怎麼樣。 或者是，當你做到半道，你的產品不被大家看好，上司不願再繼續了。能否說服上司對項目進行持續投入，這也是資源整合的能力之一。 據不完全統計，所有失敗的產品，90% 的原因歸結為資源整合不到位。
可靠的項目週期
老闆總希望第二天早上醒來就發現項目已完成，開始賺錢了。產品經理希望第二天早上醒來，項目的里程碑已經圓滿。但希望不是現實，願望只是願望。大多數產品經理在既定的時間點上，看不到應該看的東西。Delay 是我們永恆的宿命。 互聯網的一些事，每當你陷入拖期的煩惱時，你該明白，你團隊中的夥伴們，誰都不希望延期，誰都知道青春無比寶貴。
PM 的精華就是資源管理，而時間是最可寶貴的資源。 如果你開始了一個新專案，那我建議你一定要把週期分得細之又細，並在每個驗證點仔細驗證。如果你的項目現在延期，不必煩惱，只要團隊中每一分子都有求勝欲望，那很快會回到正軌。
直視產品品質
絕大部分產品，尤其是互聯網類的，產品不是做完了就完了 ; 還必須在交付運營的過程中，進一步驗證、改造，提升產品的品質。 最糟糕的情況莫過於，當你的產品一上線，使用者蜂擁而至，又一哄而散。據不完全統計，80% 跳樓的產品經理都是因為這個原因。剩下的 20% 很堅強，他們頂住了壓力，從另外一個角度來反觀產品，分析資料，說服團隊積極面對快速行動，然後把用戶又感召回來了。 當然大多數產品都是上線後無人問津。
大概念上的 PM 也需要對此負責。而不幸的是，很多 PM 在這時候退縮了，不敢擔責任。遙想當年，當我的團隊承受這種壓力時，那幾個跟著我的兄弟，紛紛提出辭職，整得我仰天長笑壯懷激烈。 其實，反思我們的產品為什麼贏不來使用者，這樣的過程會讓我們成長得更快。別怕總結教訓，別怕失敗，別怕面對過去。
有效學習
很多 PM，當他們做成了一款或者兩款或者更多的產品之後，他們往往固守成功，忘記了進一步學習。即便他們認為自己是在學習，那也是在學習如何讓自己已經有的經驗成為牢不可破的教條，其實沒有比這更可怕的事情了。你想想，為何擁有那麼多優秀產品的微軟會在網路時代步履維艱?
有則你肯定聽過的寓言，關於空杯的。如果我們想一直在產品這條線上走下去，嗯，要保持有一顆空靈的心，天真而好奇，永遠不認為自己是對的，永遠做好迎接新知識新理論的準備。還有，永遠不要再說永遠!
完全避免這 9 個問題談何容易。但我們可以用來警醒自己：別再犯二了。最後，我想對各位 PM 說，「老闆說」現象並不可怕，可怕的是我們怎麼去規避此現象。作為一個 PM，我們應該學會解決問題的方法，而不是遇到問題隨波逐流，那麼你永遠無法成長。
產品的魅力在於過程，結果雖然重要，但過程的風景也是那麼迷人，我願意在產品的路上，做一枚小小的產品，也希望能遇到更多的同道，大家一起交流、成長，開心就好。
（本文轉載自《36kr》，圖片來源：kennymatic CC Licensed，未經授權請勿轉載。）
