近年來，我聽到了越來越多TO C衰退和TO B崛起的聲音。雖然我對這一說法有所保留，但我知道越來越多的同行正在考慮轉向TO B領域。作為一名經驗豐富的產品經理，我想分享一下關於TO B產品規劃的坑，並與各位同行互勉。

我相信很多 TO B企業市場的產品經理都會遇到這種情況——產品規劃中出現的一些功能都是專門針對特定客戶的「需求」。 當這種情況發生時，或許你的公司已經或即將進入「項目化」的產品開發路徑。

「項目化」的特點之一是產品研發的重點落在特定的客戶身上，以犧牲產品的核心價值創新、新功能、體驗改進和技術優化為代價。

使用這種「項目驅動」的產品最終會形成一個「四不像」，甚至會發現 「項目化」的產品越難越銷售了。 可怕的是，團隊常常沒有意識到他們為什麼會走到這一步，甚至沒有意識到出了什麼問題。 因此，我們要追本溯源，從根源上分析問題。

產品和項目

在說「項目化」之前，我們首先要弄清楚產品和項目的區別。與 TO C產品不同， TO B產品很容易混淆產品和定製項目，我們來看看有什麼不同。

---

?做項目，就是有一兩個程序員到客戶那駐場，你說你想做什麼我們就做什麼。你看行，驗收。你看不行，我們再改，認為沒有問題我們就回去。

?做產品，是標準的，不會特意為客戶修改。你覺得有幾點不符合需求不想買，我們也沒辦法，我們不會特意去按你需求來修改。你想買，那麼我們來安裝、對接吧。

---

最尷尬的是產品不是產品，項目不是項目。某個功能，是為張三做的。然後李四看起來不錯也想要，然後把張三項目代碼改一下，套給李四使用。這下麻煩了，公用的SAAS產品，某個功能既有張三的需求，又有李四的需求，然後後期可能還摻雜王五、趙六的需求，可想而知十分糟糕。

上面還只是技術代碼層面的視角，來分析混淆項目與產品的利弊。 我們再換個角度，看看在商業和財務視角上的區別。

產品型的公司銷售的是標準產品，一個產品可以反覆銷售給不同的客戶，使單位邊際成本低於單位價格，從而形成一個可持續的模式。 做產品的公司前期投資大，要賣出一定數量才能達到保本點，保本點後賣出絕大部分是純利潤。

項目型的公司則不同，每個項目都是獨立覈算，目的就是要確保每一個項目都有賺（不管是短期還是長期）。 客戶提出的需求越多，項目能賺到的錢就越多(當然，前提是客戶承認新需求所產生的工作量，這也要求項目經理有很高的管理水平)，因此每個客戶的產品都是定製化的。

很多項目型公司都試圖將一些好的定製化需求整合至產品中，但通常很難有成效。新的定製項目常常會打斷所謂的「產品化」工作，因為可以立即賺錢。

產品和項目的模式沒有什麼優劣之分，通用需求和個性需求這兩者都可以賺錢。 但對於TO B產品，很容易不知不覺地進入一種混合模式：半定製軟體，需要不斷投入開發力量支持新需求，但又不是以項目的形式簽合同，報價往往強差人意，用這種方式發展的客戶也很難覆蓋二次開發的成本。

大多數時候我們遇到的困難，比如開發資源不能支撐大量的客戶的需求，銷售會認為開發效率低下做事慢，開發又覺得銷售胡亂承諾客戶給自己挖坑需求怎麼做都做不完。這些都是表面上的困難，問題的根源是混合模式在面對成千上萬的客戶下，是根本走不通。

「項目化」是如何形成的

接下來，我們梳理一下「項目化」模式是如何產生的，分為以下幾個步驟：

1.一般的產品化產規劃路線;

2.客戶定製「需求」的出現;

3.接下來發生的是混合反應

「產品化」路線規劃

一般來說，對於一個已經成型並驗證過PMF（最小化產品市場驗證）的產品，研發團隊應該將其分為四個部分，使產品穩定發展：

