這“2.5”個B端產品方法論，我想分享給你
編輯導語：關於B端產品的相關知識，大家已經瞭解了不少，然而關於B端產品方法論，不同的人會有不同的見解。本文作者通過回顧自己4年的平臺產品工作經驗，總結了“2.5”個B端產品方法論，希望對你有所啓發。
距離上次發表文章已經過去30+個月了，在當下這家公司負責了15+個項目（還沒算上一些不成項目的流程優化），高效的工作效率/溝通效率讓我能夠同時負責多個項目且腦子不堵車。
接近4年的平臺產品工作經驗，又臨近工作更換的節點，將這段時間的一些個人思考和收穫梳理成型，和大家分享。
前言： 由於行業/公司/部門的情況不同，造成了不同產品崗位所需要的能力不同。但抽象一下，所有（產品）崗位提供的都是解決問題的能力。當然問題是五花八門的，但解決問題總有相同的方法/思路。
籠統來說，解決問題總共有三個步驟，且分先後：
- 分析問題關鍵
- 提供解決方案
- 效果驗證
- …
- 循環迭代（分析/解決/驗證 新的問題）
一、分析問題
在分析問題上，有個很著名的梗<怎麼把大象放進冰箱？>。答案大家都知道<打開冰箱門，把大象放進去，關上冰箱門>，不妨就以這個問題來展開討論。
1. 細化流程
分析問題的首要步驟，毫無疑問是要先細化問題。一個天馬行空的問題，不代表問題本身100%是天馬行空的，一部壞的電視機可能只是某個零件出了問題，放大象進冰箱我們也可以幫忙開關門。
可惜的是，大部分人的第一反應是對問題本身全盤否認。而一旦否認問題後，問題解決者的價值也就一同被否認了（或者變成了否認提出問題的人的觀點），畢竟沒人願意爲一個解決不了的問題去投入成本。
回到放大象進冰箱的梗，細化流程之後，問題就清晰很多了。
- 打開冰箱門——可行（成本低）
- 把大象放進去——存在難度（成本高）
- 關上冰箱門——可行（成本低）
再對第二步拆分，從某地把大象運到冰箱前，引導它進去。流程拆分得越細，要解決的問題就越清晰，相應的，解決問題的方法也就越清晰。
2. 到底要多細
我的答案是，細到能解決的地步，或者盡你所知道的程度就足夠了。這分兩步細到能解決，問題解決了，繼續細沒意義，除非再細下去能有替換方案降低成本。
儘自己所能的細，是自我安慰的選擇。信息/知識 容納量的大小，在一定程度上等於一個人的智商/能力/價值的水平，不要在超出自己能力範圍的東西上對自己要求過高，否則只會給自己帶來挫敗感。
而儘自己所能的細，要做到這一步也不容易。這要求我們對自己所瞭解的東西融會貫通，做到舉一反三。在工作場景中，這要求我們能夠結合項目過往的內容/正在執行的方案/將來可能的規劃，給出一個成本最低的答案。
再結合例子來看：
- 從某地獲得大象使用權（當然偷一個也行，不過違法的成本可能是無限大的）
- 運到冰箱前
- 引導它進去
如果公司有錢買下一頭大象，那麼使用權問題就解決了。如果公司剛好是海運行業，那麼運輸問題就解決了。如果公司裏面有員工當過動物園飼養員而你又知道，那麼引導的問題就解決了。
但公司能用的資源往往不是充足的，如果能創造出未有的方法（將成本無限大的問題轉爲成本有限的問題），或者選擇更低成本的方法去解決，中間的gap就是問題解決者的價值所在了。
這個方法在現實情況中也是多種多樣的，可能是員工的人脈關係，過往工作的知識儲備等等。
3. 爲什麼要做？
在ab兩點上，都是對問題提供解決方案的思考。
而在實際工作中，特別是產品經理，經常遇到上下游提出的各種需求。這要求產品經理在問題的出發點上進行更多的思考，做不做，爲什麼要做，做了後收益是否足夠可觀，而不是直接埋頭去想怎麼做。
如果僅是爲了展示部門能力而把大象放入冰箱，那麼將部門的資源拿去買大象（內部消耗）是否值得？但如果是爲了向股東/客戶展示能力而獲得更多合作機會，那麼聽上去就是一個不錯的方案了（不過我在工作上，很多時候都是先思考細化流程，分析發現成本過大，反推目的，梳理責任邊界，然後拒需求的hhh）。
在分析問題的方法上，分享一些我實際遇到的例子，解決方案足夠旁大的都已經成爲我簡歷上的項目了（我的經歷在文末）：
- 如何減少一線人員的划水情況？
- 如何對比內外部模型水平差異？
- 如何降低線上工作和質檢工作環境的差異？
- 如何設計一個評分彈窗？
實際上問題3在實際工作中沒有暴露出這麼明顯，當時情況是質檢準確率總是比較低，經過一番調研後才發現這個問題，這也比較符合大部分產品經理實際工作遇到的情況。
而問題4是我在面試中遇到的一個問題，它掠過了問題分析的步驟，要求直接提供問題的解決方案。但是評分彈窗何時出現，用戶評分結果要用在哪裏，都沒有給出，設計起來就比較困難了，面試結果也不如人意。
那麼如何設計一個評分彈窗呢？
二、提供解決方案
後臺產品的設計往往是爲了支撐上游業務，提供信息化的傳輸/協調能力，從而加快整體流程，達到節省成本的作用，規範/加快/簡化業務流程是解決方案重要且基本的要求。
在此之上，節省開發成本的多少，是區分產品優劣的另一個因素。如何降低開發成本呢？有三種可能，且一般情況下優劣同先後順序：
1. 當下開發成本爲0
這意味着，用現有的流程去滿足新的業務需求。
已有流程可能不完美，但如果能快速實現，且滿足業務方的關鍵要求，對比之下便是最好的選擇。還有一點是，緊急的流程可能是低頻且不重要的流程，畢竟如果足夠重要，往往早已實現，或在部門的大規劃上。
入門的產品經理在面對業務需求時，對現有功能/歷史情況不瞭解，即使明明有菜刀了，還要另外造一把匕首。
2. 有多個方案的情況下，選擇開發成本最小的一種
運大象到冰箱前，還是運冰箱到大象前更簡單？新規劃一條航線去運大象，還是將原定航線上的船空出來一個位置比較節省成本？這個選擇很簡單，但可能會和3衝突。
3. 流程可兼容日後流程/規劃，節省以後的成本
如果逼不得已要新建一個流程，最好將其做到足夠通用（減少個性化）。而通用的要求是，先將多個流程的維度抽象出來，變成一個個個性化的值。這麼說有點模糊，放出我一般梳理需求時都會用到的excel表：
（表1）
（表2）
表1是對錶單設計時的信息梳理。後臺的每個任務（電商入庫，每個貨物/包裹都是一張入庫流水單；oa系統，每個用戶/id都是一條記錄。
如果信息過多，則通過uid將儲存在不同庫表的信息關聯起來）都對應一條數據記錄，而每條數據記錄都有自己的信息，通過將實際的線下流程節點和記錄的狀態數據變更觸發點關聯起來，一個個流程便可以實現。
可以看到，我：
- 首先將每個任務需要記錄的信息維度列出，比如任務名稱/任務時間/…這要求我們對所有場景的流程需要用到的相同信息抽象出來；
- 再將信息維度歸類，歸爲任務信息/業務範圍/投放時機/…信息歸類可以幫助產品自己對每個信息的用處有更深的瞭解，對開發同學設計庫表，理解業務時也有幫助；
- 根據每個場景，制定每個維度裏面都有什麼值。
表2與表1的區別在於，表1是對一個個任務（如實物）的信息進行抽象，表2是對一個個流程（虛物）的將信息進行抽象。只要練習多了，就可以將不同對象都按照不同維度抽象起來。
實際上按照不同維度來抽象描述，這和技術同學的[面向對象編程]有相似之處，而日常在介紹各類內容時，我們也是按照一定邏輯/維度順序的，比如時間順序、空間順序…
這個方法可是我的壓箱法寶了，它幫助我在一天內就把這個容納了雙審/質檢/培訓的系統方案給梳理完善出來。當然，我所負責的業務的流程複雜程度相對而言是比較低的，有些行業的線下業務流程可要複雜得多，但抽象總是有用的。
以電商流程爲例，如果抽象的流程爲[入庫]，那麼購置的貨物入庫/退貨入庫/調倉入庫/…是不是都可以使用同一套流程呢？只是貨物來源不同，那麼貨物來源又可以定義爲一個維度了。
三、效果驗證
這part主要描述的內容是 [制定關鍵指標]（結果），以及不只看[關鍵指標]（關注過程）。就當0.5個，下次有機會再分享吧～
本文由 @Ien 原創發佈於人人都是產品經理。未經許可，禁止轉載。
題圖來自unsplash，基於CC0協議
