近年來聽到越來越多2C衰退，2B興起的聲音，雖然我對這種說法保留意見，但認識的同行也有越來越多人考慮轉到2B行業。作為過來人，本文分享的是2B產品（特別是大）裡面做產品規劃的一個很常見但有很需要解決的深坑，是需要這行的產品經理去面對和解決的的。（當然如果你給自己的定位就是原型仔和需求編寫工，那接下來的文字對你沒啥意義）
相信很多2B企業市場的產品經理都會遇到這種情況：產品規劃裡面出現了一些功能是專門做給特定客戶的“一錘子買賣”。當發生這種情況之後，恭喜你，你的公司要不已經進入了一種“銷售驅動”的產品發展路線，要不就是即將進入了。
“銷售驅動”的一大特點是，產品研發的重點落到了某些特定的客戶上，代價是犧牲了產品核心價值的創新、新的功能、質量提升和技術優化。
用這種“驅動方式”發展下去的產品，最終會失去尋找到真正不可替代的價值點的機會，甚至發現“銷售驅動”的產品變得更難銷售了，更不用說能成為Scalable的商業模式了。可怕的是，團隊可能往往意識不到為什麼到達了這種地步，甚至沒有意識到出現了問題。所以首先，我們應該正本清源，從根本分析一下問題的所在。
產品和項目
在說“銷售驅動”之前，首先我們要理清做產品和做項目的區別，跟2C產品不一樣，2B產品是很容易混淆做產品和做定製項目兩件事情的。先來看一下兩者有什麼不一樣。
企業軟件行業的老前輩阿朱的《走出軟件作坊》裡面曾經做過產品和項目的對比，我印象一直十分深刻，雖然成書已經過去了一段時間了，那時候甚至還沒有云、SaaS這些概念，但這個差異的本質我認為到現在依然適用，大意如下：
- 做項目，就是一兩個程序員往客戶那一駐紮，您說你想要啥我們就做，做完您看行就驗收，不行我們再改，覺得沒問題我們就回去了；
- 做產品，是標準的，不會特意為客戶修改，您要覺得拿點不順眼不想買了我也沒辦法，我們不修改，我們不改您就不買我們也沒辦法，您要買了，那我們就上門安裝、實施，就這樣。
最難的就是說產品不是產品，說項目不是項目的東西。一個東西，本來是給A客戶做的項目，然後B客戶看著不錯也要，然後把A客戶的項目代碼改改給B客戶用，這下麻煩了，A客戶代碼裡面有了B客戶要求的功能，這下軟件既不是A客戶的，又不是B客戶的，然後之後再摻和進C、D、E客戶，就更是頭疼得要命。
阿朱是從開發和代碼管理的層面，來看混淆產品和項目兩者之間關係的弊端的。我們還能更進一步，從商業和財務層面分析兩者之間的區別。
做產品的公司銷售的是標準的產品，一個產品可以不斷重複地銷售給不同的客戶，這樣單位的邊際成本低於單位價格，這樣才能形成一個可持續的模式。做產品的公司都是前期投入大，要把銷售量到收支平衡點，超過收支平衡點之後的銷售後額絕大部分都是高利潤了。
做定製項目的公司就不一樣了，每一個項目是單獨核算的，目就是要確保每一單都是賺的。客戶提出越多的需求，項目能夠賺更多的錢（當然前提是客戶承認新需求產生的工作量，這個也是很需要項目團隊的管理水平的），每個客戶都能夠得到獨立的產品。
很多做項目的公司都會嘗試開始把項目轉化成通用產品，不過一般而言很難善始善終，新的定製項目會不斷打斷所謂的“產品化工作”，畢竟項目是可以馬上來錢的。
產品和項目兩者模式並不分高下，只要世上還有共性需求和個性需求之分，兩者都可以賺錢。但對於2B產品來說，很容易不知不覺中地走入一種兩者混合的模式：一種半定製的軟件，需要不斷投入研發人員來支持新的需求，但又不是通過定製項目的工作量而是軟件授權的方式來報價，往往折中報價方式又過低，用這種方式發展的客戶數也不足以達到收支平衡點。
很多時候我們遇到的很多困難，例如開發資源無法支撐大量客戶的需求，銷售覺得開發部門不給力響應慢，開發部門又覺得銷售亂承諾客戶給自己挖坑需求怎麼做都做不完，這些都是表面上的困難，根本原因就是這種混合模式就是根本無法大規模擴張的模式。
“銷售驅動”是怎麼產生的
接下來說清楚“銷售驅動”的模式是怎麼在公司裡面產生的， 分為下面幾步：
- 一個正常的產品驅動的路線是怎麼規劃的；
- 客戶定製的“一錘子功能”的出現；
- 接下來會發生的累積和一系列連鎖反應
“產品驅動”的路線規劃
一般而言，對於一個已經成形，開始找到自己的Product/Market Fit的產品來說，要讓產品健康地發展，研發團隊要投入的精力一般包括四個部分：
- 看得見摸得著的功能提升：新的功能、用戶體驗和可用性的提升、對競品功能的響應，等等；
- 各種“基礎設施建設”和“性能提升”：可用性、可擴展性、安全性等等；
- 各種“測試、修復和運維”：修復bug、測試用例、DevOps、填技術債務等等；
- 不斷地學習和驗證：用戶調研、數據分析、原型設計來更深入瞭解一線用戶、驗證想法，來給產品下一步創新做準備。
這四個部分都有讓不同人支持的理由：
- 市場和銷售希望產品能夠有更強大的功能賣給客戶，所以他們會鼓勵不斷地做新功能；
- 技術人員最清楚軟件平臺裡面的技術風險和缺點，所以他們會希望能更多地投入在架構、工具和重構上（就是趕緊把留下來的坑填了）；
- 實施/客服能夠儘量減少客戶的投訴或疑問，所以他們會更希望投入在bug修復、可用性提升，讓暴露到客戶的問題越少越好；
- 老闆希望產品有更進一步的突破，但他們經常會把突破和創新視為個人態度努力而不是用科學的方法進行推進的結果，他們往往會低谷需要在實驗和驗證上需要投入的成本。
作為產品經理，我們在做產品規劃的時候，會把有限（永遠都不夠）的研發資源，像投資建立投資組合一樣，折中和平衡分配到以上幾個方面，希望這種投資組合能夠讓產品更健康和可持續地發展。就像玩星際一樣，要在把資源在攀科技和爆兵之間做平衡。
於是哼哧哼哧一輪，我們可能會誕生一個這樣的基於以下資源分配的產品路線圖。
路線圖看起來不錯，然後老闆也通過了。然而沒過幾天，銷售團隊反饋說，某個大客戶有點需要定製的“小功能”，於是惡夢慢慢開啟……
“XX客戶希望能實現這個功能”
產品的用戶提出新的功能需求是人之常情（畢竟強如微信也有一億人要教張小龍做產品）。在2C產品或者小B市場裡面，有成千上萬的用戶，單獨某個用戶不會直接影響到到我們對產品路線的改變。產品團隊會廣泛吸取各方面收集到的優化點，這些優化點可能來自於用戶的直接反饋，也可能來自數據的收集和分析，對於行業和環境的觀察，對於競品的分析等等。總之，很難會出現單獨一個客戶就能影響產品路線的情況。
但對於企業市場來說，客戶規模（和隨之而來的影響力）會更大，數量也更少。很可能某個客戶的合同就會佔到公司5%的總收入。這種情況下，單獨一個客戶對於產品決策的影響力就會比2C或小B大得多。而這些客戶也常常會給銷售人員提出他們的個性需求，常見的包括：跟客戶的其他系統進行整合、工作流程的調整、報表定製等等；
銷售人員會怎麼處理呢這些需求呢？先看看銷售人員的特長和思維模式：
- 銷售人員一般都樂觀、不輕言放棄，還特別擅長和人打交道和在組織裡面找到推動事情前進的關鍵人物；
- 擅長說服：能用他們強大的說服力，把客戶的需求重新掰成我們的產品能夠大部分滿足他們的應用場景（儘管實際上不是這樣），再進行投標；
- 企業對於銷售人員的業績評價標準十分簡單粗暴：能簽單就是成功（就像電競界一樣的：沒有成績，連呼吸都是錯的）；
- 對銷售人員的激勵方式（銷售提成）讓他們百分百專注於自己手頭上的客戶和銷售機會。
所以當客戶跟銷售提出一些產品原來路線圖所不包括的需求時，銷售人員就會很自然地要求產品經理去實現這些功能。正常來說，他們首先得到的答覆一般是“我們先記錄下來，然後下個季度再來考慮”或者“這個排不上期”而不是“這個想法太棒了，我們立馬做”。
正當產品經理天真地以為自己已經把事情完結了的時候，不要忘記銷售人員不輕言放棄、擅長說服和找到關鍵人物的特長。這些特長能夠幫助到他們在外打動客戶，自然也能幫助到他們對內對管理層施加影響，然後管理層就會從銷售人員那聽到下面這些說法：
- “這個客戶是我們重要的大客戶，對於我們具有戰略意義。完成這些需求對於簽單/收款和達到銷售目標是必須的”；
- “這個需求很簡單”；
- “這個客戶很清楚想要什麼，會成為我們市場裡面的一個標杆客戶”；
- “我們採用敏捷的開發方式，所以研發計劃應該可以靈活調整的才對”；
- “這個是市場通用的需求，而不是單個客戶的需求，我們談過很多的客戶都希望有這個功能，這個功能其實早就應該做了”
這些說法看起來都合理（我們也倒是希望它們是真的合理的，這樣做產品就比現實上簡單多了），正因為銷售團隊所花的所有時間都是在客戶身上，從這個角度來說，他們也的確可以認為自己就是最瞭解客戶真實需求的人。
然後接下來的推論就會變成，因為這些客戶對於我們太重要了，我們一定要找到辦法來體重資源來服務他們。於是，我們前面那些立足於整體的產品規劃就會為這些特定的客戶需求所讓路。就算產品想掙扎一下，說出來的理由跟銷售人員的相比，更像是推卸和牢騷，常見的包括：
- 現在已經沒有空餘的人手來做這些事情了；
- 如果要做這個那原定計劃中的XXX和XXX就要延後了；
- 客戶不瞭解我們軟件的現狀，所以他們提的需求我們需要從頭認真分析，初步判斷這些是很大的工作量；
- 如果這個需求是通用需求，那我們早就把它放到我們高優先級的工作上了；
- 等等
然而這些反對意見一般最終都沒有什麼用，我們還是不得不把這些需求排進我們的產品路線圖當中。而我們之前分析的幾類工作當中，也只有最後一種——學習和驗證，相對來說最不緊急，而從這些工作中抽調人手在短期內影響最小。於是我們新的資源投資組合就變成了以下這樣。
看起來還沒有啥大問題（儘管犧牲了點有長遠回報的投資），不過往往事情沒有那麼簡單。當真的開始開發這些客戶定製的需求的時候，就會不斷髮現有新的坑：新的流程需要改變我們現有的數據流轉方式；客戶現有系統用著不標準的對接方式；一些看起來簡單的UI個性化需要，要重寫成可靈活配置的形式，不然就要變成兩套代碼來維護等等。
當然還有最坑的，其實客戶自己最開始也沒想清楚或者說清楚，做著做著還得改。然後為了趕客戶給出的時間點（這是經常發生的），不得不交付出一個揹負大量技術債務、甚至還沒有經過嚴格測試覆蓋的產品出去。
這種定了時間點就要完成的功能，也往往會讓我們忘記（或者避而不談）去驗證這些需求背後真實性和是否真的存在意義。於是實際上，我們的投資組合結果變成了這樣。
不過好消息是，經過一大輪趕工之後，於是我們趕在了deadline之前把功能交付了出去，客戶爽快地簽單/付款了，老闆、產品、研發、銷售大家都皆大歡喜。是不是以為事情就告一段落，可以回到我們原來的產品路線上呢？沒那麼簡單。
進入“銷售驅動”模式
有了上面這一次“成功的案例”之後，管理層和銷售部門都嚐到了甜頭，知道了產品和研發部門是能夠為客戶做定製需求的，這種方式（看起來）也沒有給公司造成什麼損失。這個先例一開，後面就會成為慣例。
其他的銷售人員就開始照葫蘆畫瓢，用答應客戶的定製功能（一般還附帶時間要求）來完成自己的簽單目標，甚至管理層也會開始要求研發部門優先去完成這些有助簽單收款的功能開發，我們原來的投資組合的其他部分，被進一步積壓，最終變成了這樣。
於是我們的產品研發的決策模式，也從考慮整體市場的方式，變成為每一單真金白銀合同所附帶的功能所開路。單獨看，每一次決策好像都沒什麼毛病，但整個產品已經不知不覺中陷入了一種局部最優的死循環裡面：
優先做客戶個性定製需求—>犧牲了產品的整體水平（不僅僅是功能、還有穩定性、可用性，最重要的，真的能為廣泛客戶解決真實痛點的能力）—>只能更依賴銷售人員說服客戶和滿足客戶的定製需求才能簽單—>優先做客戶定製需求—>……
到了這一步，一系列的連鎖反應就會慢慢發展和爆發，表現在：
- 需求來自不同的客戶，附帶的嚴格的時間要求，也讓我們沒法為一個需求深究其背後的真實痛點做出根本的解決方案，這些功能點也往往不存在什麼真實的戰略價值，這些碎片化的需求影響了產品的內在一致性和長遠發展的能力；
- 產品經理從“產品的CEO”，變成了被動地應對客戶需求的狀況，實際上變成了服務客戶的項目經理和原型/需求編寫工，不再能積極主動地規劃他們的產品；
- 研發/設計人員會失去積極性，因為他們被迫接受客戶指定的需求和時間點，而不是用一種學習和探索的方式來開發產品。而這些客戶的需求完成後也很少會有正面的反饋（一般都是出問題了才來找你）；
- 銷售團隊也會慢慢發現自己的日子不大好過了，客戶依然會不斷地提出新的定製需求而且胃口越來越大，而研發的排期也因為其他的客戶需求堆積，變成了一個長長的隊列，再也無法像之前那樣快速地去響應客戶，想繼續用這種方式談新的客戶也會越來越艱難；
- 整個公司的利潤率會下降：軟件產品商業模式的魅力原本是很低的邊際成本，但在現在的既不是產品又不是項目的方式下，軟件的授權費用未必真的能覆蓋客戶定製需求的成本；
- 市場份額增長緩慢，因為讓路於客戶定製，產品不再有新的亮點來擴張新的市場了。
矛盾開始會爆發，然後就會開始亂找病因、亂開藥方，“產品經理應該要更快速響應客戶的需求，哪怕先做個方案響應一下客戶”、“開發人員效率是不是太低了，他們能不能加班趕上進度？”“銷售能不能不要亂給我們挖坑？”然而這些都不是問題的根本所在。
根本的問題就在於組織形式和盈利模式的錯配：單個客戶的需求優先，讓我們犧牲了為廣闊市場去規劃和研發產品的能力，做著一個個隱藏在產品外衣之下的外包項目，為一棵樹放棄了一片森林。
如何解決問題
上面說的這些問題，是一個系統性的問題，不是單個產品、研發或者銷售人員可以憑藉自己的力量去解決的，而是應該是跟管理層一起，開誠佈公地討論和解決問題，嘗試用以下的方式來解決：
（1）識別自己是否正處於這種“銷售驅動”的狀態當中：整體分析一下產品和銷售的運轉遇到了瓶頸了，新客戶的獲取是否越來越依靠於定製開發？可以把最近的一段時間（例如半年到一個季度）的研發投入拿出來分析，有多大的比例是用在為單獨的客戶定製功能上，又有哪些所謂的“提升產品水平的通用功能”實際上只有一兩個客戶在用？我們所做的新的功能是否跳過了驗證的步驟？
（2）公司究竟是做產品還是做項目才是真正滿足市場需求的？徹底分析自己所在的行業和要滿足的需求到底是否能夠用通用產品去滿足，還是需要一個一個的定製項目去做，企圖採用折中的方式一定異常艱辛。
（3）該是定製項目的，就按定製項目的模式去報價，然後去應用專業的項目管理的方式來管理客戶的需求，不要幻想著為客戶定製的需求能夠變成通用的產品，雖然不是完全不可能，但這概率就跟刮彩票一樣，刮到了算是賺了，但不能指望著刮彩票來過日子。
走定製項目路線的，也可以讓專門的研發力量去打造平臺和工具（例如PaaS或者現在很火的中臺概念），來提升整體的研發效率。
（4）該是做標準產品的，就要正視問題和管理好“銷售驅動”的問題，用運營產品的思路去規劃和管理產品，例如：
- 從用戶的獲取、轉化、留存等角度來思考產品，盡力去優化自己整體的LTV和CAC；規劃需求的出發點也不再是“做了這個需求可以滿足什麼客戶”，而是要推理和假設一個需求能為整體客戶市場帶來什麼，然後去驗證他們；
- 從整個研發力量劃分出一個堅定的底線，客戶的一錘子需求不能夠超過特定的比例（例如一個季度不超過兩週的時間），所有的定製需求的需要的資源都不能超出這個資源池來獲取，需要銷售部門自行給所有客戶定製需求劃分優先級；
- 調整不同的激勵方式：例如銷售團隊通過銷售標準產品可以獲得完整的提成，但對於定製需求則需要按照實現成本的一定比例進行扣除；
- 謹記資源是有限的，有額外的東西安排進來，必定有其他工作被犧牲掉，這些犧牲掉的，可能是產品的長遠利益；
- 把定製工作從產品的核心中剝離開來，定製工作一定要按照定製工作的方式來定價，甚至可以考慮和專業的定製項目公司合作，把定製工作外包出去，由專業的人來處理專業的事，自己的產品團隊則專心在產品的核心；
- 客戶提出的需求也不是完全拒絕，而是要總結歸納出共性的地方，思考出有共性的產品方案來解決客戶的真實的痛點，可以用通用需求通過配置的方式來滿足一定的個性化需求，而不是通過定製，但是對這些解決方案要有足夠的耐心和投入足夠的精力進行學習和驗證。
總結
當公司盈利的時候，很多問題可能都不是問題（就像贏球可以掩蓋很多問題），但是當公司增長受困，作為產品經理，就要從產品的角度來分析和解決問題的根本所在了。
而銷售驅動的產品方式，對於2B公司來說的確是一個常見的因素（當然還有很多其他原因），要知道如何識別和解決這些問題，產品經理，是有責任去掃清產品發展的一切障礙的。
參考:
- RICH MIRONOV：《[The Slippery Slope of Sales-Led Development]》
- 阿朱：《走出軟件作坊》
- 白鴉：《SaaS業務的價值評估》
題圖來自 Pexels，基於 CC0 協議
閱讀更多 人人都是產品經理 的文章