?可見的功能改進：新功能、用戶體驗和可用性改進、對競品功能的借鑒等;

?各種「基礎設施」和「性能增強」：可用性、可伸縮性、安全性等。

?各種「糾正、適應、預防、完善」：bug修復、測試用例、技術債務等等。

?持續改進與驗證：通過用戶調研、數據分析等來瞭解目標用戶，驗證思路，為下一步產品創新做好準備。

我們再來假設各個角色對這條路線的看法：

?市場和銷售希望產品有更強大的功能來滿足給客戶，因此他們會鼓勵不斷的新功能;

?技術人員最瞭解平臺的技術風險和缺陷，因此他們希望在架構、工具和重構上花費更多時間(也就是償還技術債務)。

?客服人員可大大減少客戶的投訴或問題，他們更支持bug修復、可用性改進，總之給客戶的問題越少越好;

?老闆希望他們的產品有進一步的突破，但他們往往把突破和創新視為個人努力的結果，而不是科學方法推進。（例如實驗與不斷試錯，這裡成本也不容低估）

作為一名產品經理，我們會將有限的(永遠缺人)研發資源均衡的分配到以上幾個方面，就像投資建立一個投資組合一樣，希望這個投資組合能夠讓產品更加穩定、可持續的發展。 就像魔獸一樣，攀科技和爆兵之間也要取得平衡才能獲勝。

因此，在經歷了許多困難之後，我們可能會根據下面的資源分配製定一個產品路線圖。

路線圖看起來不錯，老闆同意了。 然而，幾天後，銷售團隊報告說，一個大客戶有一個「小功能」，需要定製，噩夢慢慢開始了……

「XX客戶希望實現此功能」

用戶提出新的功能需求是很正常的。在 TO C產品或面向小B的產品上，用戶數以萬計，單個用戶的意見不會直接影響我們產品路線的變化。 產品團隊將廣泛吸收從各個方面收集的優化點，這些優化點可能來自用戶的直接反饋、數據收集與分析、行業與環境的觀察、競品分析等。 簡而言之，很難想像單個用戶可以影響產品路線的情況。

但對於企業市場來說，客戶的規模可能會很大，集團、上市公司之類的不缺錢。一個客戶單年的合同很可能會佔到公司單年總收入的10%。 在這種情況下，單個客戶對產品決策的影響要比 TO C或B大得多。 這些客戶經常向銷售人員提出自己的個性化要求，包括：與客戶其他系統的集成、流程調整、報表定製等;

銷售人員將如何處理這些需求? 首先，讓我們看看銷售人員的優勢和思維模式：

?銷售人員一般都是樂觀、不輕易言棄，而且特別善於與人打交道，能輕易在組織中找到推動事情前進的關鍵人物;

?善於忽悠：通過他們強大的忽悠能力，把產品的功能說得能滿足他們大部分的業務場景（例如一個OA產品可以當成新聞資訊產品來賣），然後進行投標;

?銷售人員的績效考覈標準非常簡單粗糙：簽單成功(有點像國足，沒有進球的話，連喝水都是錯);

?對銷售人員的激勵(銷售傭金)政策，使得他們只專註於自己的客戶和銷售商機。

因此，當客戶向銷售人員提出不屬於產品路線圖的需求時，銷售人員自然會要求產品經理額外實現該功能。 通常，他們得到的IT團隊的答覆是「我們把它記錄下來，下個版本再考慮吧」或者「暫時安排不了」，而不是「好需求，我們馬上出方案安排人員實現」。

當產品經理天真地認為他們已經應付過去時，不要忘記銷售人員不輕易言棄和他們善於說服、找關鍵人物解決的特點。這些特性可以很容易籠絡外部的客戶，自然地，也可以影響內部管理層，然後管理層會從銷售人員那裡聽到：

「這個客戶對我們來說是一個重要的大客戶，具有戰略重要性。只要完成了這些需求，客戶就能簽下來（或就答應給錢）。」

「需求很簡單」

「這個客戶知道自己想要什麼，將成為我們市場的標杆客戶。」

