導讀業務同學看過來，八個方法教你更高效給產品經理提需求！一個普通的工作日下午，同事小R給我發了個釘釘對話截圖（附帶個委屈的表情）。大致的意思是Y姐要求PM在FA....

業務同學看過來，八個方法教你更高效給產品經理提需求！

一個普通的工作日下午，同事小R給我發了個釘釘對話截圖（附帶個委屈的表情）。大致的意思是Y姐要求PM在FAQ總增加幾條內容，需求很普通，溝通方式很犀利。

“你不要問這問那，我在一線看到很多問題，你就趕緊給我加上去就行了！”

“能不能讓我看一下您這邊整理的調研資料？”

“不是跟你說了，我看到很多問題了嗎，沒工夫整理什么資料，你趕緊給我加上去，這么點事怎么那么費勁！”

……

最終因為斷斷續續的反復溝通了很多天都沒有進展，只能升級到我這里處理了。

其實類似的事情在業務方和產品之間經常發生，這也就是為什么說產研團隊最大的成本不是開發而是“溝通”了。

那業務同學到底該如何給產品經理提需求，才能更加高效呢？

01 說清楚背景

每當業務同學提交需求的時候，都有個典型的特征：充滿激情，有種要拯救世界，解放全人類的感覺。

有這種特質的業務同學是非常優秀的，但也常犯一個典型的錯誤：想當然的認為產品也是這么想的。

但是，此時的產品就只會思考一個問題——“這個需求真的存在嗎？”

這是一種定性的考慮，如果需求本身就不存在，那么產研團隊后續的任何投入都是一種浪費。

這個時候你往往會發現，產品經理一直會追問你：

“為什么需要這個功能？”

“誰會使用這個功能？”

“會在什么場景下使用？”

本質上就是通過了解需求背后的場景，來做需求真偽的判斷。

相信我，但凡有經驗（被坑過次數較多）的產品一定會把這條作為優先級最高的判斷。

所以，給產品經理提交需求。首先最重要的是，要交代清楚需求的背景，一般包括場景、用戶和痛點（有的時候也是價值）。

建議開場白如下：

“hi，天兒哥，我們在去BD陪訪的時候，發現在BD掃街時效率很低，要自己人肉檢索身邊的線索，很多還是無效的（被別的BD跟進、競品獨家等）。”

• 場景：掃街
• 用戶：BD
• 痛點：優質線索獲取效率低

02 證明需求的相關性并量化其價值

真實的場景描述，會解除產品經理對需求本身真偽性的質疑。

但是眾所周知，任何團隊研發資源都是稀缺資源，意味著任何的投入都會產生機會成本。

產品經理的工作職責就是：保證在正確的方向上，任何的研發資源投入都要能夠帶來明確的產出。

所謂正確的方向，就是該需求產生的價值與公司業務當前階段戰略目標相關，能起到有效的支撐；如果公司當前的階段目標是節約運營成本，這時候你提個“支付渠道路由對接”的需求，肯定好過提“對接用友財務系統”。

所謂明確，就是能夠量化。不是說不能夠量化的就不做，只是比較麻煩，需要老板特批（對不確定性的需求的一種認可）。一般來講大部分都是可以量化的，只是沒有深度思考罷了。

所以，此時產品經理緊接著會考慮的這樣問題：

“你們部門的OKR是啥？”

“你這個需求的價值有多大？”

建議對話更新如下：

“hi，天兒哥，我們在去BD陪訪的時候，發現在BD掃街時效率很低，要自己人肉檢索身邊的線索，很多還是無效的（被別的BD跟進、競品獨家等）。

我做了個統計，公司目前有2765名BD（示例），每天花費在檢索線上的時間大概是2個半小時（通過BD陪訪和問卷收集了200多個樣本），統計下來，這方面每天大概要花掉6912個小時，占總工時的25%（按每天工作10個小時計算）。

俺們部門現在OKR重點是提升BD人效，所以這塊咱們要是能搞一下，還是挺有價值的。”

• 場景：掃街
• 用戶：BD
• 痛點：優質線索獲取效率低
• OKR：提升BD人效
• 價值：25%的工時占用，6912小時

03 提供參考建議并附上注意事項

真實的場景，明確的價值，基本上就是個靠譜的需求了。

此時的產品會根據業務方提供的信息，考慮初步的解決方案了，一般會提供幾種解決方案的思路，和業務討論。

一般來講，大部分業務會認為此時提交需求的事情基本上就完事兒了，剩下的就是等著產品經理給方案了。

這樣沒錯，但效率很低。

造成反復溝通的原因無非兩點：

• 該考慮的業務風險沒有考慮
• 和理想中的方案有些距離，使用產品給的方案心理有點沒底

以前聽過這樣一個法律糾紛：說是一家外貿公司進了一批北極鱈魚，本來想要的是產地是俄羅斯的，結果賣家給的是法國的，最后法院只能以合同沒有明確約定產地為由，駁回買家請求。

這個故事留下來的經驗是，好的合同一定是律師和業務方一起努力的結果，僅僅是依靠律師肯定是不行的。

