全文約3077字，建議先收藏再看
權衡，這個詞貫穿了產品經理的職業生涯。
每逢遇到了做決策的時候我們總說“價值導向”，但當這個詞所涉及的組織和角色幾何式上升，各方的着眼點及利益點都不同，我們應該滿足誰的需求，資源又該向誰傾斜呢？
在B端產品的鏈路中，規模越大，組織和角色也越多。對於權衡，是很好的實踐案例。
在全心投入B端產品的這半年，在這方面也有了些更深的認識，本文將以B端產品設計爲例闡述對權衡的理解，希望能給大家一些幫助。
01 什麼是B端產品？
B端產品，其使用對象是企業或者組織，用於提升效率、效果等某一特定領域的問題。對比C端產品，其受衆不再是個體而是一類羣體，並且與業務的連結也更爲緊密。
B端產品的產生主要源於企業的規模化，組織結構增多、分工也愈加明細。鏈路的加長卻使線下運行的成本逐漸增高，無法使邊際成本真正地降低。
將業務簡化、線上化、自助化做到降本增效，也正是B端產品的作用。
另一方面則是由於市場成熟，業務模式的趨同。同一片紅海不會只有一艘輪船，無論是爲了保持先發優勢還是想後發制人，很關鍵的一點在於運營的效率。
效率的提升，能讓我們更高效的管理、更敏捷的試錯，從而更迅速的尋找優秀的業務模式。
02 如何進行B端產品設計？
2-1、梳理業務現狀，確立產品定位
產品經理需要有很強的角色轉換能力，對於B端產品而言，也稱之爲業務感。
設計B端產品需要將自身代入業務流程的每一環，對業務的現狀進行調研以及梳理。
調研的主要目標如下：
1）業務是如何運作的？
2）運作過程存在什麼樣的問題?
3）哪些問題已經被解決了，是誰在解決？
4）目前已解決的問題是否符合該業務部門、實施部門的規劃以及預期？
5）未解決部分不解決的原因是什麼？
6）適不適合由你的團隊來解決？
7）投入和產出是否匹配？
設計B端產品，大多會改變舊有的業務運作模式，可能是運作環境、運作流程亦或承載團隊。過程中會面臨無數的抉擇，我們需要慎重考量變更的收益能否抹平變更的成本。
在調研時應覆蓋鏈路不同環節的角色，不能只偏重於業務部門，還應考慮協作部門。其次不應只調研一線執行人員，還應調研負責人的預期。
在調研清晰後才能確立產品的定位，它能面向什麼角色提供什麼支持。產品畢竟是權衡後產物，只爲自身創造的價值不能稱之爲價值。
2-2、優化並確定業務流程
在上一步驟，通過調研企業中各部門、系統的業務流程，經過分析、評審確定了其中不合理的環節，下一步則是優化並確定核心流程。
跨職能流程圖的一軸爲部門及角色，另一軸多爲階段，下圖是以用戶運營系統爲例繪製的跨職能流程圖：
繪製業務流程目的是表達業務的流向，表現業務部門的業務關係以及作業順序，描述鏈路中起點、操作以及終點。
至於使用什麼工具、橫縱的規範、設計的細節其實並不是特別重要。
2-3、根據產品使用角色進行需求分析
B端的產品的需求，基本都來自於真實的業務場景，換言之，這些需求都是具有實現價值的。
但也正因爲是真實的業務，所以需求會牽涉許多部門、角色。鏈路的加長，會使“要不要做？什麼時候做？怎麼做？做到什麼程度？”這類問題複雜了無數倍。
在這一方面筆者的做法是通過梳理系統角色，從角色出發來權衡需求。
與平臺相關的角色，可以粗略的劃分爲決策者、直接使用者、間接使用者。
其具有以下特點：
在進行權衡時，價值導向是第一位的，但由於不同角色需求的產出價值是波動的，所以並未在上圖中表現。
在需求分析時，我們應根據其產出的收益決定資源的傾向、產品設計的深度。其次則是根據角色的代表、使用的場景、關注重心決定產品設計的側重點。
1）決策者
決策者的主要代表是業務負責人、平臺負責人、協作負責人，他們是決定是否使用這個平臺的人。雖說價值產出會抖動，但決策者的需求優先級大多在第一順位。
其關注的重心是邊界以及收益，邊界是指業務流向是否正確、人力損耗是否減少，收益則是否正向、是否達到預期。
直接和間接使用者，更側重於局部的價值，而決策者則更側重於全局，在產品設計上我們須考慮的是決策者的全局視圖。
2）直接使用者
直接使用者首要的代表是業務運營，他們是產品發展的中堅力量。
其對產品的依賴性越高，產品創造價值的可能性才越大，業務運營的需求優先級略低於決策者，但大多數情況高於其他的角色。
在需求分析上，由於業務運營的需求零散且差異性高，我們需要提煉業務的共性，犧牲較爲定製化的邏輯，對平臺而言，全局效率的提升會比個別業務的體驗更爲重要。
在上圖中，還包含了平臺的研發、測試以及運營。這是因爲只有支撐人員的效率提升，纔有更多的資源能投入到業務需求以及非功能性需求的建設之中。
在需求分析及資源傾斜時至少要保證30%的資源分配給於非功能性需求，否則暫時性的繁榮遲早會被故障擊破。
當業務支持和產品建設形成良性循環，能用和好用兼備，業務運營乃至決策者的觀感纔會不斷提升。
3）間接使用者
這一角色，多爲與平臺業務某一環節所關聯的研發、測試成員。其關注重點是，做什麼以及怎麼做。
前者是邊界，後者則是接入或使用的流程和規範，在這裏則不贅述了。
2-4、沉澱業務需求，封裝標準化服務
B端產品的本份是降本增效以及建立規範，而建立規範又來源於“降本增效”的沉澱。
什麼時候應該考慮標準化呢？在觀測時間線足夠長的前提下，應符合以下的條件：
1）系統建設足夠完善
2）業務模式足夠成熟
3）標準化的收益能超出變更的成本
如果標準化的需求被拒絕，不妨在深入思考需求背景是否符合上述的條件。
關於標準化的細節可以查看此前關於《前端配置化系統的設計思路》，這次想談談標準化可能陷入的誤區：認爲解耦一定能提升效率，更愛設計組件而非插件。
對於迅速變化的業務系統，插件更能夠提升效率，組件卻可能增加枷鎖。判斷是否插件的標準是：是否獨立可用，插件可以靈活組裝、隨時捨棄的，組件卻是相互銜接且密不可分。
電腦主機上的USB接口，只要硬件符合接入標準，無論你是U盤、硬盤還是手機都可以與之通訊。而組件則如同電腦的主機，運作需要有電源，將數字信號轉換爲模擬信號則需要顯卡。
但無論哪種思路，始終還是爲了快速響應業務，如果標準服務反而拘束了業務的發揮空間，影響了C端用戶的操作體驗，這就本末倒置了。
2-5、效果追蹤與資源再分配
效果追蹤，是權衡的重要工具，其作用是監測產品穩定性以及評估業務價值。
前者是執行效果，後者則是運營效果，這兩個數據的提升，都能幫助各個團隊建立信心。
執行效果，指在一定時間範圍內執行的任務數量、速度、成功率、錯誤率等，更偏向產品的風險控制，如果執行效果不達標，前進一步卻退三步，支持再多的業務也沒有意義。
而運營效果則是B端產品價值的體現，雖說B端產品的價值之一是降本增效，但當效率面向不同的業務模式、運營人員，會讓量化變的很困難。而另一方面，提升效率也不一定會提升效果。
運營效果的追蹤，一方面能夠使運營閉環，另一方面則是爲了資源的再分配。
如果將企業比作一輛汽車，C端業務更多的是在踩油門，而B端支撐則更多的要考慮踩剎車。提升效率不僅是簡化鏈路、優化流程，還包含停止投入。
追蹤業務效果，可以讓我們知道業務的優劣對比，幫助我們決定資源傾向。
寫在最後
最後談談個人心態的變化吧，得益於B端的確定性更高，讓我能夠有信心、耐心，願意看的更長遠些。
以前的我喜歡追求產品設計上的難度，不喜歡做簡單的需求，甚至還會對業務同學不耐煩。現在則不再在意難度，只在意有沒有用，也許有時做的事情並不“高級”，但我卻能夠堅定的往前走。
產品的路很枯燥也很漫長，“做好的產品，不是做好的產品經理。”這句話與大家共勉。
往期文章