產品經理經常需要與RD進行需求溝通，有個很有名的幽默漫畫是這樣畫的。

產品的需求，經由產品經理定義成產品規格後，開始找RD討論。而一切的錯，也就從客戶（或Product Manager）口中的需求開始。

PM：「我們要發展一種在無重力狀態下也可以使用的多功能原子筆，也就是說墨水不會因處在無重力下就無法送達筆尖。」

RD：「這個想法做不到。因為OOXX，所以XXOO」

PM：「可是之前看日本技術展的時候，他們有展示不受重力影響的液體封裝技術。你們要不要研究研究，這麼快就說做不到，會不會太草率？」

RD心理在幹：「你到底有沒有聽懂我講話啊？就不可行啊！講不聽。就說產品經理每次都在外面看到什麼新玩意，就自己High了起來。明明是外行又要裝內行，專門想出一些怪東西來整我們！」

PM又說：「客戶說他們對這種產品有很大的需求，這個訂單對我們公司很重要。」PM開始拿客戶需求這個神主牌來壓。

PM心裡也幹：「這些RD超沒幹勁，每次開需求給他們，他們東閃西躲，就是不想做事情，老是說做不到，明明就有人做的到。RD都欺負PM在開發知識上不如RD。可惡！」

上面的需求溝通，到底出了什麼問題？

曾經有人教過Mr PM，跟RD溝通，要「態度柔軟，但立場堅定」，或是「要懷疑RD說的每一個做不到，要常常找出別人做得到的證據，逼RD就範」。PM和RD的關係，就在這些經驗傳承之下，越來越緊張，不是你壓倒我，就是我每次都反駁你。

問題的癥結點在哪裡？在於產品經理沒有好好敘述產品的故事。

什麼叫做產品的故事？就是把產品的從頭到尾的使用過程，如同小說般的敘述出來，至少要包含下面幾個範疇。

• 產品在哪一種情境之下被使用？
• 在什麼場合被使用？
• 被哪一個人使用？
• 為了達到什麼目的？
• 使用方式？
• 達成什麼效用？
• 使用頻率多高？
• 其他背景因素，諸如：個性、天氣、月份…等。

產品經理若沒有先敘述產品故事，而直接開產品規格請RD評估，就會鬧出「要RD做出可在無重力狀態下使用的原子筆」的笑話。若是產品經理可以事先說明「太空人因為有時候要做實驗抄數據，來不及輸入到電腦，所以需要暫時寫在紙上」的產品故事，那RD面對所謂的奇怪產品規格時，就很容易跳脫「無重力狀態下用的原子筆」的解決方案陷阱，進而能根據真正的需求，進行方案的構思。而想出不需要用原子筆，只需要用鉛筆的聰明解決方案。

而面對喜歡直接開規格的產品經理，RD在面對一些難以實作的規格時，應該也要學會問「這個規格背後真正的需求是什麼？」，這個問題可以去刺激那些不愛說明產品故事的PM，把難以實作的規格背後的真正需求說清楚。有時候是因為PM自己的知識有限，然後又趕著要將產品kick off，所以就直接開了規格（越有經驗的PM越常做這種事）。殊不知，若是PM能把真正的需求講清楚，其實RD手頭上還有更棒的解決方案或能達到相同目標的替代方案可用。

有時候問題不在於對方很機車不配合，而在於你思考模式出了問題。

千萬記住，別把別人的答案當作真正的問題。就「做出可在無重力狀態下使用的原子筆」的例子來說，就是PM把「外太空書寫」這個問題，先行找出解答是「無重力下可輸寫的原子筆」，然後再把解答當作問題來問RD。一般人非常容易犯這個毛病，請大家多多注意。

把產品故事敘述清楚的好處還不只如此。回到最上頭關於鞦韆的幽默漫畫，團隊成員因為都了解最源頭的產品故事是什麼，所以在訊息層層傳遞與轉譯的過程當中（需求規格->技術規格->系統分析->實際寫code），每個人都有了基本依據，而減少認知上的錯誤，降低產生誤解的機率。

產品故事甚至可以激勵團隊成員，因為他們知道，自己做出來的是個什麼樣的產品，甚至可以大家都可以貢獻一些idea，把這個產品弄得更好，畢竟大家都希望自己做的產品能夠大賣，這樣自己的考績也會打得好一些。而且在大家都貢獻了自己idea以後，就會更覺得這個產品與自己緊密相關，進而更願意付出心力在開發產品上。

最後要提醒的一點是，其實對PM來說，要跟每個相關的人都講一次產品故事，其實還挺累人的。筆者也常想偷懶直接跟某些比較不核心的成員，直接從最後的結論切入，而不去鋪陳告訴他們產品原始的故事。其實後來證明，跟每個成員都不厭其煩的講產品故事是有必要的，所以，PM們，別偷懶嚕。

Mr PM在經歷過許多產品開發經驗後，終於明瞭到前輩說的「態度柔軟，但立場堅定」…等的「對立」思考邏輯，還是不如「站在同一邊」的思考邏輯。小小心得與大家共享之，希望大家也可以多花點時間在「產品故事」的敘述上。

--
不想錯過我的新文章：訂閱免費電子報

---

我的線上課：數據化營運、產品增長 和 產品企劃力，歡迎大家報名