從用戶到場景，從場景到產品使用路徑，全面的梳理復盤過程產生的新的需求點，對於簡單需求形成各方滿意的初步方案。
本月復盤內容簡述
現狀問題：司機拉不上來，沒有司機貨主的貨就沒有人拉。GMV就上不去。怎麼解決？
解決目標：降低拉新司機門檻
產品提案：司機操作簡化：下載APP、提交認證資料（用戶中心）、運輸中操作（司機端操作裝卸貨地點擊手機）
Case1：能否不讓司機下載APP？Case2: 能否讓司機提交資料後置？Case3: 能否幫助司機提交資料？如：銷售幫助司機提交（通過銷售移動端）
分析及說明
Case1:是否可以用小程序替代APP？
Result：
與獨立App相比，微信小程序更多的受限於微信體系。APP所具有的簡訊推送，站內推送等手段也會在一定程度受受制於微信規則。微信小程序較App而言，運營自由度也會相對降低，運營難度更大。其次，對於有支付強需求的產品而言，微信小程序內部設計支付功能，就很可能會產生被支付寶的屏蔽風險，在這一點上，App就顯得得更加靈活性並擁有獨特優勢。更多分析可參考《如何選擇移動端？》
Case2:能否讓司機提交資料後置？
Result：不能。
原因主要有兩個：第一，接單籤約時必須確保運輸協議所關聯的訂單車輛和駕駛員一致；第二，司機在運輸過程中，平臺需要監控運輸過程，並且在裝卸貨低獲取駕駛員位置。那麼前提就是能證明駕駛員就是註冊的司機用戶。
分析依據：《網絡貨運平臺管理制度》中運輸過程監控部分強調，網絡貨運平臺應驗證訂單裡的車輛和駕駛員一致，並且在裝卸貨地獲取駕駛員位置。
因此，即便是司機提交資料後置，我們也必須限制司機在接單前就完成人和車輛的認證及綁定。所以，為了保證運輸協議籤訂是真實的，現在產品是先完成駕駛員認證後接單的途徑是唯一合規的方式。
Case3:能否幫助司機提交資料？
Result：能。
如：銷售幫助司機提交（通過銷售移動端）
從系統上線至今，我們從運營、業務都接收到這樣的反饋：司機的註冊認證基本是銷售代勞。
既然如此，我們完全可以為銷售提供拉新司機的移動端小工具，用戶採集司機認證資料。並且通過我們的中臺完成認證資料的審核及司機帳號的激活。如果提供這樣的銷售小工具，銷售拉新司機的方向就需要做微調。
首先，拉新司機變為採集司機資料並送審。這一項是需要銷售團隊提供考核標準給產品組做依據，先明確如何考核再考慮如何完成產品支撐。
其次，銷售依然需要解決司機不願意下載APP的問題，並且需要調整開拓司機的戰略及話術。
從復盤到Workshop
產品經理對曾做過的產品，曾參與過的項目進行復盤是很自然的學習過程。學習-思考-實踐-總結-再學習，這是一個個人能力長期迭代的過程。
作為產品經理，保持學習總結的態度和能力，是非常重要的。2C的產品經理學習的成本較2B的產品低，因為純網際網路的產品可參考的案例多，用戶場景也雷同。B端的產品，業務屬性強，線上線下結合緊密。因此，2B的產品經理，其學習的成本就很高。
2B的產品經理主要來源於三種場景：
帶研發項目，項目逐步標準化為產品，轉產品經理；技術出生，帶過幾個初中級產品經理，變相是產品經理；做解決方案寫PPT的售前，接觸客戶多，能補充業務場景帶隊做產品，然後找技術負責人打配合。從不同場景成長起來的產品經理，需要學習的方向和目標也是不同的。但是無論如何學習，復盤一定是必經之路。復盤過程是就專項問題做專項分析。
分析過程可能需要組織項目組成員完成多個Workshop，在Workshop中，我們需要完成對復盤內容及後期規劃的出結論性產物。
結論性產物一般含四類：
項目組成員需要對業務關鍵流程及關鍵需求點再次達成決策；產品經理負責評估復盤過程中，總結出的需求點的可行性；項目經理+產品經理，需要識別並剔除不合理需求，特別是投入產出比低的需求要慎重處理；會後，由產品經理形成清晰的會議紀要，並且在可控時間內完成需求文檔。
總結
從復盤到Workshop的過程，我們需要對於簡單需求形成各方滿意的初步方案。通過描述Userstory的方式，從用戶到場景，從場景到產品使用路徑，全面的梳理復盤過程產生的新的需求點。
採集需求-分析需求-整合需求-再分析需求，是產品經理重要工作之一。需求挖掘的過程就產品了解用戶，熟悉業務的過程。
特別是2B的產品經理，能從眾多需求中，有效兼顧可行性、投入產出比、業務改善等複雜問題，是非常不容易的。多學習，多復盤，多思考，才能把B端產品做好。
#專欄作家#
《從需求到產品：0歲產品經理進階之道》作者，善於C端產品體驗，B端產品模式設計。
本文原創發布於人人都是產品經理，未經許可，禁止轉載。
題圖來自Unsplash，基於CC0協議