「PM只會出張嘴、改需求…」從RD抱怨文，談產品經理該做的事

從基本功開始，PM至少要明白客戶或用戶這麼做的「目的」是什麼，因為一般而言，客戶開案的大目標不會有太大的改變，但是對「怎麼實現」會有很多意見，如果雙方可以在目的，也就是「Why」方面先建立共識，其實在後續的「How」如何實現，會更容易聚焦，而且這也會扣回第一點──

你如何讓你的團隊真正了解需求，一起做出客戶需要的產品。

接著，做到盡量以可視化的方式溝通，例如提供相關範例，確保是不是客戶要的，或是畫出使用流程、大致的介面與行為，讓客戶更清楚做出來是什麼樣子。

不然很容易變成「客戶心中的xxx」、「PM心中的xxx」和「RD心中的xxx」完全不一樣的結果（不過誤解還是不可避免，這只是盡量減少「人禍」的可能性）。

（延伸閱讀：新創公司的協作PRO法則：當再努力也不能確保完全理解對方想法，所有人都需要「過度溝通」）

當然，PM也要想辦法讓客戶「畫押」，並讓對方知道修改可能需要負擔額外成本，或是增加工時，讓對方理解他們的修改，也是要付出對應的代價的，讓對方的利益和己方一致，往「盡量一開始就釐清需求，不要太多修改」前進。

更厲害的PM會「嗅得出來」哪些地方可能有風險，例如聽到客戶需求講得不太清楚，或是數據不太合理、動機不太合理，或者他是也是轉自第三方（或老闆）的消息或說法，就會有很大的機會，後續有新的資訊跳出來而變動。

根據PM嗅出來的「異味」，他會在問題還沒發生時就盡量避免。例如，可以想辦法約到對方老闆，直接溝通需求，不要透過傳聲筒，或者是在討論初期，針對需求提出多種可能實現的proposal，用結果去逼近對方的真正需求。

抱怨３：PM都不懂技術

PM其實會覺得不太公平，技術以及程式怎麼寫，一定是RD最會呀！不過我發現即使是懂技術的PM，還是會被RD嘴不懂，所以我最後已經放寬心了，只要不是寫code的人，會需要RD解釋邏輯的，大概都會被嘴吧！（RD不要戰我><）

不過PM還是有些基本的觀念與認知需要弄懂，不需要會寫程式，但是重點是關於產品設計的know-how：