漫談B端SaaS產品方法論

01、關於B端

最近B端產品的熱度慢慢上升了些，筆者開始收到一些同行的諮詢。在toB領域也算摸索了幾年，攢了一些心得，整理分享一下。

首先提一個問題，B端產品與C端產品最大的區別是什麼?

這個問題我也問過一些同行，答案不一而足。有的說設計風格，有的說行業垂直深度，也有說迭代速度。

我總結下來的答案是，最大的區別在於買單人。因為B端產品是面向企業售賣的，面向企業這個性質決定了它的一系列特點，這些特點又來源於究竟是誰在付費。

第一，產品的立足點在於幫助企業增長。由於企業的目標是儘量提高利潤，那麼其願意購買產品的動力是產品可以幫助賺錢，或幫助省錢。與C端不同，C端使用者的付費動機可以是用著爽，用著習慣，用著情懷。所以從這個角度往下切，產品經理必須要了解行業，瞭解一個企業基本的經營模式。這也是為什麼做B端產品會更要求行業深度，源自於此。

第二，產品的買單人是高層及以上，統稱決策者。由於產品是面向企業應用的，以及B端產品的客單價相對比較高，所以基本上企業的付費是走公賬的，走公賬意味著這不是一個個人行為，並且有較長的流程及多個角色的審批，那麼就需要一位能夠有決策能力的人來拍板。那麼一個產品能否賣得出去，就一定考慮怎麼打動決策者。

通常我們把決策者分為兩種，總監級與老闆級。總監級的特徵在於，他承擔了一個部門/事業部的KPI，他務必要讓花出去的成本有所收穫，所以他會計算ROI來決定要不要用某款產品。老闆級的特徵在於，除了希望公司多賺錢，他也需要監管員工的工作情況。以及他很忙，希望定期能看到產品使用的資料包告就可以了。所以呢，打動總監在於，讓他的產出更高。打動老闆在於，幫他賺錢，或透過管理內部來省錢，以及不要給他增加工作成本。當然對於小B公司來說，決策者有可能只是一個人，購買過程就會縮短很多，不過同時他們也會更在意費用多少，增加了一些價格上的糾結時間，所以最後也都是這麼個意思吧( :3 )

把這個方法落到產品經理的工作中呢，我們就會發現，跟銷售的同事保持良好的溝通很重要，因為他們非常清楚客戶的訴求，客戶的組織架構，客戶的工作環境。

第三，產品的使用者往往不是決策者。高層或者老闆級角色付費之後，一般是交給下面的執行者去實操產品。這兩種角色的差異在於，決策者在乎收益，不在乎使用者體驗。執行者在乎使用者體驗，因為他們不想增加工作量，但不太會在乎收益，反正也沒讓他們付錢。所以做B端產品有個點要明白就是，使用者體驗沒有那麼重要。它不能直接決定使用者的去留，連間接作用也比較弱。執行者往往只能用買好的產品，沒那麼多競品可挑剔。但體驗也不是完全無所謂哦，也要達到及格線的，不然執行者大量投訴，依然會給產品使用帶來阻礙。

第四，產品的設計是基於實際場景出發的，絕不可以玩空中樓閣。當面向企業中的使用者設計你的產品流程與體驗時，要明白對方已經形成了他們內部的一些機制和方式，所以要先去了解他們，而不是閉門造車地臆想對方或許是這樣使用的。作為B端的產品經理，我們可以最佳化他們的流程，不可以反對他們的流程。儘管都說產品要有創造力，那也要分場合，先保障基礎功能可用才行。這裡溫習一下上面的知識點：與銷售的同事保持良好的溝通，因為他們瞭解客戶。最好能夠去跟使用者面聊，收集到一手的資訊，記錄與整理好對方的實際工作場景，然後才能設身處地理解對方的需求。我自己叫這種思維方式為“順應”。cue一下產品原則之一：做一個好的產品，首先成為使用者。

說完了差異，那麼下一個問題，B端和C端最大的共通點是什麼呢?

對於要一款要盈利的產品來說，無論toB或toC，本質上都要回答的是：使用者是誰，你透過產品向使用者提供了什麼，使用者在為什麼而付費?

所以，結合這點及上面說的對於B端比較通用的幾條規則，我總結了一個產品設計中使用的自查表。

使用方法是首先去填滿它(……好像是廢話)，如果你發現有的空你都填不上，那不好意思你可能……只是個畫原型的。當你填完之後，再從後往前反推一遍，你的答案成立嗎?如果不能，很好，你還可以在正式開發之前校正你的產品路線。填寫與反推可能是個反覆的過程，會有點痛苦，好處是它迫使產品經理必須紮紮實實檢查自己的需求是否真的有用，提升了需求質量。

插播一個小技巧：有個快速準確的方法檢驗一個產品方案是否可行——帶著方案去準客戶面前講，觀察對方的反應。通常對方有兩種反應，第一種是微笑點頭表示挺好的，第二種問你多少錢。不要被第一種反應欺騙，他們的意思是這玩意兒挺好的但是自己用不上：)第二種反應出現的時候，恭喜，你的方案初步合格了。

02、關於SaaS

