如何做好TO B產品？

1

互聯網的下半場

過去，平臺的黃金時代

互聯網上半場的商業模式，主要是以滿足C端用戶需求為核心的平臺產品，包括：社交平臺、電商平臺、團購平臺、出行平臺、內容平臺。平臺通過鏈接人與人，內容與人，商家與人，聚合大規模的流量。

圖1：平臺產品示例

互聯網平臺的核心優勢

① 超低的邊際成本

平臺公司的核心業務主要是信息服務，它每多服務一個用戶所花費的邊際成本極低。根據利潤公式可知：

π(總利潤) =TR(總收入)-TC（總成本）=TR(總收入)-TFC(總固定成本)-TVC(總變動成本)

其中，TR、TVC都是與Q（用戶數量）相關的函數，只要TR-TVC為正數且TFC與Q的關係較弱時，規模效應會攤平TFC，實現整體盈利。

圖2：當Quantity大於20時，產生正向的利潤

② 贏者通吃的護城河

C端的平臺產品顯著區別於B端的是：“任一用戶對平臺的議價能力都很弱，單個用戶的離開對業務的影響很小，並且C端平臺規模有較強的馬太效應（供需趨向於集中化），規模本身就是護城河。”

圖3：流量與護城河

③ 網絡效應築造產品壁壘

如果淘寶/天貓只能購買一線城市的商品，那它很難有今天的規模與社會影響力。只有當它成為一款全國性的產品時，用戶的需求才能更完整地被滿足，它也才有更高的產品壁壘。一個硬幣的反面，當一款產品無法通過網絡效應提升壁壘時，它的競爭壓力也會相對更大一些。

例：滴滴出行的快車業務屬於本地生活業務，就算杭州的快車做得再好，對成都的快車業務是沒有顯著增益的，沒有網絡效應也就意味著在不同地區都可能直面競爭壓力。就像兩年前美團打車上海、南京與滴滴直接競爭。

④ 高技術槓桿

上半場的產品大多都是以代碼為核心生產力的，技術的高槓杆在於：

1. 能夠通過快速的迭代來創造用戶價值。因為，

• C端平臺關注核心用戶的畫像，產品標準化程度更高。
• 代碼屬於很輕的技術資產，不涉類實體行業的庫存及現金流佔用問題，沉沒成本更低。

2. 數據與算法的應用降低了信息/交易的撮合成本，提升了用戶獲取信息及交易的效率。

其實，每一次新浪潮的開始，我們都能見到很多自信的、躍躍欲試的闖入者。那些一夜暴富的故事，支撐著霧霾下每日4小時的通勤人，他們是造夢者的門徒。直到潮水褪去，我們才在不斷地離別、嘆息和馬後炮中，看見了市場它最冷靜的一面。

流量紅利殆盡，產業亟待升級

移動端的流量紅利是互聯網上半場創業市場繁榮的根本原因，海量的新流量，從供給端拉低了平臺產品的獲客成本。

然而在2018年後，移動端增速見頂。根據Quest Mobile的數據，2019年1~6月移動互聯網MAU僅淨增570萬，Q2甚至淨降了193萬，預示著移動互聯網進入“存量殘殺”時代。

圖4：移動互聯網MAU趨勢

1）TO B是順勢而為

2016年7月，王興提出了“互聯網下半場”的概念，他提到：“美團點評作為國內最大的互聯網餐飲平臺，過去幾年做的只是很薄的互聯網化，即幫助企業引流。接下來要實現和行業的深度融合，全面幫助它們提升效率，降低成本。”

歷史之勢從來不是無心為之，那這次為什麼是TO B呢？

就在2019年，中國人均GDP正式邁入1萬美元梯隊，奇蹟四十年彰顯了中華民族韜光養晦、努力奮鬥的民族底色，也給了Z世代的年輕人足夠強的文化自信、道路自信。

但是，這個被修昔底德陷阱籠罩的資本世界，並不會手捧鮮花迎接來我們的成功。

圖5：2020年中美貿易協議雙方需要履約的條款統計

在內部，勞動力受舊政策、新環境的複合影響，出現斷崖式下降，成本不斷攀升。導致低端製造業比較優勢喪失，相關產業逐步轉移至東南亞、印度、巴西等地區。

中國製造的升級需求急迫。

2018年中國出生人口達1523萬，比上年減少200萬人，是近40年來中國出生人口環比下降最多的一年。

2019年，中國美國商會（AmCham China）針對239家在華美資企業的調查顯示，22.7％的公司將把供應鏈從中國轉移出去，19.7％的公司正考慮將部分或全部製造業遷出中國，33.2％的公司將推遲或取消其投資，只有2.9％的公司將增加其在華投資。

