壹
網際網路的下半場
一、過去，平台的黃金時代
網際網路上半場的商業模式，主要是以滿足C端使用者需求為核心的平台産品，包括：社交平台、電商平台、團購平台、出行平台、内容平台。平台通過連結人與人，内容與人，商家與人，聚合大規模的流量。
圖1：平台産品示例
1、網際網路平台的核心優勢
1）超低的邊際成本
平台公司的核心業務主要是資訊服務，它每多服務一個使用者所花費的邊際成本極低。根據利潤公式可知：
π(總利潤) =TR(總收入)-TC（總成本）=TR(總收入)-TFC(總固定成本)-TVC(總變動成本)
其中，TR、TVC都是與Q（使用者數量）相關的函數，隻要TR-TVC為正數且TFC與Q的關系較弱時，規模效應會攤平TFC，實作整體盈利。
圖2：當Quantity大于20時，産生正向的利潤
2）赢者通吃的護城河
C端的平台産品顯著差別于B端的是：“任一使用者對平台的議價能力都很弱，單個使用者的離開對業務的影響很小，并且C端平台規模有較強的馬太效應（供需趨向于集中化），規模本身就是護城河。”
圖3：流量與護城河
3）網絡效應築造産品壁壘
如果淘寶/天貓隻能購買一線城市的商品，那它很難有今天的規模與社會影響力。隻有當它成為一款全國性的産品時，使用者的需求才能更完整地被滿足，它也才有更高的産品壁壘。一個硬币的反面，當一款産品無法通過網絡效應提升壁壘時，它的競争壓力也會相對更大一些。
例：滴滴出行的快車業務屬于本地生活業務，就算杭州的快車做得再好，對成都的快車業務是沒有顯著增益的，沒有網絡效應也就意味着在不同地區都可能直面競争壓力。就像兩年前美團打車上海、南京與滴滴直接競争。
4）高技術杠杆
上半場的産品大多都是以代碼為核心生産力的，技術的高杠杆在于：
- 能夠通過快速的疊代來創造使用者價值。因為C端平台關注核心使用者的畫像，産品标準化程度更高。代碼屬于很輕的技術資産，不涉類實體行業的庫存及現金流占用問題，沉沒成本更低。
- 資料與算法的應用降低了資訊/交易的撮合成本，提升了使用者擷取資訊及交易的效率。
其實，每一次新浪潮的開始，我們都能見到很多自信的、躍躍欲試的闖入者。那些一夜暴富的故事，支撐着霧霾下每日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端使用者的規模效應、網絡效應築造護城河，下半場轉向更多的企業服務，以及傳統行業更新，包括，
1）以企業為核心的産品/服務。
包括：餐飲Saas、開店Saas、人力資源（組織發展、員工福利）、協同辦公（Confluence、Teambition）、資料服務（神策資料、飛瓜資料）、雲服務、人臉識别、無人駕駛等。
2）傳統行業資料化、智能化、供應鍊優化。
包括：新零售、物流科技、長租較高價的電梯大廈、K12教育、AI晶片等。
差別于網際網路上半場更高頻、短鍊、碎片的移動場景，下半場對産品經理提出了新的挑戰，
- 産品/服務不再完全以系統為核心，産品經理需要更多關注業務的場景、流程、組織、角色、供應鍊，去設計“服務”而不僅是“系統”。
- 使用者體驗由“抽象的主觀效用”轉換為“可量化的收入與生産成本”，要求産品經理有更強的業務認知、商業敏銳度。
近幾年，TO B方向已經誕生了很多優秀産品。例如：有贊、曠視、Teambition、阿裡雲、釘釘、神策資料、G7等等。相信就在不久的将來，中國也将誕生像Salesforce、Atlassian、ZOOM、Slack這樣千億、百億美金的企業服務公司，大勢之下，隻是時間問題。
圖7：美股排名靠前的企業服務公司
貳
TO B，業務下沉
一、業務設計與有效工作
世界上沒有完美的規劃，但全面、嚴謹的業務設計，能夠大幅提升組織的有效産出。如果在這件事情上懶惰，天天拉着團隊打雞血、畫餅、打仗，中長期持續的負回報，很容易讓團隊崩盤。
1、業務設計要相信專家。
相比較那些聰明、年輕的頭腦，業務專家更值得信賴，因為B端很多線下的細節和業務邏輯，需要足夠長的項目積累才能有判斷力。網際網路人在産業中往往不是使用者，隻能憑借邏輯或者類比法來演繹，決策的有效性不高。
2、業務設計要心懷敬畏。
不管你做過多少DAU的産品、多麼閃亮的教育背景，面對傳統行業，都是從零開始。一定要對行業、前輩心懷敬畏，網際網路在這裡很難颠覆誰。
3、業務設計要勤于思考。
問：業務設計不是CEO、總經理關注的問題嗎？和我有什麼關系？我隻想紮紮實實做好産品、營運。
答：紮紮實實做産品、營運和關注行業趨勢是不沖突的，這種東西不觀察個3年、5年也觀察不出什麼，思考核心問題不怕早。并且，沒有公司需要一個35歲的活動策劃專員，努力認知業務是個人從點→面的過程。
二、TO B的業務設計概述
圖8：TO B的業務設計概述
1、業務分析
業務分析是為了“發現機會”與“預警風險”，對于TO B業務，除了正常的行業分析、使用者分析，需要重點關注“監管趨勢、政策走向”，并不是所有的行業監管都允許先粗放發展再加強監管，死亡可能是突然休克式的（電子煙、比特币）。
1）宏觀經濟
宏觀經濟的走勢對企業融資成本、現金流壓力是直接關聯的。對比個人消費者被宏觀經濟的影響有逐級的傳導遲滞，企業一定是更敏感的。
關注的核心子產品，包括：出口/内需/投資的戰略變化（例：近幾年對外資的政策松綁）、貨币政策的變化（例：近期的公開市場操作、準備金率變化）、稅收政策變化（例：增值稅稅率變化對業務進銷項的影響）、地方政策（包括：人口政策、産業政策）等等。
2）監管趨勢
順勢而為，是保障業務能夠持續發展的必要前提。滴滴規模近似壟斷後迎來的管制壓力，我認為本質上是國家對核心民生行業的行政幹預預期較高，因為涉及到社會穩定、安全，強管制是有必要性的。
同樣，像比特币這類去中心化、發行不由官方控制的所謂“貨币”，在目前的監管層面上，肯定也是無法被接受的。以大局為重，是一個取舍的過程，4.025%的年金險下線也是同理。
3）分析架構
分析架構需要站在行業的角度、客戶的角度、需求的角度，評估業務的可行性。
4）案例
做一款TMS（運輸管理系統），解決規模型車隊的管車問題。
1. 行業基本情況與發展趨勢概述
商流驅動的集約，受電商飛速發展的影響，中國集約性比較強的運輸領域以快遞為代表，CR5已接近70%，也帶動了一些成規模的運輸車隊（下遊）。
成本壓力逐級傳導，但由于快遞行業過于集中，核心企業貨量龐大議價能力強，成本壓力逐級傳導，中下遊的運輸公司經營壓力大。尤其那些重資産、大規模的車隊，其資産管理、資産使用率、成本控制等多個方面都對營運能力提出了極高的要求。
.....（不贅述，參考咨詢報告）
2. 客戶概述及上下遊分析
目标客戶畫像，擁有>100台卡車以上的運輸公司，因為這種量級的客戶才有優化管理成本的需求，目前這種規模的運輸公司全國大概有10000家（假設）。
客戶的上下遊分析，這些運輸公司的上遊是通達系、德邦這類大型快遞、快運公司，下遊有自有購置的車輛，也有社會運力。目前的行業現狀是：“運力相比貨源大幅過剩，整體議價能力較弱。”除電商外，整體商流的集中度不足、需求個性化，無法形成高度集中的物流市場
......（多元度、資訊詳盡）
3. 客戶在成本、效率上有什麼痛點？
效率瓶頸：公路運輸核心還是在成本、履約品質上，為了保障履約，部分企業購入大量固定資産（車頭、車挂）自營運力。與其他實體行業一樣，這将面臨着業務波動帶來的周轉效率問題。
品質管控：因為快遞、快運對于運輸的時效要求很高，供應商需要及時了解車輛位置，做好時效控制，降低時效罰款（大概占其總成本的5%（假設））。
邊際成本：實體資産無法像代碼資産那樣，邊際成本趨向于一個極低值，相反，每一個時間段内，一個貨車隻能運送一趟貨物，這就決定了該場景下技術杠杆不會特别高，營運的效能非常關鍵。
現金流壓力：中遊運輸公司需要承擔>2個月的賬期（甚至半年），相比快遞、騎手這類即付現金流的模式，賬期帶來的資金壓力也限制了業務規模。尤其在利潤相對微薄的情況下，即使通過保理融資解決了現金流的問題，其所帶來的成本上漲，對實體運輸企業也可能是不可承受之重。
......（業務經驗比邏輯閉環更接近事物的本質）
4. 業務的可行性分析
需求驗證：管車的需求是真實的，主要是為了減少管理成本、降低遲到罰款。目前競品已經切入了100家大客戶。付費意願大概在1500元/年，續費率75%。
注：上述資料皆為假設。
切入路徑：目前通達系的供應商（我們的客戶）都必須安裝一款XX品牌的監控裝置，如果想要切入該類客戶，本質是需要搞定它的上遊，客戶不會重複采購兩款類似的産品。
......（僅做示例，競争力評估、關聯市場影響等不在此贅述）
總結：隻有深入了解供應鍊上下遊的關系、供需基本面，才能更好地做銷售、産品、營運的決策。
2、業務設計
業務設計的重點是“知己知彼、産品下沉、營運業務”。
1）知己知彼，百戰不殆
不同的業務所處的行業周期、競争情況都很不一樣。但最抽象的一層，仍然是以“解決客戶需求”為核心。需要通過持續分析競品、完善服務體系、制定符合業務發展階段的增長政策，去建構核心競争力。
1. 産品分析
調研競品是一個自省、疊代的過程，主要目的是為了評估客戶需求集合的滿足程度，以及産品切入場景後的角色體驗問題。
關注客戶的核心需求滿足程度。B端業務需要滿足企業的需求集合，而非單點打透。如果産品功能覆寫度不夠，難以建構競争力。
例：一款餐飲Saas，80%的使用者不僅需要收銀功能，還需要“經營分析、報表管理、營銷管理、排号等位”等10項功能。産品A僅能滿足其中5項，産品B全部滿足，則産品A難以與B競争（價格相差不大）。
圖9：中國典型餐飲Saas競争力分析
産品的操作體驗是否能被客戶的組織接受，也很重要。如果僅僅隻是老闆買了單，但客戶的組織、各關鍵崗位無法接受系統的流程/互動，産品切入會受到各種各樣的阻力，落地困難。
2. 銷售政策分析
在有限的預算與HC的條件下，根據競品的銷售資源、銷售政策，去制定ROI更高、長線收益更大的銷售政策，是很有必要的。
- 客戶：梳理競品的客戶清單，盤點客情關系及服務深度。
- 政策：梳理競品的拓展政策，盤點其核心優勢區域及下一步重點拓展的區域。
-
增長：梳理競品在拉新、留存上的人力配置、補貼政策，能幫助我們更有針對性地開展差異化的增長政策。
例：産品A拉新方面投入了大量的線下力量，且線下銷售的核心任務都壓在了新增上面。此時，産品A通過“留存激勵”的營運政策，即隻要商戶交易額在次月保持上個月的80%以上，即可獲得“高額獎勵/折扣”等（通過電銷營銷），以此減輕線下銷售的存量客戶維護壓力。這筆營銷費用需要與所釋放銷售的獲客價值相比較。
2）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模型
總結：當角色的權限邊界較為清晰時，可考慮使用多對一的權限設計。若不滿足該條件，則最好使用多對多的權限體系（避免大量使用者都要獨立建設角色，變成一對一的權限管理），保障系統的可擴充性。
例：小代既是銷售營運，也負責财務對賬，那小代就應該同時擁有銷售營運與财務對賬兩個角色的權限。
3）卓有成效的業務營運
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）
4）靈活的項目管理體系
一個業務要持續前行，有兩種工作要做：
- 重複性工作，例：日常的資料監控、客服等營運工作。
- 項目型工作，通過完成一個新項目改善産品/營運，進而讓業務發展得更好。
圖33：業務與項目的關系
網際網路行業，業務從0~1的過程中，
- 需求變化很快、要求整個組織足夠靈活、高适應性地去為組織提供服務。
- 團隊規模的擴張，沒有體系化的項目管理，将出現：“資訊不對稱、進度把控弱、協同成本高、邊界不清晰”等問題。 圖34：項目管理的急迫性
萬字長文 | 如何做好TO B産品？
1. 靈活的業務營運
如同産品是疊代出來的，營運要持續優化業務，也必須采取疊代傳遞的模式，以應對多變的業務需求。
圖35：疊代式開發的優勢
我通過3年的實測與疊代，驗證了“建設以Scrum（靈活）為核心的項目管理體系，确實能有效提升營運團隊的自我管理、高效溝通、适應變化的水準”。
下面我會簡單介紹下靈活營運的方法。
2. 什麼是Scrum？
Scrum一詞來自橄榄球運動中的“并列争球”。在軟體開發曆史過程中，Scrum 先驅們将 Scrum 這個詞的隐喻應用于軟體開發。它是一套輕量級的核心價值觀、原則和實踐，統稱為 Scrum 架構，在這個架構中人們可以解決複雜的自适應問題，同時也能高效并有創造性地傳遞盡可能高價值的産品。
在這個架構下，我們可以檢驗團隊是否符合 Scrum 原意的要求：
1. 團隊成員是否有共同目标？
2. 團隊成員是否開誠布公地緊密合作？
3. 團隊成員是否經常檢視和調整？
4. 團隊成員是否各自發一顆球（各做各的使用者故事等），各自努力往後場沖刺以争取個人績效？
......
圖36：Scrum Porcess
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模型：基于使用者-角色-權限控制的一些思考》，公衆号：PM珣玗琪。
點個“在看”吧