這樣提需求,產品經理加班都願意幫你做!

人人都是產品經理2019-07-11 18:00:34

關注並標星「人人都是產品經理

每天早07 : 45 按時送達


溝通技巧作為職場人的必備軟技能之一,直接決定了你的工作效率。在日常溝通中,有一個明確的目標——“給產品經理提需求”的時候,怎樣的溝通方式才是有效的呢?看看作者給我們的解決方案,希望能對你有所幫助。

作者:吳天

微信公眾號:竹林雜記(ID:pmwutian)

題圖來自正版圖庫 圖蟲創意

全文共 3652 字 1 圖,閲讀需要 7 分鐘


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


“你不要問這問那,我在一線看到很多問題,你就趕緊給我加上去就行了!”
“能不能讓我看一下您這邊整理的調研資料?”
“不是跟你説了,我看到很多問題了嗎,沒工夫整理什麼資料,你趕緊給我加上去,這麼點事怎麼那麼費勁!”
……

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


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


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


一、説清楚背景


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


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


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


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


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


“為什麼需要這個功能?”
“誰會使用這個功能?”
“會在什麼場景下使用?”

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


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


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


建議開場白如下:


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


場景:掃街


用户:BD


痛點:優質線索獲取效率低


二、證明需求的相關性並量化其價值


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


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


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


所謂正確的方向,就是該需求產生的價值與公司業務當前階段戰略目標相關,能起到有效的支撐。


如果公司當前的階段目標是節約運營成本,這時候你提個“支付渠道路由對接”的需求,肯定好過提“對接用友財務系統”。


所謂明確,就是能夠量化。


不是説不能夠量化的就不做,只是比較麻煩,需要老闆特批(對不確定性的需求的一種認可);一般來講大部分都是可以量化的,只是沒有深度思考罷了。


所以,此時產品經理緊接着會考慮的這樣問題:


“你們部門的OKR是啥?”
“你這個需求的價值有多大?”

建議對話更新如下:


“Hi,天哥,我們在去BD陪訪的時候,發現在BD掃街時效率很低,要自己人肉檢索身邊的線索,很多還是無效的(被別的BD跟進、競品獨家等)。
我做了個統計,公司目前有2765名BD(示例),每天花費在檢索線上的時間大概是2個半小時(通過BD陪訪和問卷收集了200多個樣本),統計下來,這方面每天大概要花掉6912個小時,佔總工時的25%(按每天工作10個小時計算)。
俺們部門現在OKR重點是提升BD人效,所以這塊咱們要是能搞一下,還是挺有價值的。”

場景:掃街


用户:BD


痛點:優質線索獲取效率低


OKR:提升BD人效


價值:25%的工時佔用,6912小時


三、提供參考建議並附上注意事項


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


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


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


這樣沒錯,但效率很低。


造成反覆溝通的原因無非兩點:


  • 該考慮的業務風險沒有考慮

  • 和理想中的方案有些距離,使用產品給的方案心理有點沒底


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


這個故事留下來的經驗是:好的合同一定是律師和業務方一起努力的結果,僅僅是依靠律師肯定是不行的——同理,一個好的方案僅僅是依賴產品經理,也是不行的。


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


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


建議對話更新如下:

“Hi,天哥,我們在去BD陪訪的時候,發現在BD掃街時效率很低,要自己人肉檢索身邊的線索,很多還是無效的(被別的BD跟進、競品獨家等)。
我做了個統計,公司目前有2765名BD(示例),每天花費在檢索線上的時間大概是2個半小時(通過BD陪訪和問卷收集了200多個樣本),統計下來,這方面每天大概要花掉6912個小時,佔總工時的25%(按每天工作10個小時計算)。
俺們部門現在OKR重點是提升BD人效,所以這塊咱們要是能搞一下,還是挺有價值的。
來之前,我看了一下幾家競品的解決方案,其中這家我覺得挺好的,建議參考一下。另外,BD那邊有特殊規定,不許BD跨區域拜訪,這需要特別注意一下。”

場景:掃街


用户:BD


痛點:優質線索獲取效率低


OKR:提升BD人效


價值:25%的工時佔用,6912小時


建議:競品xx的方案


注意:BD不許跨區拜訪


四、解決問題而不是堅持方案


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


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


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


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


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


沒必要,只要能儘快拿到結果。


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


五、友善的溝通方式


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


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


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


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


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


六、自行解決內部優先級


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


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


這麼説,沒毛病。


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


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


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


太體貼人了!


七、善用敏捷通道


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


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


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


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


八、及時表達感激


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


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


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


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


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


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

———————— END ————————


每個「在看」,都是一次鼓勵 ▼

https://hk.wxwenku.com/d/201119697