近年來,我聽到了越來越多TO C衰退和TO B崛起的聲音。雖然我對這一說法有所保留,但我知道越來越多的同行正在考慮轉向TO B領域。作為一名經驗豐富的產品經理,我想分享一下關於TO B產品規劃的坑,並與各位同行互勉。
我相信很多 TO B企業市場的產品經理都會遇到這種情況——產品規劃中出現的一些功能都是專門針對特定客戶的「需求」。 當這種情況發生時,或許你的公司已經或即將進入「項目化」的產品開發路徑。
「項目化」的特點之一是產品研發的重點落在特定的客戶身上,以犧牲產品的核心價值創新、新功能、體驗改進和技術優化為代價。
使用這種「項目驅動」的產品最終會形成一個「四不像」,甚至會發現 「項目化」的產品越難越銷售了。 可怕的是,團隊常常沒有意識到他們為什麼會走到這一步,甚至沒有意識到出了什麼問題。 因此,我們要追本溯源,從根源上分析問題。
產品和項目
在說「項目化」之前,我們首先要弄清楚產品和項目的區別。與 TO C產品不同, TO B產品很容易混淆產品和定製項目,我們來看看有什麼不同。
---
?做項目,就是有一兩個程序員到客戶那駐場,你說你想做什麼我們就做什麼。你看行,驗收。你看不行,我們再改,認為沒有問題我們就回去。
?做產品,是標準的,不會特意為客戶修改。你覺得有幾點不符合需求不想買,我們也沒辦法,我們不會特意去按你需求來修改。你想買,那麼我們來安裝、對接吧。
---
最尷尬的是產品不是產品,項目不是項目。某個功能,是為張三做的。然後李四看起來不錯也想要,然後把張三項目代碼改一下,套給李四使用。這下麻煩了,公用的SAAS產品,某個功能既有張三的需求,又有李四的需求,然後後期可能還摻雜王五、趙六的需求,可想而知十分糟糕。
上面還只是技術代碼層面的視角,來分析混淆項目與產品的利弊。 我們再換個角度,看看在商業和財務視角上的區別。
產品型的公司銷售的是標準產品,一個產品可以反覆銷售給不同的客戶,使單位邊際成本低於單位價格,從而形成一個可持續的模式。 做產品的公司前期投資大,要賣出一定數量才能達到保本點,保本點後賣出絕大部分是純利潤。
項目型的公司則不同,每個項目都是獨立覈算,目的就是要確保每一個項目都有賺(不管是短期還是長期)。 客戶提出的需求越多,項目能賺到的錢就越多(當然,前提是客戶承認新需求所產生的工作量,這也要求項目經理有很高的管理水平),因此每個客戶的產品都是定製化的。
很多項目型公司都試圖將一些好的定製化需求整合至產品中,但通常很難有成效。新的定製項目常常會打斷所謂的「產品化」工作,因為可以立即賺錢。
產品和項目的模式沒有什麼優劣之分,通用需求和個性需求這兩者都可以賺錢。 但對於TO B產品,很容易不知不覺地進入一種混合模式:半定製軟體,需要不斷投入開發力量支持新需求,但又不是以項目的形式簽合同,報價往往強差人意,用這種方式發展的客戶也很難覆蓋二次開發的成本。
大多數時候我們遇到的困難,比如開發資源不能支撐大量的客戶的需求,銷售會認為開發效率低下做事慢,開發又覺得銷售胡亂承諾客戶給自己挖坑需求怎麼做都做不完。這些都是表面上的困難,問題的根源是混合模式在面對成千上萬的客戶下,是根本走不通。
「項目化」是如何形成的
接下來,我們梳理一下「項目化」模式是如何產生的,分為以下幾個步驟:
1.一般的產品化產規劃路線;
2.客戶定製「需求」的出現;
3.接下來發生的是混合反應
「產品化」路線規劃
一般來說,對於一個已經成型並驗證過PMF(最小化產品市場驗證)的產品,研發團隊應該將其分為四個部分,使產品穩定發展:
?可見的功能改進:新功能、用戶體驗和可用性改進、對競品功能的借鑒等;
?各種「基礎設施」和「性能增強」:可用性、可伸縮性、安全性等。
?各種「糾正、適應、預防、完善」:bug修復、測試用例、技術債務等等。
?持續改進與驗證:通過用戶調研、數據分析等來瞭解目標用戶,驗證思路,為下一步產品創新做好準備。
我們再來假設各個角色對這條路線的看法:
?市場和銷售希望產品有更強大的功能來滿足給客戶,因此他們會鼓勵不斷的新功能;
?技術人員最瞭解平臺的技術風險和缺陷,因此他們希望在架構、工具和重構上花費更多時間(也就是償還技術債務)。
?客服人員可大大減少客戶的投訴或問題,他們更支持bug修復、可用性改進,總之給客戶的問題越少越好;
?老闆希望他們的產品有進一步的突破,但他們往往把突破和創新視為個人努力的結果,而不是科學方法推進。(例如實驗與不斷試錯,這裡成本也不容低估)
作為一名產品經理,我們會將有限的(永遠缺人)研發資源均衡的分配到以上幾個方面,就像投資建立一個投資組合一樣,希望這個投資組合能夠讓產品更加穩定、可持續的發展。 就像魔獸一樣,攀科技和爆兵之間也要取得平衡才能獲勝。
因此,在經歷了許多困難之後,我們可能會根據下面的資源分配製定一個產品路線圖。