起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識B端產品經理與業務方的相愛相恨
和對口的業務打交道時B端產品經理的日常核心工作，工作中雙方難免會遇到一些爭執與問題。如何看待這些問題？本文筆者分別從業務方、產品經理的角度，梳理了各自的槽點和辯駁，一起來看看吧。
不論是從事企業內部軟件建設，還是對外售賣的SaaS軟件設計，和對口的業務方打交道，是B端產品經理日常核心工作之一。前者的業務方一般是業務運營部門，后者的業務方一般是銷售、BD、客戶成功部門。
很多時候，B端產品經理和業務方如何順暢高效的協作，一直是各個公司和團隊普遍面臨的挑戰和困難。因為兩者之間工作的邊界往往存在重疊，權責也有模糊地帶，這就導致有時候工作中會出現一些小爭執，小摩擦，甚至產生沖突。
本文嘗試分別從業務方、產品經理的角度，各自描述槽點和辯駁，希望大家都能夠換位思考，理解彼此。
業務方如何看待產品經理和研發團隊
槽點1
研發效率低——產研團隊是事情最多的團隊，提個需求要排期，做一點小功能也要排期，實在不理解為什么，改個小東西，如果稍微走點心，難道不是我早上說完中午就該上線么？效率這么低，肯定都在偷懶磨洋工。
辯駁：業務人員往往不理解軟件工程的復雜性，嚴謹性，研發工作非常講究節奏型和計劃性，你們看起來的一個小功能點，如果非要加塞做，小到影響研發節奏，大到影響代碼質量，我要是同意你了，研發爸爸拿刀砍我，你幫我擋刀么！
槽點2
產品經理不懂業務——產品經理不理解我在說什么，提個需求解釋半天，最后做出來的東西完全不是我想要的，完全沒有解決我的問題。
辯駁：產品經理需要有機會去接觸學習業務，如果不給我們機會，讓我們遠離一線和終端用戶，那么我們如何學習了解業務呢？
槽點3
做的東西不好用——設計的什么玩意兒，用起來非常別扭難用，一點都不人性化，完全沒有陌陌和淘寶好用，這些人都得給開除了！
辯駁：你們要的那么急，給的時間這么有限，能做出來讓先用起來，就已經不錯了，還那么挑剔，要求美觀好用，沒門兒?。ó斎?，我也需要多用心，設計前多搞搞原型，上線后自己去一線體驗并實操，有時候我發現，我設計的東西確實很垃圾難用，哎，扎心）
槽點4
遇事不變通，比較軸——這幫搞技術的，都非常軸，一點不知道靈活變通，而且容易較真，很難相處。
辯駁：這事兒我認，如何用合適的手段和技巧，解決問題，推進事情，確實需要多用心實踐。就像我總吐槽碼農比較軸，實際上業務人員可能也認為我們軸。如果想和業務部門合作好，那就必須以業務人員的思維一樣去考慮問題、去做事情。
產品經理如何看待業務方
槽點1
需求不明確——有時候根本搞不清楚你們一天到晚在想啥，經常拿著個idea就跑來讓我們做，我三句話就能給你問回去，哎，真是浪費時間！
辯駁：我們是應該先想清楚，但某些時候你們確實也更專業，專業的你們幫助我們一起讓事情靠譜，難道不是你們的責任么；如果我把需求想明確了，那么我還要產品經理干啥呢，配個需求分析師直接寫軟件設計文檔不就成了么。
槽點2
思維發散，沒有邏輯性——你們為啥毫無邏輯性呢！我們做的是軟件項目，和代碼打交道，如果沒有邏輯，計算機怎么知道該做什么？我怎么知道該怎么設計？
辯駁：業務人員必須發散、天馬行空、喜歡試錯，否則KPI壓力這么大，我怎么知道干什么肯定能成功，還不得各種發散各種嘗試么！
槽點3
提需求總帶著解決方案——拜托你們直說問題，別說方案，方案我這里給！
辯駁：習慣性的提出問題和方案，這不是人之常情么，我也控制不住啊，你是專業的產品經理，你存在的目的之一，不就是引導我說出深層次的問題，并給出更好的解決方案么，如果你給不出解決方案，那你也得有心胸能接納我的解決方案啊！
槽點4
業務三天兩頭變——剛剛信誓旦旦的設計了業務方案，提交了需求，我們這還沒上線呢，然后你告訴我業務變了？不做了？
辯駁：我們是互聯網公司，三天兩頭變不是常態么？我們應該一起研究如何最小成本試錯，而不是拒絕試驗失敗和變化。
槽點5
對產品參與業務有所抗拒——你們對我們好像有所抵觸，不太愿意讓我們走進業務，如果這樣，我們怎么能理解業務，并幫你們呢？
辯駁：如果你們真心為了業務好，真心為了幫我們，而且又有這樣的能力，那么，即便公司不給機會，我也會給你們創造機會深入一線，幫助我們一起做好業務的！
槽點6
領賞你來，背鍋我去——哎，這個最傷心了，每次吭哧吭哧捯飭完，項目成功了，慶功會我總是只能看圖片直播的那個人。
辯駁：這個確實是我的問題，我們是一個團隊，我不辯駁，我改！
最后
上邊列了這么多吐槽，不知道你是否有所感觸呢？如何讓大家配合的更好呢？這個話題比較復雜，從公司文化，到組織架構都有影響，我們簡單的列出一些建議，有更好的想法，也歡迎大家留言補充。
- 保持一致的目標（共同的KPI，或OKR）；
- 搭檔而非上下游（組織結構的設計，信任的建立）；
- 開放協作的氣氛（產品經理有機會深入業務，參與業務）；
- 跟蹤每個需求和項目的效果（如使用情況，業務收益等，通過機制倒逼合理決策）；
- 產品經理要為結果負責（驅動并承擔業務結果，而非功能交付）。
好了，關于產品經理和業務方的相愛相恨，就講這么多，你有什么想法和觀點，或者吐槽呢，請留言分享??！
插播一條廣告
大家好，我是《決勝B端》作者楊堃，曾在VIPKID任產品總監一職。在工作中，遇見有很多優秀的B端產品經理，但缺少體系化、針對B端產品的實操訓練，在成長中走了許多彎路。
我努力將自己多年做B端產品的經驗提煉總結出來，和起點學院聯合打造了一門B端產品體系課——《To B產品實戰訓練營》希望能給需要的同學一些實質性的幫助。
幫助大家構建B端產品知識體系脈絡，掌握B端產品建設，從業務診斷、需求分析，到抽象建模、設計落地的全過程的方法思路，最終直接應用于工作實踐。
掃碼即可報名，還可為大家爭取到的專屬優惠~
立即搶座，報名成功后即可領取詳細課程資料！
作者：楊堃，《決勝B端》作者；公眾號：PM楊堃（ID：pmYangKun），11年互聯網研發、產品設計經驗，曾就職于傳統外資保險公司、百度，現就職于vipkid。
本文由 @楊堃 原創發布于人人都是產品經理。未經作者許可，禁止轉載。
題圖來自Unsplash，基于CC0協議。
挺好
即將轉崗為B端產品經理
不論是B端還是C端，做個懂業務的產品經理太難了，老師有什么了解業務的好方法嗎？
保持一致的目標（共同的KPI，或OKR）；
搭檔而非上下游（組織結構的設計，信任的建立）；
開放協作的氣氛（產品經理有機會深入業務，參與業務）；
跟蹤每個需求和項目的效果（如使用情況，業務收益等，通過機制倒逼合理決策）；
產品經理要為結果負責（驅動并承擔業務結果，而非功能交付）
說的很實在，保持目標一致很重要
產品經理要對技術爸爸負責
文章先收藏著，等到后續接觸到業務拿出來再看一遍
1、需求評審：跟業務方對接需求的時候，會有好幾次的確認和評審，交互原型完成時會給客戶演示確認，確認沒問題會輸出需求文檔，再進行細節確認，需求都完成后再確認設計稿，至少有三次確認機會，確認時候不發表意見，或者說先按你說的做，沒啥大問題，有小變動到時候再改。結果上線了，說這不是我要的，你沒理解我的要求，推翻重做。早干嘛去了，每次評審會時怎么不反饋呢，自己想要什么不清楚總讓先做，推翻重做說的輕巧，開發要罵人的。不用業務方承擔開發成本的，都是耍流氓，如果他們給研發發工資就知道心疼了。
2、催幾號上線：跟你說完需求就開始問幾號能上線，你跟我說完我要梳理之后開發才能評估時間呀，哪能那么快就出項目計劃，需求分析和方案設計不要時間的呀。甚至倒排期：不管需求實現難度和功能點多少，直接給定一個日期，不管你們加班也好還是怎樣也好，就是這個時間點要，這種一般是業務方領導給了他們壓力。產品協商砍一些優先級稍低的需求，不讓步，這是要往死里逼開發呀。
3、優先級排序：時間緊迫時請業務方排優先級，都給排成1，這排了跟沒排有啥區別，總是不愿意做取舍。
4、功能設計時恨不得考慮未來各種場景，要求系統能靈活支持，本來時間就緊，顧好目前的業務支持，后面的場景遇到了再做不行么。
5、所有業務方不直接使用的功能在他們看來優先級都很低可以一直往后放：比如因為產品發展而要考慮的組件剝離獨立維護，系統性能優化等等。
分清角色定位與分工
業務童鞋的本質工作：梳理業務邏輯，反饋業務痛點，表達業務期望。而不是 設計產品方案，比如在這個頁面上加個字段
產品童鞋的本質工作：深入了解背景，挖掘核心需求，設計產品方案。而不是 原型工程師，PRD編輯員。
太扎心了，以前沒有感受，自從在客戶那工作了半年多，看了這個，簡直段段都要驚呼：是我！尤其是業務方的槽點二。。。另外還有一個比較惡心的現象了，就是每次客戶覺得上線后達不到他們想要的（鬼知道他們想要啥），就開始抓考勤，開晨會。。。唉，說多了都是淚555