“三板斧”剖析To B產品版本管理與需求優先級

12 評論 9086 瀏覽 37 收藏 14 分鐘

?# 本文為人人都是產品經理《原創激勵計劃》出品。

伴隨著產業互聯網的搭建與市場總體環境的變化,產品經理的業務需求相應有所調整。而在To B項目中,其用戶目標群體、業務場景等也與To C有所不同。其中,產品經理如何在復合場景下協調團隊合作分工、做好版本管理與需求優先級排序?也許,你需要采取如下組合策略。

記得浙大管理課老師分享過一個故事:

愛因斯坦在普林斯頓任教時,周四下午剛結束大三期末考試,他拿起卷子匆忙離開,助教小跑著穿過操場追上他,善意地提醒道:教授,您是不是弄錯了,今年題目和去年是一樣的。愛因斯坦說:我知道題目和去年一樣,但是答案不同。

“題目相同,但是過了一年后正確答案不同”。

講這個故事是希望告訴產品同學們:產品經理的職責和企業CEO是相似的——需要面對復雜的信息源、需要持續輸出正確的決策。

做決策本身就很難,更何況是持續做出高質量的決策。

面對同樣的用戶,換個場景(地域/空間/時間)后,能滿足用戶需求的解決方案可能會發生變化,不再是現階段的最優路徑。

一、我們的困惑:怎么做好版本管理與需求優先級

上周和國內頭部一家做ERP系統的朋友在閑聊,問到他們產品功能上線流程,發現與To C消費互聯網產品開發流程相比,有著非常明顯的差異。

ERP系統的作用是串聯和呈現,將企業內部所有涉及到跨部門協作的業務流程數字化,整套ERP系統功能龐大,一般按照客戶所處的行業特性來劃定具體的細分場景,每個細分場景的功能流程不同。

To C的產品,我們都被教育要習慣去關注用戶操作的行為數據,根據數據反饋來相應優化功能。但是在ERP系統這一類B端產品里,你明知道有部分功能只有個別用戶在使用,也不能隨便下線或隱藏功能,功能模塊上下游的關聯銜接紛繁復雜,牽一發而動全身。

To B產品大而全有必然性的:SaaS廠商的會員客戶達到一定量后,都會主推支持低代碼、低成本開發的PaaS(如北森)平臺。即搭建開放平臺,支持客戶們個性化的功能需求。每個客戶都是獨立的,客戶擁有個性化配置一切的權利;我們要盡全力去實現每一個客戶的獨立和個性化,而不是限定他們一定要怎么樣。

To B產品滿足的是公司業務流程數字化的需求,多角色、跨職能的操作,如果只是單一場景下某個(單一)用戶角色的需求,導致解決方案變化的的影響因素少,產品經理可以專注在核心的場景里解決問題,決策的難度大大降低。所以,很多做企業服務類產品的PM都會被版本管理與需求優先級排序困擾,這個問題是普遍存在的。

二、問題根源:產業互聯網的特殊性

既然版本管理與需求優先級是普遍存在的共性問題,我們就需要去分析問題背后的本質原因,單純評價是產品經理個人能力差異導致是不準確且片面的。

下面我將分別從宏觀和微觀兩個視角分析,為什么產品人會對B端產品的需求管理與功能開發優先級產生困惑。

1. 宏觀視角:消費互聯網和產業互聯網差異

《冰與火之歌》里有句著名的臺詞,“In the game of thrones, you win or you die”。

在消費互聯網的市場里,這句話是成立的。

比如做熟人社交通訊的微信一家獨大,其他產品幾乎不存在;但在產業互聯網里(如企業服務軟件市場),我們在美國看到了百花齊放的春天,大家耳熟能詳的比如Salesforce、Slack等等,國內市場也是如此;從市場兼容性可以看出,產業互聯網和消費互聯網是有差別的。

消費互聯網更鼓勵高效運作。它的分工關系可以被設計出來,比如有一撥人做產品經理,有一撥人負責把這個產品運營起來,還有一些設計師和工程師等,他們的分工相對來說比較成熟。

但產業互聯網它本身就已經有了一個產業(現有的業務流程),它不是去創新,而是在這個產業當中做一些改革,只是這個改革過程中有不確定因素。它鼓勵探索不同的邊界;相比消費互聯網,產業互聯網更多的是強調由合作帶來對分工,這里的分工和合作關系很難被設計出來,基本上都要一次次地摸索和實踐。

2. 微觀視角:復合場景下對PM的能力挑戰

產業互聯網的產品經理起初都是由技術工程師演變而來,比如制造業的ERP,他們懂代碼語言和技術框架,轉崗后可以良好地與技術團隊溝通,協助評估需求開發上線成本,避免了因為不懂技術而無法與技術人員溝通的問題。

另一個層面是:消費互聯網對產品經理的能力要求是理解場景與用戶的行為路徑,更關注單個用戶的操作體驗,往往對于某一類客戶的抽象歸納能力很突出。但是對于產業互聯網,做企業服務類產品的PM而言,要理解并發的多角色功能邏輯,在同一套系統里要能夠宏觀地看待跨部門協作的效率。

換而言之:企業服務類產品(to B)對于產品經理的能力要求更高,需要具備處理復合場景下的并發功能的邏輯思維能力,同時要能夠理解客戶的業務訴求——產品不單單只是某個用戶的工具,而是連接組織內部各線條的系統,客戶需要的是整車方案,不是單個輪胎。

三、解決方案:可甜可咸的組合策略

