經驗分享:2B產品工作中的那些坑
本文從2B產品的工作流程去講,做產品路上都遇到的那些坑以及避坑方法。
我是從2017年底,轉入了2B產品的坑,之后在同一條產品線,經歷了20+個項目,做的基本都是大客戶的私有化部署項目,并且在今年負責把這條產品線帶入了SaaS的軌道。所以想借這篇文章,為各位想要做2B或剛剛開始做2B的產品萌新,說明一下2B產品工作中,那些你可能會遇到的坑,以及應對的思路。
這篇文章的敘述思路基本會按照2B產品的工作流程去講,但我暫時不講方法論,那會有點虛,我想更直白一些,告訴你當你到達這個工作階段后,你可能會遇到什么問題,解決的思路是什么,也算是對我這兩年產品工作的一個梳理。OK,let’s go!
一、產品立項階段
我也不是謙虛,怎么就讓我上了呢?
其實作為一個產品新人,一般是不會需要你去做產品立項的工作的,但我們實際會遇到的情況是什么呢?想想一下這個場景:你的直屬領導語重心長地拍著你的肩膀對你說的“小M啊,這里有一個項目/一條產品線,我們決定做,我看你骨骼驚奇,這個任務就交給你了”。
你:“???”我也不是謙虛,怎么就讓我上了呢?
OK,不管怎么樣,現在任務已經到了你手上,操起鍵盤就開始干嘛?不不不,如果這是一條新的產品線,那你需要向你的直屬領導了解清楚,公司為什么要立這個項目?公司的戰略是什么?當然不需要你設計公司戰略,但是至少需要了解一下,假設是想要增加公司盈利能力,那你就踏踏實實去跪舔(可太真實了)大客戶。
如果這不是新的產品線了,你一樣需要去了解市場上的競品,他們是誰?他們在哪里?他們的優勢是什么?他們的噱頭又是什么?一般2B的產品不會像2C的,那么容易就能了解到競品是怎么做的,但我們依然有辦法……比如假裝自己是某一家公司的員工,需要購買這一領域的產品,以這樣的借口去接觸競品公司的銷售,獲得體驗他們產品的機會,方法總比問題多嘛。
另外需要建議你的是,在調研競品的時候眼光最好開闊一些,比如你們做的是客服系統,那你就不要只盯著市場上做客服系統的公司,相鄰領域或者上下游的產品隨時有可能跨界。最好再看看做CRM的、做呼叫中心的、做IM的公司,他們又在干什么。
調研完競品,記得回過頭來想想自己,“我們現在做的怎么樣?我們的優勢?劣勢?機會?威脅?”你不用要求自己能一上手就把這些問題想明白,但你要時時刻刻都想著這些問題,市場的每一次變化,都有可能產生新的機會。
另外你的調研將會使你對競爭對手知己知彼,這會在你與客戶接觸時提供幫助,這部分內容我會在其他模塊介紹。
二、產品需求階段
客戶教你怎么做產品
作為2B產品,你的需求最有可能就是來源于你的客戶,但是從這里開始,就會很大程度上體現出我們與2C產品之間的區別來了。2C產品,可能不知不覺間影響了你的用戶;2B產品,則會被客戶摁在地上來回摩擦。
你會發現這樣一個問題,當你接到了項目,你的客戶就開始對產品指手畫腳了,他們永遠都企圖教你怎么做產品,他們提給你的不是需求,他們提給你的是他們認為最好的解決方案。
所以你需要有這樣一個意識:既然我是這個產品的產品經理,那我就得是這一領域的專家——比如你們做的是CRM,那你就得是營銷領域的專家。當然很有可能你現在真的不是專家,我也不是專家,但你得有這樣的意識,你需要往這個方向去發展,這會讓你不被客戶摩擦嗎?不,但這至少能讓你被摩擦得更有尊嚴一點。
實際更有意義的解決方案是什么呢?當客戶告訴你他需要什么的時候,問他為什么,了解他提出的方案背后想要解決的問題。
這件事至關重要,并且還有幾個相關的點,也是我必須告訴你的:
- 第一,請打破砂鍋問到底,客戶想要解決的問題可能拐了好幾個彎,他自己都沒發現,但你作為專家需要能夠通過提問找到背后真正的問題;
- 第二,務必要找到原始需求,以及提出原始需求的人,你的需求可能是銷售、項目經理、項目對接人轉述給你的,他們的話聽過就可以了,但你一定要找到最原始的起點,不然你可能會把團隊這艘船帶到陰溝里去。
記住我們的目標,用最合適的解決方案滿足你的用戶,并且交付項目。
工作似乎永遠在救火
好的,假設你終于在和客戶的交鋒中沒有敗下陣來(敗了也沒關系,你得至少比小強更堅強才能做好這份工作),現在你會發現又一個問題,我靠,需求也太多了吧?
一個項目幾十條需求是最少的,作為優秀的產品經理,你理所當然會同時面對N個項目——你痛苦地發現,所有客戶都是爸爸,所有項目都要打造成標桿,而你的工作,也永遠都在救火。
如果你是在一家大公司,那這個問題可能不會碰到,但如果你是在一個創業公司或者小團隊,那這個問題就太常見了。怎么辦?向大公司學習?。W習如何做好需求管理,并且請一定用上你覺得順手的管理工具,記清楚需求,理清楚優先級。Excel也沒關系,不要嫌它原始,只有工具才能保證信息明確、可同步、可更改,不然你就只能祈禱你救火的步伐跑得足夠快吧。
三、產品設計階段
?踏實去想,踏實去做
這個階段,對于2B產品來說,大概率不需要你有什么天馬行空的創業,獨出心裁的設計,你需要做的事,就是踏踏實實把業務了解清楚。
你面對的問題涉及到業務中哪些角色?他們彼此是怎樣的關系?他們關心什么?他們會做什么?怎樣的行為將他們串聯起來?認真向你的客戶確認這些信息,把業務模型畫下來。需要畫到什么程度?讓任何人都能一眼看明白這個業務是怎么一回事。
信息結構圖、產品結構圖,這些步驟請不要跳過,但是對于原型,你可能會有一個問題:高保真還是低保真?事實上,我的回答只能是:看情況,這需要看你和你的研發/測試是怎么配合的,我們重要的不是產生哪種格式的文檔,而是讓我們的方案能夠與研發/測試達成一致,沒有偏差。
方案設計好了,可以評審進入研發階段了嗎?請等一等,如果你正在做的項目,是一個重要的客戶,那我用我血淋淋的教訓告訴你,請一定和你的客戶確認你的方案,并留下書面的記錄(比如郵件的確認信息,但是微信聊天可不算?。?!不要覺得wtf,我是產品經理,方案怎么做難道不是我說了算?在C端,你的方案有點偏差,可能用戶都發現不了,但是在B端,哪怕有一個字段有問題,都有可能導致整個產品無法被使用到工作中。作為一個位高權重的產品經理,在這種關鍵時刻,你一定不介意跪舔一下你的客戶,對吧?
?好兄弟需要一起被摩擦
在進入產品開發的過程中,你往往會遇到這樣一個問題:你的上帝從客戶變成了研發。在你被客戶摩擦完之后,接下來你又需要遭受研發的毒打,社會真是太殘酷了,不是嗎?即使你的方案能夠讓客戶點頭,讓石頭開花,對于研發來說,他們大概率會認為你設計的是狗屎。
我不建議你在需求評審上和研發互噴,畢竟你可能要以一敵十,一個更好的辦法是,拉著你的研發好兄弟一起被客戶摩擦。
不是要你搶占研發寶貴的碼代碼時間去讓他們做自虐狂,而是讓你的團隊明白需求,不要上來就告訴他們要做什么方案(還記得我們畫的業務模型嗎)。
?四、產品開發階段
?不要依賴你的項目經理
產品進入開發了,一般在B端,我們會有項目經理,對項目的交付負責,把控項目的進度,但我的提議是,不管在開發階段也好,上線階段也罷,不要依賴你的項目經理,你最好能做到自己來管控全局。你需要在整個開發與測試的過程中注意兩個問題:能不能按時交付?是不是我要的產品?
關于時間,我建議你最好為你的項目創建里程碑,越細越好,同步給你的研發與測試團隊,將馬拉松賽跑式的一個季度/半年/一年時長的項目(這并不少見),以許多個細分的里程碑管理起來,如果每一個里程碑都能按時達成,那整個項目就不會出現太大的風險。這里還有一定需要注意,反饋風險不要等到里程碑到來的時候再反饋,理論上在距離里程碑還有一半時間時,如果有人覺得無法達成,就需要反饋出來,方便團隊及時調整,必要時,甚至可以每天15分鐘站會,確認項目進度。
關于產品,如何保證你向研發要個蘋果,他們不會給你一個梨(有的時候,能給你一個梨還算好的了)?除了在需求評審階段,大家能夠互噴到位以外,你最好有足夠厚的臉皮,在每一個里程碑,甚至每一天去確認產品開發的情況——你得時時刻刻明確大家在往蘋果的方向走。既然已經被客戶摩擦過了,你一定不會介意再被研發和測試摩擦了對吧?他們越是覺得頻繁的確認沒有必要,你就越要提高警惕,明天和意外,誰也不知道哪個會先到來。
?五、產品上線階段
?每一個項目都需要確認
項目上線了,產品經理可以拍拍屁股了嗎?當然不可以,你至少還有這樣幾件事要確認:管理產品版本、客戶培訓、銷售材料更新、復盤項目。
這些事情不一定需要你來完成,但我覺得你至少需要參與制定這些事情處理的流程,讓我一件一件事告訴你可能出現的問題吧。
產品版本的管理很重要,請一定要落實到實處,什么叫落實到實處?當項目經理需要給客戶發版本的時候,他能夠很明確的說出“我需要發布公版1.x.x版本”,而不是說“給客戶發一個XX項目一樣的版本”。如果你的項目經理說出后者這種話,我覺得你們最好先停下腳步,把團隊內部的流程整理清楚。
客戶培訓和銷售材料更新需要及時,如果不小心把一份過時的銷售材料發給了客戶,你會花更多的時間來彌補錯誤的。
最后,記得為項目做復盤。大多數時候,如何才能交付項目,是很明確的:可能是需要在要求的時間內,完成并交付特定的需求;可能是需要將效果達到客戶要求的標準。不管這個項目交付得順利與否,在完成后記得回頭分析完成情況,維度有很多,甚至可以專門一篇聊復盤,所以我就不在這里展開了。
六、其他
吹下的牛X都要圓
我想有一件事是你逃不掉的,售前工作。
Yes,我知道有的公司可能有專門的售前崗位,但是大多數時候,也需要產品參與進售前的工作中。相信我,這會很累,你可能經常需要出差,但是這總比當項目都要正式開始了你才被動介入要好。
售前工作,簡單直接的解釋就是,吹牛X。但吹也有技術含量對不對,在仰天長嘯出門吹牛X之前,你最起碼需要做到以下幾點:
1. 搞明白客戶的基本狀況,這些信息你可以向銷售了解,他們的業務是怎么樣的,為什么需要這個產品,之前是否用過相同的產品,訴求是什么?
2. 做好完善的準備,銷售材料記得帶齊,白皮書和PPT是至少的,如果客戶意向比較高,你們覺得有戲,那最好做一份針對性的PPT,讓客戶能夠感受到你們的誠意。
3. 還記得立項階段讓你了解的競品嗎?
再回顧一遍,因為你的客戶可能已經了解過這些產品了,甚至更大的可能是你的競爭對手已經捷足先登,比你更早接觸了客戶。
所以此時你和客戶的溝通,不僅要在有限的時間內,告訴你的客戶,如何使用你們的產品與解決方案,幫助他們解決問題、產生收益;更進一步最好能在潤物細無聲的情況下,讓你的客戶意識到,你的產品比競品更好。
如果競品捷足先登,你或許能夠從客戶的訴求中察覺到蛛絲馬跡(也許他們會問你,有沒有XX功能,能否實現XX需求,而這些XX都是競爭對手在宣傳的噱頭),記得靈活調整自己的話術,在信息不足的情況下也不要露怯。
但是還有一件事要記?。耗阍诳蛻裘媲按迪碌拿恳粋€牛X都是需要你自己去圓的。請不要吹牛一時爽,交付火葬場,這也是我認為產品需要參與到售前工作中的原因。如果是銷售或者售前在給客戶吹牛,而產品不在場,那場面可能會更加失控,并且讓你在接到這個項目,了解到客戶的需求后,想要與銷售/售前同歸于盡。
七、最后
我認為2B產品相比2C,說實話苦逼得多,我們很少會有什么高光時刻,更多的時候是一步一個腳印去踏實交付掉每一個項目,服務好每一家客戶,打造好我們的品牌。
今天或許有人會告訴你,企業服務是風口,我覺得你最好不要把這些話放在心上,路漫漫其修遠兮,我們只是提供服務的踐行者。
本文由 @misbone 原創發布于人人都是產品經理,未經許可,禁止轉載
題圖來自 Unsplash,基于 CC0 協議
謝謝分享,認真收藏了好文。想請教個問題,2B產品中,你們產品經理、項目經理、研發之間是怎么協同的?盼復。
我的理解,協同來源于對規則的確認與執行。事實上,不同的團隊,協同的方案都是可以有差異的,并不存在一定最好的方式。重要的是大家能對一份統一制定的協同規則/流程沒有疑問,并且嚴格執行。如果由于環境變化導致流程不適用了,快速迭代就行。
?? 寫出真情實感了
雖然沒說什么方法論,但是還是很符合toB產品經理的處境的,在toB項目中打磨好之后,如何轉型成toC產品經理,想請教下
2B和2C是兩回事,所以 在toB項目中打磨好之后,轉型成toC產品經理 這條鏈路本身就我的理解,是很難成立的……或許大佬們能有一定理解吧
優秀的產品經理,需要像你這樣有獨特的幽默感!產品協同上也會有更有樂趣順暢 !
——好文!耳目一新
厲害了,TOB半年,少走很多坑
有趣,有料!關注一波!
b端是趨勢。c端很常見,范圍廣,
b端才是主心骨,c端是建立在b端規范的基礎上運作。
沒毛病
寫的邏輯清晰,語言幽默哈哈??被客戶摩擦,與開發一起被客戶摩擦,與售前同歸于盡??非常生動形象地說出產品人的心里話哈哈。不過假如售前給客戶吹的太過牛x那也就只能產品在后期溝通需求細節時降低客戶的期望值了。全文最喜歡的一句話就是:明天和意外,你永遠也不知道哪個會先到??
學習了
一時吹牛一時爽,時時吹?;鹪釄?。學習了,去年還在評審會上跟開發互懟,今年逐步能達成一致。明年準備拉上開發去感受來自前線的摩擦!
好厲害 ?? 我也做了差不多1年的TO B產品,感同身受,仔細想想還真是那么回事,但是卻沒有你這么總結的很細致,還要好好學習,總結經驗 ??
我比較關注兩個數字,兩年、20+項目;一個B端項目少則兩三月,長則至少一年以上
我做了一個半年前至今的。。。。
正常啊 項目周期短+并行沒問題
對頭,一個是項目并行,然后我們也有項目是直接用標品交付的,畢竟做了項目也得有積累對吧
不錯不錯
寫的很好,點贊。
哈哈哈,寫的都是每天的工作。
我就是一個2B產品
尼瑪最近面試,有人說做b端的公司根本算不上互聯網公司…
很常見的…
那說明說這句話的人對互聯網的理解還停留在5年前
哎 傷不起