還需要清醒認識的是：“我國的科技實力、大學教育、基礎科學，相比美方仍然有巨大的差距。”

應該避免盲目自信稀釋了專注度。

宏觀層面，仍高度依賴發達國家的高科技產品（進口）；中國智造想要邁向全球，也還長路漫漫。微觀層面，傳統行業信息化水平低、企業管理粗放、誠信體系缺失、供應鏈效率不足，制約著中國從量到質的轉型。

這是未來10年必須要變革的難點，也是TO B賽道的歷史機遇。

圖6：半導體、飛機等高端製造，中美差距巨大

2）TO B的快速車道

相比於上半場以C端用戶的規模效應、網絡效應築造護城河，下半場轉向更多的企業服務，以及傳統行業升級，包括，

① 以企業為核心的產品/服務。

包括：餐飲Saas、開店Saas、人力資源（組織發展、員工福利）、協同辦公（Confluence、Teambition）、數據服務（神策數據、飛瓜數據）、雲服務、人臉識別、無人駕駛等。

② 傳統行業數據化、智能化、供應鏈優化。

包括：新零售、物流科技、長租公寓、K12教育、AI芯片等。

區別於互聯網上半場更高頻、短鏈、碎片的移動場景，下半場對產品經理提出了新的挑戰，

• 產品/服務不再完全以系統為核心，產品經理需要更多關注業務的場景、流程、組織、角色、供應鏈，去設計“服務”而不僅是“系統”。
• 用戶體驗由“抽象的主觀效用”轉換為“可量化的收入與生產成本”
  ，要求產品經理有更強的業務認知、商業敏銳度。

近幾年，TO B方向已經誕生了很多優秀產品。例如：有贊、曠視、Teambition、阿里雲、釘釘、神策數據、G7等等。相信就在不久的將來，中國也將誕生像Salesforce、Atlassian、ZOOM、Slack這樣千億、百億美金的企業服務公司，大勢之下，只是時間問題。

圖7：美股排名靠前的企業服務公司

2

TO B，業務下沉

業務設計與有效工作

世界上沒有完美的規劃，但全面、嚴謹的業務設計，能夠大幅提升組織的有效產出。如果在這件事情上懶惰，天天拉著團隊打雞血、畫餅、打仗，中長期持續的負反饋，很容易讓團隊崩盤。

1）業務設計要相信專家。相比較那些聰明、年輕的頭腦，業務專家更值得信賴，因為B端很多線下的細節和業務邏輯，需要足夠長的項目積累才能有判斷力。互聯網人在產業中往往不是用戶，只能憑藉邏輯或者類比法來演繹，決策的有效性不高。

2）業務設計要心懷敬畏。不管你做過多少DAU的產品、多麼閃亮的教育背景，面對傳統行業，都是從零開始。一定要對行業、前輩心懷敬畏，互聯網在這裡很難顛覆誰。

3）業務設計要勤于思考。

• 問：業務設計不是CEO、總經理關注的問題嗎？和我有什麼關係？我只想紮紮實實做好產品、運營。

• 答：紮紮實實做產品、運營和關注行業趨勢是不矛盾的，這種東西不觀察個3年、5年也觀察不出什麼，思考核心問題不怕早。並且，沒有公司需要一個35歲的活動策劃專員，努力認知業務是個人從點→面的過程。

TO B的業務設計概述

圖8：TO B的業務設計概述

1）業務分析

業務分析是為了“發現機會”與“預警風險”，對於TO B業務，除了常規的行業分析、用戶分析，需要重點關注“監管趨勢、政策走向”

① 宏觀經濟

宏觀經濟的走勢對企業融資成本、現金流壓力是直接關聯的。對比個人消費者被宏觀經濟的影響有逐級的傳導遲滯，企業一定是更敏感的。

關注的核心模塊，包括：出口/內需/投資的戰略變化（例：近幾年對外資的政策鬆綁）、貨幣政策的變化（例：近期的公開市場操作、準備金率變化）、稅收政策變化（例：增值稅稅率變化對業務進銷項的影響）、地方政策（包括：人口政策、產業政策）等等。

② 監管趨勢

順勢而為，是保障業務能夠持續發展的必要前提。滴滴規模近似壟斷後迎來的管制壓力，我認為本質上是國家對核心民生行業的行政干預預期較高，因為涉及到社會穩定、安全，強管制是有必要性的。

同樣，像比特幣這類去中心化、發行不由官方控制的所謂“貨幣”，在當前的監管層面上，肯定也是無法被接受的。以大局為重，是一個取捨的過程，4.025%的年金險下線也是同理。

③ 分析框架

