作者 /祝百萬
來源 /本文系產品獵人“Hunter”計劃投稿作品
To B和To C的產品經理對用戶的期望值截然不同。
To B產品設計是幫用戶解決問題，希望用戶用完即走，或者默默使用，但潤雨細無聲，讓用戶感知不到。
To C產品設計，會想盡一切辦法佔據用戶時間，拉長用戶使用時長。
總的來看，To B產品佔據的是用戶時間背後的價值，提供的價值越大，用戶越願意付費。
從這個角度來看，To B產品經理更“霸道”，不care用戶使用時長，更關注產品能給用戶提升多少效率、帶來多少價值。
本文為一位產品經理對To B產品設計的思考（上篇），細致分享To B產品設計與To C的差異之處。
該文來自去年的一次分享中的一頁ppt，由於分享時間有限，表達很淺，這裡會把那次分享的部分，分成幾次，分篇闡述。
自從有To B以來，鮮有產品經理的崗位。傳統To B領域裡面，產品並非是必要的崗位。有些是用項目經理，有些是用售前和研發去支持。但不管工作職責的劃分如何，對於產品設計的關鍵點，並沒有因此而改變。
然後，大多產品的認識和了解，容易停留在To C的情形，因為產品經理的興盛，是隨著To C來的，若一個To C產品領域的大神有一個法則，那麽大家都會爭相模仿，甚至奉為圭臬，若稍有不同，便會招來爭論。好像大家都習慣了經典物理，突然量子大門打開了，但大家都容易以最初的方式理解新的情況。
本文將會論述4點To C和To B不一樣的地方：
有情 VS 無情
人性 VS 理性
賣身 VS 賣藝
玩具 VS 工具
本文為上篇，僅論述前兩點，對於第一點，又分為4小點：
個體 VS 角色
情緒 VS 問題
瞬間決策 VS 決策鏈
留下 VS 離開
不管是To C還是To B的產品，設計出來，雖然都是人在使用，但是對於個人來說，他可以跳出他的社會角色來使用。而我們設計的產品，大都是當用戶處於職位角色才使用的。
例如一個人打遊戲的時候，不管他平時的職位高低，是從事什麽行業，他都能按照自己想要的方式去操作這個遊戲。
而若某個公司的DBA使用騰訊雲的數據庫，他就必須按照規範來，這裡的規範，其實就是社會角色對他的約束，遊戲可以不想玩了直接推出，大不了這局就輸了，而線上的操作則必須按時保證質量的完成，大部分To C設計出來的產品天然是社會角色退相乾的。
因此，產品設計的時候，我們得考慮這個職位的角色賦予個人的規則來設計，例如，一個DBA通常是把業務切換放在對客戶影響，或則還是收入影響最小的時候，而這個時候往往對於個人來說，是他們的休息時間。即To B和To C產品，至少在這個情景的時間點上其實是錯開的。
其次，使用的情緒是不一樣的。往往個人使用某個消耗其時間較長的產品，是為了表達或者宣泄某種情緒，或者是讓產品來撫慰自身。若是不斷的刷視頻，是後者，若是不斷的發視頻，是前者。他們當情緒得到滿足就會完成一次大腦刺激放鬆，最後歸於無聊，然後再度循環，終而樂此不疲的不斷循環，可能內容不一樣，但形式大都是相同。
而To B的設計，往往是帶著問題的。通過使用產品，解決我的某個問題，例如解決我計算量不夠的問題，幫我做圖片識別，幫我提供更大的訪問帶寬。這裡的不一樣，會導致我們設計產品的許多出發點不一樣。
例如，當你的目的是要讓客戶情緒得到滿足，那可以多留他一些時間，讓信息一層層的傳達到他，層層深入，循循善誘，而又欲蓋彌彰，各種關卡不斷的挑戰用戶的獵奇與滿足。而當你要解決問題，那必然是高效的，及時的，準確的，可預期的。這樣設計出來的產品形式，就會完全不一樣。
再次，個體的決策過程和企業會差別很大。個體的思維誤區，衝動決策，從眾心裡是非常常見的，也是我們產品設計時候可以利用的點。例如設計一個產品的展示中，美女在使用某種化妝品，人們會不自主的認為使用了該化妝品，就能會和這個演員一樣了。也幾乎不會有人直接去追問該化妝品的成分以及百分比、生產過程的副產品可能有哪些、吸收後的藥動力代謝、相關的研究論文和國內外聲音等。
然而To B的決策就是如此，尤其是大公司，他們看完廣告基本的態度是“好的”，“呵呵”，一定要做測試驗證，或者是要求你去交流，講清楚原理和風險。這樣，他們做下來的決策，才會是風險最小的。
因此這裡的設計，也會讓我們很多得到很多經驗，例如不必去過多的去把他們導向到一個可能並不適用的場景，或者刺激用戶，因為他們足夠的理性。他們會很快回過神來，同時，運營活動也不必保太多期望，因為那些目前不需要的，他們是幾乎沒有衝動消費的情況的，伺服器不用，反正便宜，不買就虧了，先屯著，剁手黨在這裡是幾乎不存在的； 其實我們很少去提今年運營活動增量，有多少是由於活動本身帶來的額外量，而不是本來就有的增量，或提前透支的量，直接去做同比，其實並不是一個邏輯上自洽的解釋。（這個問題，我將會在後面的文章展開討論）
有了前面三點的論述，第四點就好理解了。To B設計是要幫助用戶解決問題，因此希望的是趕快用了就走，沒事你真的連用都不要用，或者說是默默的在用，但潤物細無聲，讓你感覺不到，這是最妙的。這個和小龍對微信的小程序定義算是不謀而合了，但推導的出發點是不一樣的。
而大多To C的設計，會想盡一切辦法佔據用戶時間，甚至某些產品的考核，就是看用戶使用、觀看時長，用得越多，我廣告的機會和時間也越多，獲取用戶信息也越多，能做運營的口子也越多，對於收入的想象空間也越多。
而To B，是在佔據產品背後的暗時間，或者是說時間背後的價值，提供的價值越大，用戶越願意付費。例如，原來的AI服務，3小時計算完成，而升級後，10秒計算完成，顯然升級後的，和用戶的接觸時間少了，但卻更高效了，也能收更多的錢。
接下來，我們開始討論第二個大點，也分為4個小點：
模糊 VS 精確
便捷 VS 強大
意外 VS 確定
休閑 VS 壓力
首先來說第一點，和第二點。在功能設計的時候，To C和To B的立意，是不一樣的。你使用微信的時候，你會發現不能批量操作的地方很多，也不能自定義你的菜單，要把聊天記錄和聊天中的視頻上傳到雲盤備份，還不能直接操作，諸多不便。
然後To C的產品會給你一堆為什麽要這樣做的理由，而你又能說出一堆你的需求。這裡有一個區別很大的地方就是，一個基本的To B產品，是沒有選擇用戶群體的機會的。你需要能支撐所有用戶，當然未必是所有的場景。
例如，用戶買域名，不管是大客戶還是中長尾，都無差別的需要域名，因此功能上，需要既滿足對技術沒有積累的初步使用的客戶，也要滿足在功能上要求細致的重度使用客戶。但是一旦設計複雜了，兩種客戶看到對方的視圖，就會覺得產品不友好。因此，這裡的設計，就天然變成了京東+拚多多在一個APP裡面，我們設計的時候，不得不考慮。
第三個點，To B客戶對確定性的期望要遠遠大於To C。例如，出現了故障，到底什麽時候恢復，到底這次問題影響的時間多久，下次還會出現類似問題嗎，是否有能覆蓋我損失的賠償方案。而To C裡面，若出現故障，一般會告訴你稍後重試，除非是事先的停服，然後版本跟新後，給你總送一些鑽石，金幣，用戶會有一種感恩戴德的感覺，因為沒有那裡規定必須要給。
有一個非常小，但很有代表性的例子，數據庫做退貨退費的功能的時候，有一個按鈕叫做“銷毀”其實本想表達的是既銷毀也退錢，而用戶從字面上看，看不到退費的意思，因此一些用戶不敢點，來提工單退費。一個小小按鈕的表達，意思並沒有滿足用戶期望的關鍵點，導致了這個案例，最後還得補上。
最後一點，是很多人使用To B產品不一樣的地方。曾經有多次都聽人說過，覺得釘釘的設計，是反人類的。非常的讓人討厭，不斷的彈消息，自動語音等。然而，從工作的角度，會發現這個無比的方便。再有一個例子，也很典型，企業微信剛開始的時候，和微信一樣，沒一條消息是不展示時間的，當然也沒有已讀未讀，To C的時候，展示出來其實會給看消息的人帶來壓力，而To B就不是。
我們數據庫在設計的時候，有錯誤日誌了，主從斷開了，應該都是把消息給到客戶。這類功能，都有一個共同的特點，就是給客戶的壓力明顯比To C的大。To C更多時候會避免把複雜的東西給到客戶，因為我們自己也天然是客戶，我們能從客戶的角度理解，並消化這些情況，遊戲的設計者，一般都是非常重度的玩家，天天都在用自己的產品，你才能做好。
而To B我們天然不是客戶，客戶還在不斷變化，你也許了解遊戲，但你不一定了解金融，或者零售，世間的行業太多，一個人的經驗，你是不可能全行業覆蓋的。因此，也很難設計以一個統一的策略，發現每種客戶都是最好的。
所謂眾口難調，To C和To B的解決辦法是不一樣的，To C是，請出去，我們不賣牛排，To B是，有川味和麻醬，還不喜歡的，佐料在那邊，自己打。因此，我們在基礎能力設定上，會把更多的選擇權交給客戶，然後為了體驗優化，再到上層去封裝解決方案。這樣，你才能夠最快速的建立基本能力，然後再慢慢重構。
上篇到此結束，總的來說，To C產品在角色、情緒、場景等的不同，導致了功能、壓力、確定性等的要求也不一樣。若我們習慣了“傳統”的產品思路，就非常容易帶來各種問題。下篇中，我們將從服務、SLA的角度來繼續討論這個話題。
To C的產品設計，有些時候其實可以囫圇吞棗，模糊一些，因為你為了把一個東西表達清楚，可能會讓產品本身變得極端複雜，而大部分個人、或者大部分場景並不需要這麽清晰。設計簡單就好。
而To B的設計，則不然。盡量的表達精確，因為一個不明白的描述，會直接涉及到用戶在設計自己方案的時候出現問題，最後傷害到最終的數量不可預期的用戶，也就是說，這裡的模糊或者是精確，會被放大，To C裡面很少會被放大，即便以後，也不會想To B這樣明顯的放大，例如客戶對一個字元集的理解錯誤，會導致他所有用戶數據變成亂碼。
香港九龍灣馬來街興發大廈15樓D室