「我們不是採用敏捷開發嘛，開發計劃應該是響應需求變化的，調整一下開發計劃就行」；

「這是一個共性的市場需求，不是單個客戶的需求，我們談過很多客戶，他們都想要這個功能，這個功能其實早就該實現了。」

這些理由聽起來都很合理(我們也希望是真的合理)，而且因為銷售團隊把所有的時間都花在客戶身上，他們覺得自己知道客戶真正需要的是什麼。

然後推論就變成了，因為這些客戶對我們很重要，我們必須想辦法投入更多資源來為他們服務。然後，我們的整體產品規劃將讓位於這些具體的客戶需求。 即使產品經理想據理力爭，在管理層看來更像是推脫的說辭（對比銷售人員）。常見的原因包括：

?沒有人手可以做這些需求了;

?如果要這樣做，原計劃中的XXX和XXX就要延後。

?客戶不瞭解我們系統的情況，這個需求我們以前做過類似的，初步判斷工作量很大。

?如果這是一個通用需求，我們早就將它列為高優先順序的需求了;

然而，這些反對意見通常沒有什麼用處，我們仍然需要將這些需求加入到我們的產品路線圖中。在我們之前分析過的幾類工作中，只有最後一種工作「學習和驗證」相對來說是最不迫切的，抽調這部分工作的人員，在短期內影響是最小的。於是，新的資源組合會變成下圖這樣。

這看起來並不是什麼大問題(儘管犧牲了一些長遠收益)，但事情並不總是那麼簡單。 當我們真正開始開發這些定製的需求時，我們將不斷發現新的狀況：新的流程需要更改我們現有的數據流、客戶現有系統採用非標準對接方式。一些看似簡單的UI個性化需要以一種靈活配置的方式重寫，或者變成要維護兩組代碼，等等。

當然，還有最坑的，其實客戶自己一開始也沒搞清楚或說清楚，做了還是要改。然後，你還必須按照客戶期限交付產品，其中包含大量的技術債務，甚至只安排了冒煙測試就算通過了。

這種定了期限而交付新功能的產品，往往會令我們忘記（或迴避）驗證其需求背後意義和真實性。其實到了這裡，我們的資源組合已經是這樣的。

但是好消息是經過一大輪的工作，我們在截止日期前交付了功能和產品。客戶很快地簽合同（或驗證）付款。老闆，產品，研發，銷售都很開心。

此時此刻，你認為我們能回到原來的產品路線圖中嗎? 事情沒那麼簡單。

進入「項目化」模式

通過這個「成功故事」，管理層和銷售人員瞭解到產品和開發部門能夠定製客戶的需求，並且這種方法(看起來)對公司沒有任何損失。一旦這一先例確立，它將成為常態。

其他銷售人員開始奴性地承諾客戶能定製功能(一般還帶上時間節點)，以便順利地完成他們的銷售目標，甚至管理層將開始要求研發部門優先完成這些「客戶需求」，因為能馬上收錢。其他項的資源組合，將進一步擠壓，最終變成下圖的情形。

因此，我們的產品開發決策模型已經從考慮整個市場，轉變為每一個立刻出績效的定製化功能的合同讓路。單獨來看，每一個決策似乎沒什麼問題，但整個產品線不知不覺地陷入了一個短期效益最優的無限循環中：

此時，一系列的連鎖反應發生和爆發，如下：

?需求來自不同的客戶，有嚴格的時間限制，根本沒時間做出有效的解決方案。因為定製的功能只是「頭痛醫頭、腳痛醫腳」，這些功能點往往沒有真正的戰略價值，需求的碎片化已經影響到產品的內部一致性和長期發展的能力;

?產品經理從「產品BOSS」轉變為對客戶需求作出響應的人，變成真正的客戶服務項目經理或原型/需求設計師，不再主動思考和規劃產品;

?開發人員/設計人員失去動力，因為他們被迫接受客戶的需求和時間點，而不是以學習和探索的方式開發產品。 而這些客戶在完成需求後很少會有正面的反饋(一般是出bug或故障才找你);

