“三板斧”剖析To B產(chǎn)品版本管理與需求優(yōu)先級
?# 本文為人人都是產(chǎn)品經(jīng)理《原創(chuàng)激勵計劃》出品。
伴隨著產(chǎn)業(yè)互聯(lián)網(wǎng)的搭建與市場總體環(huán)境的變化,產(chǎn)品經(jīng)理的業(yè)務(wù)需求相應(yīng)有所調(diào)整。而在To B項目中,其用戶目標(biāo)群體、業(yè)務(wù)場景等也與To C有所不同。其中,產(chǎn)品經(jīng)理如何在復(fù)合場景下協(xié)調(diào)團隊合作分工、做好版本管理與需求優(yōu)先級排序?也許,你需要采取如下組合策略。
記得浙大管理課老師分享過一個故事:
愛因斯坦在普林斯頓任教時,周四下午剛結(jié)束大三期末考試,他拿起卷子匆忙離開,助教小跑著穿過操場追上他,善意地提醒道:教授,您是不是弄錯了,今年題目和去年是一樣的。愛因斯坦說:我知道題目和去年一樣,但是答案不同。
“題目相同,但是過了一年后正確答案不同”。
講這個故事是希望告訴產(chǎn)品同學(xué)們:產(chǎn)品經(jīng)理的職責(zé)和企業(yè)CEO是相似的——需要面對復(fù)雜的信息源、需要持續(xù)輸出正確的決策。
做決策本身就很難,更何況是持續(xù)做出高質(zhì)量的決策。
面對同樣的用戶,換個場景(地域/空間/時間)后,能滿足用戶需求的解決方案可能會發(fā)生變化,不再是現(xiàn)階段的最優(yōu)路徑。
一、我們的困惑:怎么做好版本管理與需求優(yōu)先級
上周和國內(nèi)頭部一家做ERP系統(tǒng)的朋友在閑聊,問到他們產(chǎn)品功能上線流程,發(fā)現(xiàn)與To C消費互聯(lián)網(wǎng)產(chǎn)品開發(fā)流程相比,有著非常明顯的差異。
ERP系統(tǒng)的作用是串聯(lián)和呈現(xiàn),將企業(yè)內(nèi)部所有涉及到跨部門協(xié)作的業(yè)務(wù)流程數(shù)字化,整套ERP系統(tǒng)功能龐大,一般按照客戶所處的行業(yè)特性來劃定具體的細(xì)分場景,每個細(xì)分場景的功能流程不同。
To C的產(chǎn)品,我們都被教育要習(xí)慣去關(guān)注用戶操作的行為數(shù)據(jù),根據(jù)數(shù)據(jù)反饋來相應(yīng)優(yōu)化功能。但是在ERP系統(tǒng)這一類B端產(chǎn)品里,你明知道有部分功能只有個別用戶在使用,也不能隨便下線或隱藏功能,功能模塊上下游的關(guān)聯(lián)銜接紛繁復(fù)雜,牽一發(fā)而動全身。
To B產(chǎn)品大而全有必然性的:SaaS廠商的會員客戶達(dá)到一定量后,都會主推支持低代碼、低成本開發(fā)的PaaS(如北森)平臺。即搭建開放平臺,支持客戶們個性化的功能需求。每個客戶都是獨立的,客戶擁有個性化配置一切的權(quán)利;我們要盡全力去實現(xiàn)每一個客戶的獨立和個性化,而不是限定他們一定要怎么樣。
To B產(chǎn)品滿足的是公司業(yè)務(wù)流程數(shù)字化的需求,多角色、跨職能的操作,如果只是單一場景下某個(單一)用戶角色的需求,導(dǎo)致解決方案變化的的影響因素少,產(chǎn)品經(jīng)理可以專注在核心的場景里解決問題,決策的難度大大降低。所以,很多做企業(yè)服務(wù)類產(chǎn)品的PM都會被版本管理與需求優(yōu)先級排序困擾,這個問題是普遍存在的。
二、問題根源:產(chǎn)業(yè)互聯(lián)網(wǎng)的特殊性
既然版本管理與需求優(yōu)先級是普遍存在的共性問題,我們就需要去分析問題背后的本質(zhì)原因,單純評價是產(chǎn)品經(jīng)理個人能力差異導(dǎo)致是不準(zhǔn)確且片面的。
下面我將分別從宏觀和微觀兩個視角分析,為什么產(chǎn)品人會對B端產(chǎn)品的需求管理與功能開發(fā)優(yōu)先級產(chǎn)生困惑。
1. 宏觀視角:消費互聯(lián)網(wǎng)和產(chǎn)業(yè)互聯(lián)網(wǎng)差異
《冰與火之歌》里有句著名的臺詞,“In the game of thrones, you win or you die”。
在消費互聯(lián)網(wǎng)的市場里,這句話是成立的。
比如做熟人社交通訊的微信一家獨大,其他產(chǎn)品幾乎不存在;但在產(chǎn)業(yè)互聯(lián)網(wǎng)里(如企業(yè)服務(wù)軟件市場),我們在美國看到了百花齊放的春天,大家耳熟能詳?shù)谋热鏢alesforce、Slack等等,國內(nèi)市場也是如此;從市場兼容性可以看出,產(chǎn)業(yè)互聯(lián)網(wǎng)和消費互聯(lián)網(wǎng)是有差別的。
消費互聯(lián)網(wǎng)更鼓勵高效運作。它的分工關(guān)系可以被設(shè)計出來,比如有一撥人做產(chǎn)品經(jīng)理,有一撥人負(fù)責(zé)把這個產(chǎn)品運營起來,還有一些設(shè)計師和工程師等,他們的分工相對來說比較成熟。
但產(chǎn)業(yè)互聯(lián)網(wǎng)它本身就已經(jīng)有了一個產(chǎn)業(yè)(現(xiàn)有的業(yè)務(wù)流程),它不是去創(chuàng)新,而是在這個產(chǎn)業(yè)當(dāng)中做一些改革,只是這個改革過程中有不確定因素。它鼓勵探索不同的邊界;相比消費互聯(lián)網(wǎng),產(chǎn)業(yè)互聯(lián)網(wǎng)更多的是強調(diào)由合作帶來對分工,這里的分工和合作關(guān)系很難被設(shè)計出來,基本上都要一次次地摸索和實踐。
2. 微觀視角:復(fù)合場景下對PM的能力挑戰(zhàn)
產(chǎn)業(yè)互聯(lián)網(wǎng)的產(chǎn)品經(jīng)理起初都是由技術(shù)工程師演變而來,比如制造業(yè)的ERP,他們懂代碼語言和技術(shù)框架,轉(zhuǎn)崗后可以良好地與技術(shù)團隊溝通,協(xié)助評估需求開發(fā)上線成本,避免了因為不懂技術(shù)而無法與技術(shù)人員溝通的問題。
另一個層面是:消費互聯(lián)網(wǎng)對產(chǎn)品經(jīng)理的能力要求是理解場景與用戶的行為路徑,更關(guān)注單個用戶的操作體驗,往往對于某一類客戶的抽象歸納能力很突出。但是對于產(chǎn)業(yè)互聯(lián)網(wǎng),做企業(yè)服務(wù)類產(chǎn)品的PM而言,要理解并發(fā)的多角色功能邏輯,在同一套系統(tǒng)里要能夠宏觀地看待跨部門協(xié)作的效率。
換而言之:企業(yè)服務(wù)類產(chǎn)品(to B)對于產(chǎn)品經(jīng)理的能力要求更高,需要具備處理復(fù)合場景下的并發(fā)功能的邏輯思維能力,同時要能夠理解客戶的業(yè)務(wù)訴求——產(chǎn)品不單單只是某個用戶的工具,而是連接組織內(nèi)部各線條的系統(tǒng),客戶需要的是整車方案,不是單個輪胎。
三、解決方案:可甜可咸的組合策略
B端產(chǎn)品需求的來源豐富,有客戶反饋、銷售團隊業(yè)務(wù)訴求、運營活動策劃所需、老板發(fā)來的競品參考。與其說咱們產(chǎn)品同學(xué)難在需求處理上,更直接說是難在公信力和話語權(quán)上——如何平衡各方的關(guān)系,需要處理得很微妙。就像戰(zhàn)備時期,所有戰(zhàn)力部隊向軍工廠要武器彈藥一樣,哪里都不能短缺,得排個優(yōu)先級,讓大家都能接受的結(jié)果。
1. 專業(yè)度:建立判斷機制,被廣泛認(rèn)可
由于之前踩過坑,我們在早期就開始建模型,形成內(nèi)部產(chǎn)品需求優(yōu)先級判斷標(biāo)準(zhǔn),產(chǎn)品同學(xué)接收到需求后,按照劃分的四個維度去歸類,根據(jù)“一大帶四小”的原則去快速啟動排期開發(fā)。如果功能上線后,用戶的使用反饋不達(dá)預(yù)期,排除其他因素,是需求的源頭出了問題,我們會組織內(nèi)部討論,修正更新判斷標(biāo)準(zhǔn)。
舉個實戰(zhàn)例子,當(dāng)接到個別客戶提出的需求時(判斷個性化需求or普遍存在的通用性需求),我們可以從以下五個維度評估:
- 疼痛的深度:個性化需求對于用戶而言,是不是剛需;優(yōu)先做“雪中送炭”的需求,再排期“錦上添花”的需求。
- 影響的廣度:是不是牽扯到上游和下游不同業(yè)務(wù)流程的完整性,如果有緊密關(guān)聯(lián),不處理則會影響用戶的正常操作,就像前面提到的釘釘績效考勤表。
- 尋找最大公約數(shù):是某個特別用戶的唯一需求,還是普遍存在卻被忽視的隱藏需求。產(chǎn)品要解決用戶普遍存在的問題,就好像數(shù)學(xué)上解題尋找最大公約數(shù),這一點也會涉及到公司商業(yè)模式,有些產(chǎn)品確實解決了用戶問題,但撐不起一家有體量的公司活得很滋潤。
- 關(guān)乎公司發(fā)展布局:有些需求必須開發(fā)不是單純?yōu)榱擞脩?,和公司的?zhàn)略發(fā)展決策有關(guān);比如剛剛提到的我們公司建立判斷模型,這個模型是動態(tài)的,跟著公司目前的發(fā)展節(jié)奏和行業(yè)所處生態(tài)位。
- 技術(shù)評估:除了以上四點外,還需要考慮一下技術(shù)層面,是否現(xiàn)有技術(shù)可以實現(xiàn),實現(xiàn)成本是否太高。
2. 修煉情商:管理(需求提出者)預(yù)期
看到標(biāo)題你應(yīng)該挺驚訝的吧?確實產(chǎn)品經(jīng)理需要具備高情商,畢竟工作內(nèi)容里有很大一部分是溝通協(xié)調(diào)職能。
最近在看各種銷售技巧類的書籍,里面大量提到了頂尖銷售人員對于情商的培養(yǎng)。而產(chǎn)品經(jīng)理和銷售的工作職責(zé)非常相似——面對用戶/客戶,把有形的產(chǎn)品或無形的服務(wù)推廣出去。
從神經(jīng)學(xué)的角度解釋,人的大腦皮層杏仁核會對周圍人或事物表現(xiàn)的敵意,做出抵抗或逃避的反應(yīng)。我們在討論需求優(yōu)先級排序時,如果不能通過控制杏仁核,就會引起對方的反抗意識——想想多少次跨部門討論需求時,大家爭得面紅耳赤?
除了抵抗和逃避,高情商的產(chǎn)品經(jīng)理反應(yīng)是哪一種呢?
他們會察覺到負(fù)面情緒的觸發(fā)點,很好地管控自己的情緒,“以退為進(jìn)”的溝通藝術(shù)。
3. 應(yīng)急機制:可咸可甜的團隊協(xié)作
SaaS先靠完整的產(chǎn)品來滿足大部分通用需求,再靠行業(yè)解決方案來滿足重點行業(yè)的個性化需求,最后靠把SaaS做成PaaS來滿足每個客戶的個性化需求??蛻糇銐蚨嗔酥?,圍繞著客戶繼續(xù)展開,可以做很多“增值業(yè)務(wù)”。
判斷自己在什么階段,重點做什么事情,是一種基礎(chǔ)的戰(zhàn)略能力。
如果產(chǎn)品經(jīng)理確定了版本迭代內(nèi)容與上線時間,在開發(fā)過程中,在大的迭代主題之外增加小功能需求的穿插開發(fā),前提是與技術(shù)團隊做好充分溝通,在不影響原定的開發(fā)時間下,幫助需求提出者處理好功能上線(記得和開發(fā)小哥們處理好關(guān)系,別硬剛)。
一些產(chǎn)品常識,希望大家避雷:
- 沒有人會看公告/通知。
- 沒有人會看系統(tǒng)消息和群發(fā)短信。
- 沒有人會改默認(rèn)設(shè)置。
- 沒人會沉浸式地看產(chǎn)品操作教學(xué)。
“產(chǎn)品是有生命力的流體,在宏觀市場環(huán)境與微觀場景中會發(fā)生動態(tài)變化。”
需求和需要的差異,我們通過用戶調(diào)研訪談,循著用戶表達(dá)的“需要”去挖掘隱性的需求。
“需要”不等于“需求”,需要是浮在表面的渴望,而需求是在具象的情境中發(fā)生的情緒感知。
#專欄作家#
大井蓋先生,公眾號:八點四十,人人都是產(chǎn)品經(jīng)理專欄作家。前某廠PM總監(jiān),現(xiàn)創(chuàng)業(yè)公司CEO;關(guān)注企業(yè)服務(wù)和金融賽道,愛好廣泛,歡迎一起交流探討產(chǎn)品或創(chuàng)業(yè)相關(guān)問題。
本文為人人都是產(chǎn)品經(jīng)理《原創(chuàng)激勵計劃》出品,未經(jīng)許可,禁止轉(zhuǎn)載。
題圖來自Unsplash,基于CC0協(xié)議。
井蓋大佬精準(zhǔn)概括了b端產(chǎn)品的特點,分享的方法論很有啟發(fā)性,感覺自己對b端產(chǎn)品的理解又有突破了。
多多交流~
學(xué)習(xí)
多交流
看到這里笑si————
沒有人會看公告/通知。
沒有人會看系統(tǒng)消息和群發(fā)短信。
沒有人會改默認(rèn)設(shè)置。
沒人會沉浸式地看產(chǎn)品操作教學(xué)。
哈哈哈,真話
學(xué)習(xí)了學(xué)習(xí)了
謝謝呀,多多交流
寫的不錯
謝謝~
需要和需求好像搞反了
沒有,哈哈哈,歡迎討論交流