分析框架需要站在行業的角度、客戶的角度、需求的角度，評估業務的可行性。

案例：做一款TMS（運輸管理系統），解決規模型車隊的管車問題。

1. 行業基本情況與發展趨勢概述

• 商流驅動的集約，受電商飛速發展的影響，中國集約性比較強的運輸領域以快遞為代表，CR5已接近70%，也帶動了一些成規模的運輸車隊（下游）。
• 成本壓力逐級傳導，但由於快遞行業過於集中，核心企業貨量龐大議價能力強，成本壓力逐級傳導，中下游的運輸公司經營壓力大。尤其那些重資產、大規模的車隊，其資產管理、資產利用率、成本控制等多個方面都對運營能力提出了極高的要求。.....（不贅述，參考諮詢報告）

2. 客戶概述及上下游分析

• 目標客戶畫像，擁有>100臺卡車以上的運輸公司，因為這種量級的客戶才有優化管理成本的需求，目前這種規模的運輸公司全國大概有10000家（假設）。
• 客戶的上下游分析，這些運輸公司的上游是通達系、德邦這類大型快遞、快運公司，下游有自有購置的車輛，也有社會運力。當前的行業現狀是：“運力相比貨源大幅過剩，整體議價能力較弱。”除電商外，整體商流的集中度不足、需求個性化，無法形成高度集中的物流市場。......（多維度、信息詳盡）

3. 客戶在成本、效率上有什麼痛點？

• 效率瓶頸：公路運輸核心還是在成本、履約質量上，為了保障履約，部分企業購入大量固定資產（車頭、車掛）自營運力。
  與其他實體行業一樣，這將面臨著業務波動帶來的週轉效率問題。
• 品質管控：因為快遞、快運對於運輸的時效要求很高，供應商需要及時瞭解車輛位置，做好時效控制，降低時效罰款（大概佔其總成本的5%（假設））。
• 邊際成本：實體資產無法像代碼資產那樣，邊際成本趨向於一個極低值，相反，每一個時間段內，一個貨車只能運送一趟貨物，這就決定了該場景下技術槓桿不會特別高，運營的效能非常關鍵。
• 現金流壓力：中游運輸公司需要承擔>2個月的賬期（甚至半年），相比快遞、騎手這類即付現金流的模式，賬期帶來的資金壓力也限制了業務規模。尤其在利潤相對微薄的情況下，即使通過保理融資解決了現金流的問題，其所帶來的成本上漲，對實體運輸企業也可能是不可承受之重。......（業務經驗比邏輯閉環更接近事物的本質）

4. 業務的可行性分析

• 需求驗證：管車的需求是真實的，主要是為了減少管理成本、降低遲到罰款。目前競品已經切入了100家大客戶。付費意願大概在1500元/年，續費率75%。注：上述數據皆為假設。
• 切入路徑：目前通達系的供應商（我們的客戶）都必須安裝一款XX品牌的監控設備，如果想要切入該類客戶，本質是需要搞定它的上游，客戶不會重複採購兩款類似的產品。......（僅做示例，競爭力評估、關聯市場影響等不在此贅述）

總結：只有深入瞭解供應鏈上下游的關係、供需基本面，才能更好地做銷售、產品、運營的決策。

2）業務設計

業務設計的重點是“知己知彼、產品下沉、運營業務”。

① 知己知彼，百戰不殆

不同的業務所處的行業週期、競爭情況都很不一樣。但最抽象的一層，仍然是以“解決客戶需求”為核心。需要通過持續分析競品、完善服務體系、制定符合業務發展階段的增長策略，去構建核心競爭力。

1. 產品分析

調研競品是一個自省、迭代的過程，主要目的是為了評估客戶需求集合的滿足程度，以及產品切入場景後的角色體驗問題。

• 關注客戶的核心需求滿足程度。B端業務需要滿足企業的需求集合，而非單點打透。如果產品功能覆蓋度不夠，難以構建競爭力。例：一款餐飲Saas，80%的用戶不僅需要收銀功能，還需要“經營分析、報表管理、營銷管理、排號等位”等10項功能。產品A僅能滿足其中5項，產品B全部滿足，則產品A難以與B競爭（價格相差不大）。

圖9：中國典型餐飲Saas競爭力分析

• 產品的操作體驗是否能被客戶的組織接受，也很重要。如果僅僅只是老闆買了單，但客戶的組織、各關鍵崗位無法接受系統的流程/交互，產品切入會受到各種各樣的阻力，落地困難。

2. 銷售策略分析

在有限的預算與HC的條件下，根據競品的銷售資源、銷售策略，去制定ROI更高、長線收益更大的銷售策略，是很有必要的。