?銷售團隊會慢慢發現日子不太好過，客戶還是會不斷地提出新的定製需求，而且要求越來越多。定製需求都只能排長隊，或者拆東牆補西牆，不再像以前一樣快速響應客戶，繼續使用這種方式來獲得新客戶也將越來越困難;

?整個公司的利潤率將下降。軟體產品的商業模式的核心是邊際成本很低，但以目前的方式，既不是產品也不是一個項目，軟體的使用租金很可能也覆蓋不了客戶定製的成本;

?市場份額增長緩慢，因為沒有新的亮點可以拓展到新的市場，產品讓位於定製化。

衝突將開始爆發，然後大家就會「急病亂投醫」——」產品經理應該更快地響應客戶的需求，即使先扔個方案來響應。」，「是開發的效率太低了，能不能讓他們加加班趕下進度「 「銷售能不能不亂挖坑嗎？需求有完沒完」

然而，這些都不是問題的根源。

根本原因在於組織形式與利潤模型不匹配：重點客戶的需求是最優先，以為是做產品，實際上演變為做項目。犧牲了為廣闊的市場規劃需求和研發產品的能力，為一棵樹放棄一片森林。

如何解決這個問題

上述問題屬於系統性問題，單靠產品、研發或銷售人員的力量是無法解決的，應通過以下方式與管理層進行開誠布公的討論和解決：

(1)確定自己是否處於「項目化」狀態：全面分析產品的運營和銷售是否遇到瓶頸，新客戶的獲取是否越來越依賴於定製化開發? 我們可以把近期的研發資源(例如近一個季度)進行分析。有多少比例是用來為單個客戶定製功能，以及所謂的「增加通用功能來提高產品競爭力」實際上只有一個或兩個客戶使用? 新功能是否跳過了需求驗證步驟?

(2)公司究竟是通過產品還是項目來滿足市場需求? 深入分析自己所在行業的需求，最終能夠滿足需求的是通用型產品，還是需要做一個定製的項目。嘗試用兩者折衷的方式是很難取得好效果的。

(3)如果是一個定製的項目，就應該按照項目模式來報價。然後用專業的項目管理方法來響應客戶的需求。不要幻想依賴客戶定製需求來組合成通用產品，雖然不是不可能，但是就像刮彩票的概率。中了當然算賺到，但企業經營總不能靠彩票運作吧。

通過定製化項目的方式，還可以利用專門的研發力量創建平臺和工具(如PaaS或流行的中臺概念)，提高整體研發效率。

(4)對於標準產品，要正視問題，對「項目化」問題進行管理，以運營產品的思路對產品進行規劃和管理，如：

?從用戶拉新、轉化、留存等角度來考慮產品，盡量優化自己的整體LTV和CAC; 規劃需求的出發點不再是「做這個需求可以滿足什麼客戶」，而是推斷和假設一個需求可以給整個客戶市場帶來什麼價值，然後驗證。

?制定一個可定製化工作量底線，客戶的定製需求比例不能超過特定比例(例如，一個季度不超過兩周工作量)。如果要增加新的定製需求，那麼就要剔除舊的定製需求到下一期實現;

?調整激勵方式：例如銷售團隊可以通過銷售標準產品獲得完整的傭金，但銷售有定製需求的產品則按開發工作量折算比例，例如少20%傭金;

?資源是有限的，有新需求加入到需求池中，必定有其他的需求要犧牲。犧牲的需求，可能影響著產品的長遠利益;

?將定製需求的產品與標準產品分離，根據定製的內容報價，甚至可以考慮與外包公司合作。

?客戶的需求也不是全盤拒絕，而是總結出共性的需求，思考通用的產品方案來解決客戶真正的痛點。例如增加配置化的模塊去滿足一定的個性化需求，而不是去定製功能。

結論

當公司盈利的時候，很多問題可能不是問題(就像贏了可以掩蓋很多問題一樣)，但是當公司成長遇到問題的時候，作為產品經理，一定要從產品的角度去分析和解決根本問題。

推薦閱讀：