產(chǎn)品經(jīng)理和設計師之間最常見也是最尖銳的矛盾就是，設計師把花了很多心血做出來的稿子放到產(chǎn)品經(jīng)理面前，產(chǎn)品看了一下，覺得非常陌生和超出預期，說：“這都是些什么啊”。

(- -#)，(- -’)，此處無聲勝有聲。倒不是說這里面誰對誰錯，都挺辛苦的其實，但為什么總會落得如此尷尬呢。

世上配合最好的其實就是自己的手配合自己的腦袋。腦袋怎么想，手就怎么畫，畫出來的丁老頭再丑也覺得很親切，恩恩，是我的好作品（星星眼）。只是等到兩個人合作的時候，就有些麻煩了。因為，讓“設計師的手”精致地受控于“產(chǎn)品經(jīng)理的腦袋”，每次畫完看一看，覺得對就繼續(xù)畫、錯就改的敏捷調(diào)控是不現(xiàn)實的。

禍起，在于一些溝通中有很多弊端，唯有解決這些問題，才能讓團隊和諧地高唱“同一個夢想”。

一、產(chǎn)品沒有意識到要講的其實是故事

常見的產(chǎn)品經(jīng)理提需求的方式往往都是在需求文檔里直接寫“在Feed上增加一個轉(zhuǎn)載按鈕，點擊后可以填寫轉(zhuǎn)載理由”。這種描述方式其實已經(jīng)是一個很具象的解決方案了。然后這份包含數(shù)十條如此描述需求的文檔會被貼到內(nèi)部需求管理網(wǎng)站上，或者通過郵件發(fā)給設計師。

設計師拿到這份文檔，通常會覺得很憋屈。哎，忍忍算了，拿人錢財替人消災。然后拿著這份需求文檔在現(xiàn)有界面上去改。但往往會發(fā)現(xiàn)產(chǎn)品說這些具體解決方案其實在實現(xiàn)時是有很多細節(jié)沖突的。于是，設計師要先逆向YY出這個功能背后的用戶需求，然后再嘗試在與各種細節(jié)不沖突的夾縫中找一個新的解決方案。把這個稿子拿給產(chǎn)品看，產(chǎn)品就會楞一下，說“這是什么…”。(- -#)，(- -’)

其實很多產(chǎn)品經(jīng)理沒弄清自己最大的價值點。作為產(chǎn)品經(jīng)理最該做的是發(fā)現(xiàn)生活中用戶各種不知道該怎么滿足的需求，然后把這些很有挑戰(zhàn)也很有價值的用戶需求委托給資源方來幫忙想辦法解決。這個需求應該以盡量生活化的、講故事的方式來表達，與任何具體的解決方案無關。這樣設計師可以很明確地知道要解決什么問題，設計也就有了出發(fā)點，而且是產(chǎn)品經(jīng)理給的出發(fā)點。所以在這一環(huán)上，產(chǎn)品經(jīng)理交付的接力棒是一個好的故事，傳情地描述用戶的困難即可。

一個故事最核心的內(nèi)容應該包括: <什么樣的人><在什么樣的情況下><想要滿足何種需求><他/她會嘗試某種方式（或找不到任何解決方式）><但所需要的成本是*****><我們來解救他/她吧>。