• 客戶：梳理競品的客戶清單，盤點客情關係及服務深度。
• 策略：梳理競品的拓展策略，盤點其核心優勢區域及下一步重點拓展的區域。
• 增長：梳理競品在拉新、留存上的人力配置、補貼策略，能幫助我們更有針對性地開展差異化的增長策略。例：產品A拉新方面投入了大量的線下力量，且線下銷售的核心任務都壓在了新增上面。此時，產品A通過“留存激勵”的運營策略，即只要商戶交易額在次月保持上個月的80%以上，即可獲得“高額獎勵/折扣”等（通過電銷營銷），以此減輕線下銷售的存量客戶維護壓力。這筆營銷費用需要與所釋放銷售的獲客價值相比較。

② B端產品經理的業務下沉

TO B產品提供的是一套完整的服務，可以分為兩個維度來看，

圖10：看待服務的兩種視角

• 面向客戶（外部），業務需要交付“用戶視角的產品與服務”，即：“用戶會使用什麼軟件，體驗什麼樣的服務流程，最終支付多少錢。”產品解決方案要滿足需求、服務好、價格合理。
• 面向組織（內部），產品解決方案是由基礎的職能分工（業務運營、業務產品）與多個項目共同構建的，所有的人力資源、財務預算配置，都需要以“保障面對客戶視角的服務、體驗不斷改善”為核心目標。

1. B端產品經理如何創造價值？

抽象來看，產品經理最核心的能力應該是“解決問題的能力”，進而為用戶創造價值。

圖11：產品經理的核心能力

《俞軍的產品方法論》中提到：

對於用戶，大家有不同的理解，通常的理解是用戶即自然人。以微信為例，一般的統計報告可能顯示其“用戶”為11億，如果把微信的其他功能（支付、公眾號、小程序、朋友圈、群等）都刪掉，只留下通訊功能，它的用戶數可能還是11億，但它的商業估值可能就從2000億美元變成了200億美元。這種將用戶定義為自然人的做法，顯然在大型互聯網產品上並不適用。

從產品經理的視角來看，用戶不是自然人，而是需求的集合。

關於需求集合，C端與B端產品是有所區別的。

圖12：需求集合的差異

• 做好C端產品，要能夠洞察人性本質的需求，要求產品經理除了有較強的邏輯、同理心之外，更要能透過現象看本質。世界上最成功的C端產品，都是人類本質需求的滿足者，比如：微信的熟人社交、字節跳動的推薦算法、Pornhub的好人社區、Uber的出行服務。
• 但做B端產品，還需要產品經理有優秀的商業感覺。產品必須是一個業務專家，要能梳理業務的“供需關係、生產管理、組織管理、供應鏈管理、財務管理”等相關信息。有能力挖掘企業的效率、成本的痛點，並打造滿足企業需求集合的產品。例：釘釘，一款老闆驗高於一切的協同辦公產品，一款優秀的老闆呼叫器、考勤管理利器。只需要輕輕地奪命DING一下，員工24h在(bei)線(po)辦公，老闆能不喜歡嗎（微笑）？

2. B端產品的貨幣時間價值

• 現金流A產品，營業收入105萬元，總成本100萬元（當期支付），此時的利潤是多少？5萬嗎？但如果這105萬是應收賬款，實際1年後才到賬：Ⅰ 假設貼現率5%，未來1年的105萬收入在當期僅值100萬，所以，考慮貨幣的時間價值，當期的利潤為0。圖13：貨幣的時間價值Ⅱ 由於105萬的應收是1年後才到賬，意味著當期支付的100萬需要流動資金支持，此時使用100萬自有資金週轉業務（假設利率5%），該筆資金當期的機會成本為5萬元。業務的收入現金流是財務模型的關鍵點，像快遞、滴滴這類客戶即付，對下游供應商（運輸車隊、滴滴司機）有賬期的業務，資金佔用沒有壓力，有迅速做大規模的條件。但下游供應商如果想做大規模，週轉資金反而成為較大的阻礙點。

• NPV計算只要當成本投入與收入有時間錯配，NPV計算就是非常必要的。圖14：NPV計算公式例：當期為了拉新用戶，產品A共計投入補貼1000萬元，獲得的用戶在第12個月單月合計貢獻了1050萬的利潤，貼現率5%，
  當期價值Present Value 為1000萬元。故可得NPV=0。圖15：各時段現金流的現值計算

總結：做業務決策時，如果不考慮貨幣的時間價值，往往會導致做投產比分析結論有誤，帶來無謂的財務虧損。

3. B端產品的用戶調研

圖16：B端與C端用戶調研的差異

B端業務場景往往是非生活化，需求的蒐集與分析，沒有過往經驗的支撐，更需要產品經理深入當前的業務場景中去，瞭解：