——同理，一個好的方案僅僅是依賴產品經理，也是不行的。

所以，在提交需求的時候，如果你已經有了自己的想法，不妨明確的和產品經理提出來，作為參考。

如果在業務方存在的一些規則和風險也要第一時間明確出來，避免后續因反復溝通耽誤需求進度。

建議對話更新如下：

“hi，天兒哥，我們在去BD陪訪的時候，發現在BD掃街時效率很低，要自己人肉檢索身邊的線索，很多還是無效的（被別的BD跟進、競品獨家等）。

我做了個統計，公司目前有2765名BD（示例），每天花費在檢索線上的時間大概是2個半小時（通過BD陪訪和問卷收集了200多個樣本），統計下來，這方面每天大概要花掉6912個小時，占總工時的25%（按每天工作10個小時計算）。

俺們部門現在OKR重點是提升BD人效，所以這塊咱們要是能搞一下，還是挺有價值的。

來之前，我看了一下幾家競品的解決方案，其中這家我覺得挺好的，建議參考一下。另外，BD那邊有特殊規定，不許BD跨區域拜訪，這需要特別注意一下。”

• 場景：掃街
• 用戶：BD
• 痛點：優質線索獲取效率低
• OKR：提升BD人效
• 價值：25%的工時占用，6912小時
• 建議：競品xx的方案
• 注意：BD不許跨區拜訪

04 解決問題而不是堅持方案

此時就進入到了提交需求的隱性階段。

一般來講，在開發成本相同的情況下，產品會優先考慮業務方建議的方案，避免額外的溝通成本和業務風險；但在開發成本出現明顯差異的情況下，產品會嘗試說服業務接受新的方案。

主要的方式就是回顧目標，基于前期充分的溝通，大家對核心問題的認知是一致的，原則上“只要能在預期時間內能解決問題”的方案都是可接受的，當然哪個更快就優先選擇哪個方案。

建議方案選擇上，業務同學要盡量尊重產品經理的意見。主要是要維護好他的主動性，比較沒腦子的做法就是把產品經理當成寫稿的。

所以，當出現此類問題的時候，業務千萬不要在方案上糾結“到底用誰的”，這只會把雙方的精力都分散到論證各自的正確性上，可笑的是最后大家拼的是“體力”。

沒必要，只要能盡快拿到結果。

“黑貓、白貓無所謂，能最快抓耗子的就是好貓。”

05 友善的溝通方式

能做到上述的業務同學，可以說是優秀的水平了。

如果能在溝通技巧上在注意一下，那就更好了。

要知道產品經理，之所以叫做產品汪，真的是每天累成狗，對結果負責，工作沒有邊界。

要是你能在溝通之前，把需要溝通的內容提前發給產品經理，再約個溝通時間。

那本世紀最受歡迎的業務方，非你莫屬。

06 自行解決內部優先級

一個比較讓產品經理頭疼的問題，就是同一個部門有若干個需求方（共用研發資源），彼此之間的需求的預期時間存在沖突，一般情況下產品經理會主動反饋相關方自行溝通（有的時候產品也會參與）。

這是大部分公司的常態，業務同學也會認為這就應該是產品經理分內的事情。

這么說，沒毛病。

但是——太被動和消極了。

比較建議的做法是，找產品經理要一下需求池地址，主動了解目前的需求情況。

如果在找產品經理之前，就已經協調好了內部的需求優先級，相信我，產品經理一定會“以身相許”的。

太體貼人了！

07 善用敏捷通道

上述表達的都是常規性的需求，周期比較完成和嚴謹。

還有一類比較特殊的需求，工程成本很低（改個文案、改個圖片、調整各大小等等），個體價值不明顯，但數量多了又對用戶體驗很有傷害（價值逐漸體現），此類被稱為“敏捷需求”。

敏捷類需求的處理邏輯為“快速響應，持續迭代”：快速響應，換句話將就是只對需求做最直觀的判斷，甚至直接以業務方的為準；持續迭代，指一般的敏捷需求都會采用“周迭代”的方式，批次不斷進行優化。

業務同學應該善于利用這個通道，盡量為自己的需求，找到一個成本很低的方案。

08 及時表達感激

一旦通過業務的方案評審，產品經理就要推進工程團隊盡快啟動。

整個產研團隊后續還要經過工程評審、進度review、聯調測試、工程驗收、業務驗收、上線通知等等諸多環節，保證如期履約。

這個階段，業務同學除了要重視測試的驗收，做好風控以外，尤其要在意上線通知階段，不管結果如何，一定要在對應的郵件回復表達對過程的感激。

當然，后續有正向結論的時候，要再進一步肯定產研團隊的價值，為后續的合作，奠定一下感情基礎。

寫到最后，想起前兩天看到的一句話，獻給那些追求卓越的業務同學：

人生就是場馬拉松，只要你愿意做出改變，任何地方都可以是起點。

本文由 @吳天 原創發布于人人都是產品經理。未經許可，禁止轉載

題圖來自Unsplash，基于CC0協議