編輯導語：企業服務類産品在國外發展已經成為了主流，但在國内這幾年才掀起熱潮，大部分還處于起步、探索階段。習慣了To C 思維的我們，在對垂直場景下的SaaS應用往往沒有很清醒的認知，以 To C産品的發展視角來看待企業服務這門生意，隻會到處踩坑。本文是一位to B賽道創業公司的CEO，以自身創業從0到1打造多款企業服務類産品的經驗，分享其對于企業服務類産品的搭建、設計、運營邏輯。希望對各位有所幫助。

一、理性看待：“用戶永遠沒有錯”

C端産品的用戶表達需求，往往比B端産品的用戶表達更精準或者說更明确，人人都可能是C端産品的用戶，而B端産品卻不是個體的使用決策，是集體使用體驗。

俞老師曾說“用戶永遠沒錯”，看過産品軍規12條的小夥伴肯定記得這一條，大家要理性冷靜，俞老師表達的不是字面意思，應該解讀為“用戶面對問題時，所産生的情緒和感受是真實有效的”。

作為産品設計者，我們需要理解在特定情景裡用戶的邏輯和反應，然後……考慮滿足他們的意見或否定他們的意見，又或者放棄這一部分用戶。

做B端産品，我們圍繞着用戶核心的需求，專注極緻。與其說用戶在選擇我們，其實因為資源有限，我們也在選擇用戶，不是所有功能我們都能做 ，最終隻能在一個維度裡解決最“痛”的點。

做減法比做加法更需要策略與克制，無論to B産品還是to C産品，最終的解決方案都應該是最簡單的極緻體現，以最短路徑和最低資源成本滿足用戶的需求。

二、需求評級：建模，制定前置規則

關于産品需求優先級的評判，如果沒有統一标準，不同的産品經理估計能誕生一千種不同結果。

B端産品經理接受需求的來源要比C端産品豐富而複雜，對于B端産品經理，梳理需求的優先級開發排序是一件“左右逢源”的難事，要考慮服務部門的情緒，要照顧業務部的指标擔當，還要兼顧公司市場拓展的進度。

有些需求是老闆給的政治任務，有些需求是銷售部提的（如果不做就分分鐘影響公司營收指标），有些需求是為了支持運營活動的，有些需求是為了減輕客服團隊重複答疑工作量的，以上種種都是産品需求來源的内部渠道，需求還包括用戶使用後的反饋、行業技術進步等等，對于産品經理而言，學會将需求合理的排期是一門硬核技能。

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

舉個實戰例子，當接到個别客戶提出的需求時（判斷個性化需求or普遍存在的通用性需求），我們可以從以下五個維度評估：

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

權衡需求優先級：戰略定位、用戶影響範圍、實現成本。

三、系統框架：搭建最小可用的業務閉環

對于咱們做B端産品的同學來說，得有系統的基礎建設意識，包含業務梳理、個性化需求評審、産品架構設計等流程。企業服務類産品，在設計時要考慮能覆蓋全場景、完整業務鍊路的閉環，因為任何一個環節的缺失和不完善，都會導緻客戶的業務流程無法正常運轉。

舉例來說，釘釘現在成為了大部分企業的内部OA。如果公司HR想要做上月員工的薪酬績效，釘釘不能提供員工的日常考勤記錄，需要HR從其他系統導入或者人工錄入，那HR想要實現的績效核算就無法推進，這樣無法完成一個薪資核算的閉環，代表它不能滿足用戶的基本需求。

當然，對于SaaS産品來講，穩定性壓倒一切，服務器不能宕機，同時産品風格要保持統一連續性。如果後期，平台想要做功能延伸，在産品架構規劃初期就要預留可拓展的空間，始終為用戶提供持續穩定的安全感，to C産品可以追求UI的新奇，B端産品仍然以穩定為王。

四、用戶體驗：整體感知，保持一緻的表達方式

對于同一個角色，如果行業内有多種不同的稱呼。就好比城市裡的Kevin，春節返鄉，被人叫“狗剩”一個道理，假設城市和農村兩個地域場景重疊在一起，那就是雙城記了。

每一處給用戶表達的内容，都需要是一緻的，不做多樣化。從注冊登錄開始到退出結束為止，從 “首頁”跳轉到“我的”，界面視覺、文字内容與标點符号，給用戶一個完整的情境。

舉個例子，在藍領送工系統裡，我們将人力公司的業務場景拆分後，發現5個用戶角色就已經可以覆蓋全部的業務流程，那我們就花時間去推動用戶接受舊角色的統一“新名稱”，把之前叫“業務員”、“工頭”的全部引導成叫“勞務經紀人”，這樣無論是行業内的溝通成本有明顯降低，還是角色的職責定位也越發清晰明了。

五、功能克制：圍繞主流程，抓大場景

上周業務團隊在複盤時，對目前的産品提出了一堆的訴求，包含了個性化的需求、業務快速推進過程中的市場策略需求等等；針對這次需求追源大會，我們内部達成了共識，專注解決産品創立初期的核心問題，先有了樹幹再發展枝葉；針對B端産品，涉及到客戶繁雜的業務流程，裡面可以衍生的需求非常多，一不留神就會陷入無窮盡的開發旋渦。

做大而全很容易，做少而精很難，全面的東西是平庸的。

如果，咱們沒有化繁為簡的能力，就要克制自己做多的欲望，産品都是被“加法”作死的。

不堆砌功能，功能一定是服務于特定場景下用戶的整體體驗，沒有脫離場景的單獨功能。做多，本質上源于不自信，如果圍繞核心需求提供的解決方案最優，用戶的黏性自然強，不需要疊加一堆雜七雜八的功能作為陪嫁。每天砍掉幾個需求帶來的價值，大于提出幾個新需求。

企業服務類産品解決客戶的需求可以大緻分為兩類：“開源”或者“節流”——開源表示能夠為客戶帶來新增營收或者提高收益率，節流就是常說的降本增效。

對于任何新客戶，為開源需求買單的預算遠比節流需求更充足，意願更強烈。

舉個例子，虎蛙産品的目标客戶是人力資源公司（勞務中介），我們在确定為乙方提供數字化服務時，把行業内的全業務場景做了三段式流程劃分，即“甲乙雙方的用工訂單”、“乙方分包與招聘”、“内部管理及結算”。

考慮到當前國内的用工市場情況，買方和賣方發生了換位變化，我們設計産品結構（骨骼）時，舍棄了乙方和甲方（用工單位）簽約的CRM場景，這個場景我自己認為不是主流需求發生地，做這個決策談不上客觀，基于自己對行業的理解與判斷。

影響産品成功的關鍵因素，除了創始團隊對特定市場的深刻理解與前瞻預見之外，還有團隊對資源的掌控調用能力。

産品經理要深入了解行業，了解行業後才可能從全局視角看産品功能規劃，先有了産品結構的骨骼，才慢慢長出肌肉和皮膚（功能/UI/界面交互）。

六、有效流量：用戶痛點=需求程度*需求頻次

聊聊流量，建立在痛點滿足基礎上的流量才是有效流量。

痛點=需求程度*需求頻次，有效的流量必然是極度需求且高頻需求的。

如果不是建立在痛點基礎上，僅僅是通過一些營銷手段獲得了流量，這種流量根本沒有任何黏性可言，活躍度也會極差。

用戶的獲得感>用戶的産品使用能力，流量才不會離開。

#專欄作家#

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

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

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

,

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!

查看全部