• 客戶的決策機制、切換成本實際決策人是核心需求的來源，組織的各角色是產品的實踐者，他們的需求都需要了解（以決策人為核心）。例：為餐飲商戶提供外賣接單系統，商戶決策因素有：加入美團點評後，店鋪的流量獲取能力會與哪些指標相關，收入抽成比例，提現規則（資金佔用），營銷工具包（會員、積分、優惠券）等等。對於已經使用競品的客戶，除了考慮產品、成本差異，還要考慮切換成本，尤其那些與客戶系統打通競品（可能兩邊花了幾個月時間才打通）。我們產品的新體驗能否超出舊體驗+切換成本？如果不能，客戶憑什麼切給我呢？（答：也許可以通過銷售動作補產品不足，為什麼會有大保健？）

• 梳理業務流程、組織角色及其KPI梳理流程是業務設計最核心的工作之一，它類似C端的用戶體驗地圖，通過梳理各個節點的“效率、成本”痛點，找到產品的核心價值點，並基於此去創造新的用戶價值。圖17：瑞幸咖啡的用戶體驗地圖（示例）
• 梳理各角色及其KPI，更有助於改善服務能力、產品體驗。例1：調研客戶組織後瞭解到，採購經理的KPI除了找性價比更高的供應商，還要求供應商的履約品質必須達到公司設定的標準，這決定了業務的資源投入（例如：客服、Local人員的投入）。例2：對於訂單錄入的操作員，每個人負責的線路相對固定，高峰期每日錄入100單，每一單都需要重新選擇出發地、目的地，操作成本太高，應該設計常用地址庫功能解決這個問題。

4. B端產品的設計概述

• 瞭解程序設計的MVC範式Model指數據模型、View指前端交互圖，Controller指業務邏輯。任何一套軟件系統運作的本質都是相同的；用戶在前端交互層操作後，系統通過業務邏輯層處理數據層的數據。

圖18：MVC範式

• 從業務流程到產品架構業務流程梳理是產品設計的重要基礎。假設做一個外賣系統，一個商家要開店接單，最簡易的流程需要有：註冊認證→開店→接單→提現。流程之下就是需求的集合：(1) 註冊認證：需要哪些資料、資質？審核標準、時效要求是什麼？(2) 商品管理：支持排序管理？支持哪些信息修改？商品圖片支持多大規格？配置商品數量的上限是多少？(3) 逆向流程（重要）：逆向流程的完備性決定了銷售、客服、技術的無謂成本。完備性不足將可能導致技術分散精力去解決偶發的逆向問題，影響開發進度、質量。3.1 不同訂單狀態下，客戶發起取消的業務邏輯應該有什麼不同？3.2 騎手因故無法取餐，商家端是否需要支持發起重新匹配騎手？3.3 客戶點的某一樣商品無貨，商家是否支持部分退貨？......圖19：商家入駐外賣平臺
• 基於業務流程對應的需求集合，梳理產品架構。(1) 基礎功能：包括用戶、支付、消息、發票等，可能會接入統一的中臺服務，需要基於業務需求逐個梳理功能細節。例：因監管要求，營業執照有效日期單獨錄入字段，做較強的業務限制（超期不更新無法再接單）。(2) 業務功能：包括訂單服務、營銷工具包、門店管理、權限管理等。圖20：產品架構圖（示例）
  Ⅰ訂單作為核心服務，其狀態設計及各狀態下的逆向流程非常重要，決定了商家自助經營的能力。Ⅱ營銷工具，核心是賦能商家銷售，包括：送券、賣券、滿減、秒殺價、廣告投放等等。Ⅲ權限控制，主要參考RBAC（Role-Based Access Control）模型。其中最簡單的用戶、角色、權限模型，包含了2種情況：ⅰ用戶和角色是多對一關係，即：一個用戶只充當一種角色，一種角色可以有多個用戶擔當。ⅱ用戶和角色是多對多關係，即：一個用戶可同時充當多種角色，一種角色可以有多個用戶擔當。注：權限管理涉及到子角色、繼承、互斥、數量約束等邏輯，在此不一一展開。圖21：RBAC模型總結：當角色的權限邊界較為清晰時，可考慮使用多對一的權限設計。若不滿足該條件，則最好使用多對多的權限體系（避免大量用戶都要獨立建設角色，變成一對一的權限管理），保障系統的可擴展性。例：小代既是銷售運營，也負責財務對賬，那小代就應該同時擁有銷售運營與財務對賬兩個角色的權限。

③ 卓有成效的業務運營

1. 業務的增長解構