B端產品需求的來源豐富,有客戶反饋、銷售團隊業務訴求、運營活動策劃所需、老板發來的競品參考。與其說咱們產品同學難在需求處理上,更直接說是難在公信力和話語權上——如何平衡各方的關系,需要處理得很微妙。就像戰備時期,所有戰力部隊向軍工廠要武器彈藥一樣,哪里都不能短缺,得排個優先級,讓大家都能接受的結果。

1. 專業度:建立判斷機制,被廣泛認可

由于之前踩過坑,我們在早期就開始建模型,形成內部產品需求優先級判斷標準,產品同學接收到需求后,按照劃分的四個維度去歸類,根據“一大帶四小”的原則去快速啟動排期開發。如果功能上線后,用戶的使用反饋不達預期,排除其他因素,是需求的源頭出了問題,我們會組織內部討論,修正更新判斷標準。

舉個實戰例子,當接到個別客戶提出的需求時(判斷個性化需求or普遍存在的通用性需求),我們可以從以下五個維度評估:

  1. 疼痛的深度:個性化需求對于用戶而言,是不是剛需;優先做“雪中送炭”的需求,再排期“錦上添花”的需求。
  2. 影響的廣度:是不是牽扯到上游和下游不同業務流程的完整性,如果有緊密關聯,不處理則會影響用戶的正常操作,就像前面提到的釘釘績效考勤表。
  3. 尋找最大公約數:是某個特別用戶的唯一需求,還是普遍存在卻被忽視的隱藏需求。產品要解決用戶普遍存在的問題,就好像數學上解題尋找最大公約數,這一點也會涉及到公司商業模式,有些產品確實解決了用戶問題,但撐不起一家有體量的公司活得很滋潤。
  4. 關乎公司發展布局:有些需求必須開發不是單純為了用戶,和公司的戰略發展決策有關;比如剛剛提到的我們公司建立判斷模型,這個模型是動態的,跟著公司目前的發展節奏和行業所處生態位。
  5. 技術評估:除了以上四點外,還需要考慮一下技術層面,是否現有技術可以實現,實現成本是否太高。

2. 修煉情商:管理(需求提出者)預期

看到標題你應該挺驚訝的吧?確實產品經理需要具備高情商,畢竟工作內容里有很大一部分是溝通協調職能。

最近在看各種銷售技巧類的書籍,里面大量提到了頂尖銷售人員對于情商的培養。而產品經理和銷售的工作職責非常相似——面對用戶/客戶,把有形的產品或無形的服務推廣出去。

從神經學的角度解釋,人的大腦皮層杏仁核會對周圍人或事物表現的敵意,做出抵抗或逃避的反應。我們在討論需求優先級排序時,如果不能通過控制杏仁核,就會引起對方的反抗意識——想想多少次跨部門討論需求時,大家爭得面紅耳赤?

除了抵抗和逃避,高情商的產品經理反應是哪一種呢?

他們會察覺到負面情緒的觸發點,很好地管控自己的情緒,“以退為進”的溝通藝術。

3. 應急機制:可咸可甜的團隊協作

SaaS先靠完整的產品來滿足大部分通用需求,再靠行業解決方案來滿足重點行業的個性化需求,最后靠把SaaS做成PaaS來滿足每個客戶的個性化需求??蛻糇銐蚨嗔酥?,圍繞著客戶繼續展開,可以做很多“增值業務”。

判斷自己在什么階段,重點做什么事情,是一種基礎的戰略能力。

如果產品經理確定了版本迭代內容與上線時間,在開發過程中,在大的迭代主題之外增加小功能需求的穿插開發,前提是與技術團隊做好充分溝通,在不影響原定的開發時間下,幫助需求提出者處理好功能上線(記得和開發小哥們處理好關系,別硬剛)。

一些產品常識,希望大家避雷:

  • 沒有人會看公告/通知。
  • 沒有人會看系統消息和群發短信。
  • 沒有人會改默認設置。
  • 沒人會沉浸式地看產品操作教學。

“產品是有生命力的流體,在宏觀市場環境與微觀場景中會發生動態變化?!?/p>

需求和需要的差異,我們通過用戶調研訪談,循著用戶表達的“需要”去挖掘隱性的需求。

“需要”不等于“需求”,需要是浮在表面的渴望,而需求是在具象的情境中發生的情緒感知。

#專欄作家#

大井蓋先生,公眾號:八點四十,人人都是產品經理專欄作家。前某廠PM總監,現創業公司CEO;關注企業服務和金融賽道,愛好廣泛,歡迎一起交流探討產品或創業相關問題。

本文為人人都是產品經理《原創激勵計劃》出品,未經許可,禁止轉載。

題圖來自Unsplash,基于CC0協議。

給作者打賞,鼓勵TA抓緊創作!
更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 井蓋大佬精準概括了b端產品的特點,分享的方法論很有啟發性,感覺自己對b端產品的理解又有突破了。

    回復
    1. 多多交流~

      回復
  2. 學習

    回復
    1. 多交流

      回復
  3. 看到這里笑si————

    沒有人會看公告/通知。
    沒有人會看系統消息和群發短信。
    沒有人會改默認設置。
    沒人會沉浸式地看產品操作教學。

    回復
    1. 哈哈哈,真話

      回復
  4. 學習了學習了

    回復
    1. 謝謝呀,多多交流

      回復
  5. 寫的不錯

    回復
    1. 謝謝~

      回復
  6. 需要和需求好像搞反了

    回復
    1. 沒有,哈哈哈,歡迎討論交流

      回復