起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識企業服務類產品，其底層邏輯是什么
編輯導語：
# 本文為人人都是產品經理《原創激勵計劃》出品。
企業服務類產品在國外發展已經成為了主流，但在國內這幾年才掀起熱潮，大部分還處于起步、探索階段。習慣了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協議。
靈活用工產品經理路過，感謝分享
哈哈哈，加微信互撩，靈活用工周邊賽道產品飄過
我公司就是做企業后勤行政管理的B端SAAS產品，也無需求各種來源老板、銷售、市場、競品、客戶、系統使用對象（司機、行政
企業大中小領導、一線員工、宿管大爺、保安等等），因為需求來源太多，多業務模塊并行，場景豐滿的同時產品越做越臃腫，各方面成本越來越高，在這個野蠻生長的領域我們系統也越賣越高價，人家專注一兩個業務模塊成本低，在競標時候人家系統價格比我們系統低了好幾倍，就算是人家系統不夠好用，企業也會選，因為價格太有優勢了。
B端產品好用并不意味著會被客戶采購，影響因素不是唯一的，在業務流程上要選擇核心切入點，有自己的生態定位，不然做的太臃腫，客戶反而覺得麻煩會離開產品，很多產品是被自己做死的，如果已經上升到PaaS就可以解決一部分個性化延展開發的問題。
歡迎多多交流，產品嘛，多打磨多思考總是好的
生態定位就是行政，在傳統線下業務場景中行政崗位的工作基本上都是有多又雜又容易亂，我們通過線上系統把一些線下無序或者管理不到位的工作流程中的細節規范化，基本上從業務流程來講是很清晰，一些流程中細節化的功能可以通過IP地址配置給客戶進行定制化。這些細節很難把控，很難去斷定那些細節屬于公有化需求，是否要更新到公有化產品。有時候因為修改一下表格的字段給新客戶，老的客戶就炸毛了，要求還原表格。公司與公司之間管理體系總流程是相同的，管理細節很多都不同，并且他們都用我們公有化產品，有時候需求會出現矛盾。此時產品就很難了，做不做都很難
哈哈哈，其實我們也是做SaaS，服務的群體互聯網水平不高，也有這類問題，但是總有解決方案的。咱們產品經理就是來解決問題滴
我司產品也是服務互聯網水平不高的群體，而且也是協助企業做行政后勤管理的，每個企業行政后勤管理辦法都不一樣，基本上上市企業客戶都會有定制功能，定制功能和原有功能在大方向上是一致的，但是細節上差之毫厘謬以千里，客戶總是要求必須按他們企業原有運行了多年的管理辦法去定制開發功能，很難說服，個人感覺產品的復雜度和學習難度都是這樣來的，這種情況你們公司會遇到嗎？應該怎么解決？
產品需求排期是個很難處理的工作。尤其是那種開發資源不足，需求一大堆的情況，每個需求方都認為自己的需求重要。如果產品沒有上一級的支持，文中那些排期手段會淪為紙上談兵
能夠理解您說的，產品經理都有自己的判斷標準，我們始終是追求正確的解決方案，相信也是公司希望的結果
寫的很好，怎么說呢，這一切的基礎是要有大領導站臺，其實很多產品都是很無奈的明明知道需求不合理，如果一旦上去會出現能想到的問題，但是最終還是會上，因為你無法說服領導，領導總是覺得自己的需求是對的。我一直是這么認為的，在沒有大領導信任的基礎上，我們就是個項目經理，僅此而已。
感同身受，卑微的產品狗們團結在一起~
有個建議，咱們還是要不斷加深專業能力，可以妥協用最小成本去跑跑測試方案可行性，但是不能無底線的妥協，不能因為懼怕就不提最優方案
所以才會有數不清的小公司，中小型公司的通病就是老板自以為是，公司永遠做不大。特別是B端產品，甲方乙方兩個自以為是的合在一起搭建一個五彩斑斕黑的舞臺，產品交互設計們只能在下面鼓掌叫好了
是的，B端產品需求 來源更復雜，要讓專業的人干專業的事，先實用再考慮美觀。
你這么說，我目前所在公司的CEO是技術+產品出身，那我還算比較幸運
產品出身的CEO+1，哈哈哈
To C產品講的是用戶體驗，To B產品更多講的是效率。
說得在理，B端產品先實用再美觀
細細品讀，受益良多，感謝分享?。。∫殃P注?。?/p>
謝謝啦，多多交流~
接觸B端產品半年多，確實對文中這幾點都感觸很深。B端比C端更考驗產品經理對行業對業務的理解深度，更需要挖掘用戶反饋表述的背后最根本的需求痛點是什么
是的，從業務倒退需求源頭，不能單純看成一個功能點。
當用戶開始付費之后，用戶會天然認為“顧客就是上帝?！痹诶媸杖牒彤a品初心上如何平衡有沒有經驗（比如用戶策略、產品設計等）可以分享。
可以啊，很多SaaS做著做著就變成某家客戶的定制開發商了，要解決普遍的需求，不能過于單獨。
寫的很不錯，當然，其中還有一點我認為也值得拓展的，就是怎樣讓需求提出人（主要是運營和B端產品的用戶）接收「你的需求被拒絕了」。雖然作為PM很明白原因，但如何讓個人理解，除了強壓或拿職位和負責版塊之外，有沒有更友好的方式，這點值得探索。
是的，感謝你提的建議，需求被拒要能夠友好的上傳下達
是的。我也有被這個困擾。對方是運營的VP。怎么說服她，讓她接受“她的的需求不合理”進而讓她放棄非常難。
看樣子大家都有這個困擾，首先可以是請你們產品的負責人與運營VP同級溝通或者用最小可行的demo做一個打樣