• NDR，增長的試金石圖22：ARR示意圖如上圖，客戶的年度經常性收入（Annual Recurring Revenue）可按用戶新增年份劃分為不同的顏色，可以清晰看到，一個有好的收入留存（Net Dollar Retention）的企業軟件產品，其增長極大程度由老客戶來推動，每年新客的獲客壓力很小。注：收入留存Net Dollar Retention，指存量客戶在新一年產生的所有收入（包括原有模塊的續費與增購，新模塊的增購）作為分子，這批客戶在前一年產生的所有收入作為分母，兩者相除。

• 商業模式決定增長策略業務增長由老客戶留存收入+新客戶收入組成。Ⅰ 留存週期很短的業務，大量成本都會花在了銷售費用上，需要持續拉新才能保持增長。例：英語培訓、婚慶服務。Ⅱ 留存週期很長的業務，收入可以更多轉化到技術、產品迭代中去，提升自己的核心競爭力。
  例：協同辦公、知識管理、雲服務。例：Atlassian 的敏捷管理矩陣有“ Trello、JIRA、Confluence”三款產品，其超高的留存率反映了產品的粘性。根據2019年的投資者報告內容，Atlassian為花費5萬美元或以上的客戶實現了98%的保留率，其中90%的客戶購買了3種或3種以上的產品。圖23：Atlassian的留存、購買數據總結：當商業模式的留存能力較高時，成本投入可以更多傾斜到存量客戶的價值滿足上，用存量支撐增長的基本面。反之，只能將預算都投入到持續的拉新中去，此時存量客戶的體驗保障往往成為一個難題，婚紗攝影就是典型的銷售大於服務，套路繁多，意圖一次榨乾的行業。

2. 業務運營的設計概述

業務運營是集增長、服務、數據、研究於一體的運營體系。不僅要對外提供營銷策略、客戶服務，更需要對內交付決策支持、用戶反饋。

圖24：業務運營架構圖（示例）

對外，業務運營是營銷策略、客戶服務、培訓支持等。要實現業務的增長目標，併為客戶提供更好的的業務體驗。

對內，業務運營是流程管理、數據分析、行業/用戶/政策研究及運營支持，目標是保障業務運作的高效、流暢，保障業務決策的有效性、合理性。

• 如何實現增長？業務增長主要還是圍繞營銷策略展開的，包括產品定價及搭售方案、銷售策略。Ⅰ 定價與搭售(1) 中小客戶標準品，要參考競品的定價模式，實施與業務節奏匹配的的搭售策略、促銷策略。對於高續費率的產品，可在拉新上投入更多預算。例：假設Teambition給企業版購買者提供知識積累產品Thought半年10人的高級權限，由於知識積累屬於切換成本很高的產品，灰度測試續費率約75%（假設），綜合收益依然可觀，搭售方案可行。
  (2) 對於大客戶，要有完善的報價機制。包括：客戶檔案建設、個性化需求蒐集、決策人影響（要避免花了很大力氣BD，沒找對實際決策人）、方案設計與成本評估。圖25：Teambition價格方案Ⅱ 銷售策略要開展全國性的業務，銷售資源的配置是核心決策點，關係到整個業務的成本與產出。(1) 盤點：圍繞增長目標，設定銷售指標的拆解邏輯。盤點存量客戶的產出預期，評估增量客戶規模，並梳理潛在客戶列表及對應的HC需求。(2) 合作：銷售與事業部的組織關係，決定了業務在前臺推進的效率。如果銷售體系閉環在事業部內部，產研、運營與銷售的合作，主要圍繞KA需求的敏捷支持以及高優先級Feature List的迭代交付，圍繞研發資源的配置，需要高頻溝通。如果銷售屬於中臺體系，承接各事業部需求，業務需要先確認銷售的資源配置方案，包括：績效考核的邏輯、業務的激勵規則等等。圍繞銷售資源的配置，需要重點溝通。(3) 路徑：是先從單一客戶突破，還是從重點區域突破？要基於業務實際的競爭情況考慮。如哈羅單車初期就避開了一線城市，在二三線城市站穩了市場，最後切入一線城市。
  (4) 模式：直營服務品質更好，為了拿下重點、核心城市，可能會使用直營模式；對於業務量小、基數龐大、單個價值低的中小型城市，可能會使用成本更優、速度更快的加盟模式。