接下來我們往SaaS聚焦一下。為什麼是SaaS呢，原因很簡單，風大的先講唄 (=´ω`=)

這裡我會分三部分來闡述，一是商業模式的確立，二是產品設計與落地，三是1-100的經營思維。

第一，關於商業模式。假設你現在是一個創業者，你的目標是做某領域裡的SaaS佼佼者。那麼你要怎麼確定做什麼產品?

可以從回答以下幾個問題開始。

1.行業背景：該領域的產業鏈是怎麼運轉的?囊括哪些角色?

2.市場空間：每種角色的總的市場空間?目前已有哪些公司(使用者群體劃分)?

3.競品分析：已經有哪些競品攻下了這些公司?他們提供了什麼?使用者購買了什麼?

4.需求分析：使用者的需求都有哪些?哪些被滿足?哪些沒有?

5.落地路徑：如果選一個未被滿足需求來做，能否實現?實現路徑?營收天花板?(注，這裡的實現路徑不僅僅是指開發過程，而是從整個公司的角度出發，讓哪些人配合來完成生產+售出+售後的過程。)如果選已有競品的需求，那麼你跟他們的區別是什麼?

在做以上的推理過程中要注意前後順序，邏輯應該紮實地一步一步盤點，而不要跳脫。做商業決策是個複雜的事情，每一個因素都可能影響到結果，因素越多，最後帶來的波動越大且不可控。我們都知道這不是個容易的過程，所以更要謹慎，切勿因為有些問題太難就糊弄過去，比如回答4的時候直接用競品已經做好的事情來回答，那麼就會失去潛在市場了，也不可能完整地完成落地。

我畫了一張圖示意盤點市場過程中應該明確瞭解的內容之一：

比較粗糙，反正就這個意思吧(๑´ㅂ`๑) 。就是說動手之前心裡要有底。做產品絕不可以糊里糊塗。一個做決策的崗位一旦開始糊弄，就是整條業務線的災難。

另外真正決定要做什麼的時候，除了上述理智的分析，其實還有一個感性的因素存在。就是決心。《智慧商業》裡把它稱為信念之躍。(我很喜歡這個詞，所以稍微提一下，本文不再展示描述。)

第二，產品設計與落地。做設計之前請先溫習一個知識點：確保你足夠了解你的使用者。

設計分為兩個部分，流程設計與體驗設計。

流程設計的重心，是保證使用者的業務能夠完成閉環。閉環包括操作上對於使用者的指引，比如步驟一操作完成之後引導去往步驟二，比如確認使用者完成整個流程，不要讓其不清楚自己處在流程中哪一步。閉環也包括資料流轉的過程，比如使用者行為資料收集，比如使用者業務資料應用，要考慮的問題類似於使用者從個人中心上傳個人資訊之後資料怎麼放，如何統計如何重新整理，其他模組是否能夠應用，如果用的話資料以什麼頻率什麼方式傳遞。整體設計基於對業務、使用者、技術、資料的瞭解，所以對於產品經理的要求比較高。當PM在其中任何一環薄弱，就會直接嚴重影響產品質量。

體驗設計的重心，在於不要給使用者創造阻礙——包括流程性阻礙與細節阻礙。細節阻礙主要體現在互動設計上。這方面就考驗產品經理的基本功了——互動設計能力，同理心與責任心。為什麼要講責任心呢，因為要做好這件事其實需要大量的心力投入，反反覆覆去思考與嘗試使用者實操的場景，觀察與分析每一個細節。沒有足夠的責任心就不會支撐這種投入。如果是這方面經驗略少的話，推薦讀《About Face 4 互動設計精髓》，互動界的教科書之一。

第三，產品經營的1-100。

產品的經營分為兩部分，單個產品的最佳化迭代，和整個產品線的規劃。

對於單個產品來講，迭代方式來自於兩個方面，一是使用者直接反饋，二是資料表現。最佳化的點也集中在兩個方面，流程性問題，轉化性問題。在思考具體做哪些最佳化需求時，可以參照下面兩張圖：

這個圖的意思就是要對比最初做這款產品時候的預期與實際表現。對比的作用在於定位差異，然後尋找根因，分析之後嘗試解決差異。這樣能夠保證產品路線不會走偏。這裡也有一張自查表：

同理的，如果不知道怎麼填，那麼……就只是個畫原型的。同理的，這個表格的填寫也遵循反覆推理的過程。不過這個比上次做的時候會簡單點，畢竟聚焦到小顆粒的問題上了。

這個表填完後，最後一個格子“方案預期帶來的”的內容將作為下次分析時候的基準線。

我在實操的過程中發現，以上這些問自己的問題，以及這些產出的文件，都是一環扣一環的關係。每一步踏出，都應該基於明確的資訊，嚴謹的分析和推理。所以呢有必要存好一個產品的一生中的所有文件，這個思維我稱之為“繼承”。

單個產品的最佳化相對於整條產品線的規劃來說是簡單很多的。為什麼產品線需要經營呢?因為每個產品都有它的週期，出生，興盛，衰亡。產品依賴於使用者，使用者量是有限的，產品的增長就是有限的。但是一個公司的生意可以是無限的。所以一條產品線走到了天花板時，就需要第二條產品線。與前文做商業模式的確立時候不太一樣的是，這次的規劃是基於已有業務去考慮的。這點可以參考許多SaaS的成熟玩家——金蝶明源廣聯達，他們都從一個點做起，比如說財務管理，然後延展其產品至整個業務線，這種方式叫做管道式發展，也可以稱為縱向發展。當一條線的紅利吃掉之後，開始開拓第二個點，然後再做一條管道。管道發展起來，就開始橫向發展。這樣慢慢地產品從一個點，擴到一條線，再到一個矩陣，一張網路。就慢慢建立起了業務積澱和規模效應，從而發展出護城河。《智慧商業》裡提到一個點線面體的概念，類比於此。(cue了兩次，著實喜歡這本書。)

以上，感謝閱讀。

作者介紹：@一個圓圈兒，SaaS公司產品經理；擅長AI、搜尋、資料分析、商業化；智慧客服系列文章作者；“資料人創作者聯盟”成員。