以前做項目得到一個經驗，就是在立項前，不需要拿個布好局的頁面出來討論，因為我們覺得，在方向還未清楚的時候，討論頁面細節可能是浪費時間。
這一回，戰略部的新partner給了我一個不同的啟示。按說她的工作是在我上游，可是在最開始的實際操作中，她卻把工作走到了我的下游，直接做了一個頁面出來，把功能點、內容全都畫好了…… 我一陣吃驚，對比著我自己的proposal，我跟她說，你這個東西，同事們能接受嗎，因為他們都不知道方向在哪裡，你卻讓他們看細節。
後來我明白她的做法了。這個是“結果導向”——不把頁面先做出來展示一下，你面對那些不太懂產品原理的同事，是無法真正將講解傳遞到他們的內心的。即便洋洋灑灑的文檔在方向和細節上都非常完美了，但對其他業務部門的同事來說，可能仍是抽象或概念化的。在這個時候，不是說他們無法理解產品經理展示的東西和陳述的事實，而是，他們可能沒法兒透露真正想要的東西——他們要麼直接向你“投降”，認為非常好，要麼是半懂不懂，連自己的觀點也忘記了，再要麼是根本反對，陷入跟你空泛PK的陷阱。
Partner用這個很具體、很簡陋，但是又把功能點與內容展示出來的“結果頁”，把參與討論的同事內心想要的東西，“逼”了出來，而且越是陷入細節點的討論，對方的需求就越明晰，比簡單陳述一個概念要好很多。比如針對“結果頁”，參與討論的同事有這番說話：
· 我覺得網友的評論擺得太下面了，占比太小；
· 我覺得相關在線醫生交流這裡，實際不可操作，因為運營投入太大，每個月要消耗掉好多錢；
· 頁面非常好，沒有問題，但是覺得評論這塊還是沒有突出；
……
這個時候，對方想要什麼，我們心裡就有譜了。這比針對某個概念（比如“提高互動比例”）進行不斷地陳述、PK，要高效很多。
在此基礎上，後來我對自己的proposal進行陳述，感覺就相當esay了。在表達的穿透性上，似乎達到更好效果。下來我就跟戰略部的這位partner說，我們簡直是完美的配合。這其實同一目標的不同方向，像挖隧道一樣，從兩頭挖，最終還是要把隧道打通。
————————
通常，做一款產品，先要完成市場調研、競品分析等等流程，然後再畫原型，方可將項目執行下去。在前期資源整合的部分，了解一個業務、了解團隊資源的情況、了解我們要做什麼，即方向的把握會成為首要考慮的東西。這個階段，其實更考驗產品經理的溝通和消化能力，特別是在多部門都有產品需求提出的時候。比跟技術美術溝通要難很多。