• 構建服務體系C端產品，單個客戶的流失對平臺損失不大，客服體系可能會側重構建標準、廣覆蓋的服務能力，尤其要在成本與收益面前做再平衡（例：印象筆記甚至沒有電話客服，客服流程通過郵件處理）。但由於B端產品的客戶價值相對更大，需要更完整、深度、個性化的服務，才能提升客戶留存水平。為了實現這個目標，至少需要滿足三點：Ⅰ 讓客戶方便地找到我們，搭建覆蓋度高的服務窗口。Ⅱ 搭建售前、售中、售後多層次的服務能力。Ⅲ 實現數據閉環，便於高效、全面地評估服務質量。圖26：搭建服務體系的要點客戶服務不單單是一個體系問題，更是一個文化問題。如何看待用戶的反饋？是真的閉環處理，還是記錄後石沉大海？客服的應急權限有多大？這些問題的背後，體現了業務負責人對用戶的真實態度。

3. 面向經營的數據體系

數據體系核心是面向經營提供業務觀察、業務診斷的能力，它的結構類似MVC結構，前端是可視化的控件，中間層是數據倉庫以及對應的報表結構，底層是業務分析的體系。

圖27：業務的數據體系

• 業務分析體系（核心）分析的目的是診斷、監控。業務分析可以大概分為2個模塊：什麼樣的數據表現是健康的？哪些項目需要重點監控？根據2個模塊的具體內容，再結合業務構建指標體系：Ⅰ 業務健康度指標：判斷業務是否健康發展的核心指標集合，任一指標出現問題都預示著業務存在較大的健康風險。一般健康度指標都有明確的目標，便於做業務發展的過程管理。Ⅱ 分析型指標：業務分析邏輯鏈路上的過程指標，以及其他需要重點監控的指標。由於業務不同階段的側重點不一樣，監控的方向也各不相同。例：業務衝刺階段，業務負責人希望重點關注客服質量，避免高成本拉來的客戶因為客服質量不滿意而流失。

圖28：業務分析體系框架（示例）

• 數據倉庫/報表體系有了業務分析邏輯，就可以開始搭建業務報表了，這是一個從想→做得過程。在MVC的架構中，前端層、業務邏輯層都會有數據上報，形成數據庫表/日誌。圖29：數據的形成瞭解產品數據結構的業務運營，對分析的實現才有更強的判斷力，也更能夠理解各系統間的交互邏輯。所以，在產品設計初期，業務運營就需要和業務邏輯層（後端）溝通各個服務、系統的數據記錄的字段、規範，避免業務所需的關鍵數據漏存。圖30：業務數據的表結構（示例）通常，業務分析體系的指標，往往需要關聯多張核心表關聯計算，例如：用戶表、支付表甚至其他業務的表，單一業務方難以實現。為了解決這個問題，大數據部門通過拉取各業務的數據，經過流程調度、數據清洗、數倉建表，最終提供數據服務（例：可視化平臺、用戶標籤查詢、報表服務......），為業務方賦能。在數倉的建設過程中，最好能有懂業務、數據結構的業務運營與大數據工程師共同建設，保障“業務分析邏輯”→“技術實現”的信息傳導足夠對稱。圖31：數倉整體的技術架構（示例）
• 數據可視化數據可視化，實際是將數據信息以更低的閱讀成本提供給數據消費者。不同類型的數據適合不同的展示方式。不必過度追求炫酷的效果，時刻關注它的核心價值是“更低成本的閱讀”。推薦工具：Tableau

圖32：Tableau展示案例（Hanah Anderson、Matt Daniels）

④ 敏捷的項目管理體系

一個業務要持續前行，有兩種工作要做：

• 重複性工作，例：日常的數據監控、客服等運營工作。
• 項目型工作，通過完成一個新項目改善產品/運營，從而讓業務發展得更好。

圖33：業務與項目的關係

互聯網行業，業務從0~1的過程中，

• 需求變化很快、要求整個組織足夠敏捷、高適應性地去為組織提供服務。
• 團隊規模的擴張，沒有體系化的項目管理，將出現：“信息不對稱、進度把控弱、協同成本高、邊界不清晰”等問題。圖34：項目管理的急迫性

1. 敏捷的業務運營

如同產品是迭代出來的，運營要持續優化業務，也必須採取迭代交付的模式，以應對多變的業務需求。

圖35：迭代式開發的優勢

我通過3年的實測與迭代，驗證了“建設以Scrum（敏捷）為核心的項目管理體系，確實能有效提升運營團隊的自我管理、高效溝通、適應變化的水平”。

下面我會簡單介紹下敏捷運營的方法。

2. 什麼是Scrum？

Scrum一詞來自橄欖球運動中的“並列爭球”。在軟件開發歷史過程中，Scrum 先驅們將 Scrum 這個詞的隱喻應用於軟件開發。它是一套輕量級的核心價值觀、原則和實踐，統稱為 Scrum 框架，在這個框架中人們可以解決複雜的自適應問題，同時也能高效並有創造性地交付儘可能高價值的產品。

在這個框架下，我們可以檢驗團隊是否符合 Scrum 原意的要求：

1. 團隊成員是否有共同目標？

2. 團隊成員是否開誠佈公地緊密合作？

3. 團隊成員是否經常檢視和調整？

4. 團隊成員是否各自發一顆球（各做各的用戶故事等），各自努力往後場衝刺以爭取個人績效？

......

圖36：Scrum Process

3. Scrum的運營實踐

Scrum的運營實踐，借鑑了Scrum在產品開發上的應用。

它是一種有計劃、持續迭代的運營策略。通過多次交付來應對需求的變化，逐步得到一個完善的解決方案，並影響業務的結果。

圖37：Scrum運營實踐概述

(1) Scrum運營有哪些角色？

Business Owner(BO)：業務負責人

• 職能：負責勾勒業務願景、為業務指明方向、計劃節奏、考慮成本等。他一方面要理解用戶、利益干係人的需求。另一方面，對正在推進的業務，要和產品、運營、研發團隊緊密合作，驗收各方交付出來的產品。

Scrum Master(SM)：敏捷教練

• 職能：Scrum Master 既是 Scrum 團隊的教練，是團隊服務型領導、“保護傘”和“清道夫”。Ⅰ 負責指導團隊在通用的 Scrum 框架上建立並遵循自己的過程，幫助每個參與者理解並樂於接受 Scrum 的價值觀、原則和實踐；Ⅱ 充當教練、在過程方面發揮教導作用，幫助團隊以及組織中的其他人指定合適的高績效、有組織特色的 Scrum 方法；Ⅲ 負責保護團隊不收外部干擾和障礙
  ，（在個人無法有效解決遇到的障礙時）發揮領導作用，清楚阻礙團隊生產率的障礙；Ⅳ 他是領導者，不是管理者。

Operation Team(OT)：運營團隊

• 職能：負責確定如何交付業務負責人要求的成果，負責運營的策略設計、數據分析等工作；團隊成員整體具備的技能，需要足以實現業務負責人要求交付的業務價值。

(2) 項目管理概述

Ⅰ 業務計劃（ Business Planning）

每月的OKR評審會議將產出“業務代辦列表、OKR”。

主R：業務負責人（BO）

• 待辦業務列表：評估業務工作及優先級。
• OKR：評估一段時間內業務的目標及關鍵結果。

圖38：Uber的OKR示例

Ⅱ 衝刺計劃（Sprint Planning）

主R：Scrum Master

基於“OKR、業務待辦列表”，Scrum Master需帶領敏捷運營團隊，將“業務待辦列表”中的工作拆解為下一個衝刺(Sprint)的“工作包”列表。

• 工作包是一個有明確時間節點的可交付成果。

圖39：業務待辦事項與工作包的差異

Ⅲ 衝刺（Sprint）

主R：Scrum Master、運營團隊

• 時間盒

以時間盒（例：2個自然周）為單位進行衝刺（Sprint），持續交付工作包。在每個時間盒結束後，重新評估一次“業務待辦事項列表”所需交付的工作包是什麼，以適應業務的變化。

圖40：業務待辦事項與工作包的差異

• 看板

使用“看板”作為“信息發射源”，同步各項目衝刺（Sprint）的工作包狀態。

圖41：Teambition看板

Ⅳ 衝刺回顧（Sprint Retrospective）

主R：運營團隊

每個月結束（約2個Sprint），結合OKR做衝刺回顧（覆盤）。回顧的目的是：

• 評估目標及達成情況
• 遇到了哪些問題？有什麼亮點？
• 總結經驗教訓、客觀規律
• 總結接下來衝刺（Sprint）的改善項
• 團隊進行充分的交流、溝通

寫到這裡已經12000+字了，算是對5年業務運營工作的總結。

其實不管是產品也好，運營也好，最終的目標都是做一個業務負責人，只有持續地去認知行業，打磨自己產品、運營、商業能力，構建自己的輪子而不只是在得到上聽別人的輪子，我相信未來才能跑得更從容一點。

參考文獻：

《2019年中國報告》，麥肯錫全球研究院，2020年；

《企業服務創業者必讀：影響公司估值和發展的核心指標 | GGV投資筆記第十一期》，GGV紀源資本；

《俞軍產品方法論》，俞軍，中信出版社，2019年；

《決勝B端，產品經理升級之路》，楊堃，電子工業出版社，2019年；

《兩萬字談談如何使用 Scrum 框架進行敏捷開發》，@yishuailuo，2017年；

《RBAC模型：基於用戶-角色-權限控制的一些思考》。

作者；一隻特立獨行的Eric

閱讀更多 增長研究社 的文章

關鍵字: 美好，一直在身邊 投資 互聯網