筆者在“A公司”設計了一套支撐定義為“大宗物料”運輸業務的B2B交易平臺，這個B2B平臺有著偉大的規劃：

• 出發點：和客戶一起解決問題；

• 立場：客戶；

• 目的：創造我們的價值。

那么這個物流交易平臺“從0到1”發生了哪些故事，筆者將通過幾個小故事娓娓道來。

故事一：“邪惡”王后的目標只有白雪公主之定位客戶

王后的魔鏡告訴了她，誰是世界上最漂亮的女人，現實世界可沒有那么厲害的鏡子，那么物流行業的用戶只有通過物流行業這個大分類，來做精準定位了。

物流行業，如何定位客戶？調研行業用戶、演算服務用戶成本、確認企業自身優勢來抓去用戶痛點，及企業自身優勢能夠給出的解決方案。

step1：了解定位客戶群的方式

1. 匯集企業現有可用資源，列出企業可能服務的客戶群；

2. 深入了解行業客戶群的痛點，了解方式：

3. 摸索企業能夠給客戶群帶去的痛點解決辦法；

4. 精細演算能夠從客戶處取得的投資回報數據。

小結：收集資料后的簡易適用的歸納用戶群的方法，將出現率高的內容->統計求和->按求和數據從高到低排序。

step2：企業能力畫像及用戶畫像分析

筆者的A公司，成立之初，技術團隊僅10人，包含：老板、財務、UI、產品、技術經理、Java、iOS、Android、測試、web前端。

從人的角度切入行業，根據收集資料，分析數據，歸納了用戶畫像及用戶的痛點。

企業能力畫像：指企業能夠提供的基本能力，也是吸引員工為之拼搏的唯一動力。

用戶畫像：基本屬性+興趣愛好+訪問屬性+使用競品+意愿屬性，實際為了解你所圈定用戶的行為習慣及使用互聯網產品的意愿。

小結：用戶畫像，被企業自身具備的能力所限制，比如：不熟悉冷鏈/零售，因此不會在冷鏈用戶群體上花太多功夫，過多的研究與測算會耽擱一家企業進入市場的時機。

A公司主要服務用戶一開始就已經定好為：代理人、供應商、3PL、無車承運人企業，司機等，收集資料并且分析數據僅為論證服務的方向是否在承受范圍。

step3：用戶痛點的解決方案

通過用戶調研，形成用戶畫像的同時，歸納出用戶想要解決的痛點，以及企業能夠提供的解決方案。

小結：確認用戶痛點后才能知道企業設計的產品，如何給用戶賦能。按照調研歸納出痛點后，一定要給出自己團隊能夠做出的初步解決辦法，才能在產品設計時有針對性的處理方案。

故事二：人人都是魯班大師之產品設計

了解了用戶痛點，做產品設計 ，這個環節最容易硝煙四起，A公司為了快速打入市場，只給了3個月的時間，實現上線推廣。

那么，我們一步一步的來，首先要考慮要什么客戶端？

step1：確定要通過平臺完成的業務流程

經分析研究客戶群體的線下業務，平臺將提供兩種業務模式的流程支撐用戶：

1. 無車隊合伙人模式：

2. 有車隊合伙人模式：

step2：整理業務角色、及其要使用的功能

根據業務角色所需要的功能，結合用戶痛點，結合業務分析，考慮通過業務系統PC端、司機端、運營PC端來實現支撐業務。

1. 業務系統PC端：

命名為XXTMS運輸管理系統；

服務對象：發貨人、承運人、收貨人；

服務目的：達成用戶對于用戶、司機、車輛、組織架構及業務流程的管理，司機的跟蹤、報表的管理等。

2. 司機端APP：

服務對象：個體司機和合伙人；

服務目的：達成個體司機承運、合伙人司機接單、分配司機、轉賬給司機等；

3. 運營PC端：

服務對象：公司內部員工，運營、產品等；

服務目的：管理TMS運輸管理系統、司機端客戶數據，便于企業研究分析用戶行為。

考慮TMS運輸管理系統，是給用戶提供一套便于操作的后臺，因涉及到大量業務流程管理實時處理、實時運費結算、用戶管理、報表統計、數據查看、貨物跟蹤管理等功能操作，用PC端實現比移動端方便，實時性比H5穩定。

司機端的考慮，主要為優于小程序及H5的穩定性，尤其是涉及到收取運費、轉賬等功能。

運營端的考慮，主要是為了A公司維護用戶資料，及做數據統計。

劃清楚了業務系統邊界，這個時候就可以考慮整體的功能架構設計了！

step3：功能架構劃分

列具體功能之前，同研發人員一起先確定企業能夠搭建的通用架構，可復用的基礎結構，便于日后的架構擴展。如下圖所示：

TMS運輸管理系統功能劃分：

做功能劃分時使用用戶操作路徑的方式排列，主要實現用戶痛點之一的：單據管理、調度車輛；監控車輛；報表管理；

司機端功能劃分：司機接單、收款；

運營端功能劃分：

各個端的產品功能已經梳理了出來，但是3個月能一起設計出來嗎？即使通宵加班加點，也需要一個理智的產品經理來定義一個最小MVP，滿足系統準時交付的同時又滿足BOSS和市場同事推廣后能夠讓用戶跑通業務流程。

那么在從0到1的過程中，筆者使用排優先級的方式劃分一期（MVP）；二期、三期迭代的功能。個人習慣，可以參考。

• P0級功能：主要是實現業務流通打通，解決主要用戶痛點。MVP的原則就是可以人肉去做的事情，都先不做系統支持。

• P1級功能：主要解決支撐特殊業務的需求，如線上支付、線上簽署合同、財務對賬、核銷、開票等

• P2級功能：著重介入風險管控，前期實現業務流程時不會考慮運營，在有了前期業務數據的支撐下再來考慮運營介入，對于產品發展來說是利好。報表的功能也可以在此結算著手，畢竟有著數據基礎。

step4：原型及交互設計

本節中，筆者僅舉例TMS部分功能及司機端部分功能設計：

1. TMS中最重要的一個功能【create order】

物流行業中，開單的工作是至關重要的一個環節，開單的快慢，能夠簡介影響物流運輸的時效，那么物流系統中常見的創建訂單/運單功能設計又有什么特別需要注意的呢？

針對進行開單工作的開單員要求：開單速度要快、開單正確性。

平臺如何滿足開單員的要求：功能結構上，對缺乏用戶需求支撐且造成干擾的功能進行整合刪除；交互層面上，屏幕顯示盡量調整為一屏，減短用戶行為路徑；視覺上，優化圖標和文字，優化顏色，讓用戶不視覺疲勞。

下圖中分別為兩個創建訂單頁面設計對比：

（1）左圖長屏顯示，右圖一屏幕就可以顯示完成，減少開單員開單拖動滾動條才能看到更多內容的時間。

（2）可以作為配置項的條目，讓用戶多通過快捷鍵操作，減少用戶填寫時間。

（3）交互層面上，多級內容盡可能調整在一個頁面上，更好的體驗產品的人性化。

2. TMS中車輛監控功能

車輛監控在物流行業是作為長期規劃的重要功能，設計時實現用戶重要優先需求即可。

A公司面對市場用戶需求，要實現重點功能：

（1）需要做到貨物位置、軌跡實時查看及回放。（現實場景：司機結算完成運輸任務，報銷時會查看軌跡，才會給與報銷結算；司機排長隊等著工作人員看軌跡，再給錢。軌跡有問題還會壓錢。耽誤司機運輸任務及增加工作人員時間成本。）

（2）監控看板讓貨物運輸狀況一覽無余。（現實場景：司機拉著貨，在休息區休息娛樂了，時效控制差。）

（3）現場照片實時上傳，實現無紙化管理。（現實場景：A公司經常讓司機將裝卸、車況、路況及貨損貨差通過拍照并且立即發群留證，容易導致留證照片混亂，不知道是哪筆運單的問題，造成工作人員大量繁瑣統計工作）。

3. 司機端

司機端規劃的功能以注冊認證、接單、上傳回單、收錢重點。

舉例：司機注冊認證

注冊認證設計注意點：操作簡單、路徑短、認證審核快。用市面已有產品做一個對比，如下圖所示：

左圖為研究市場某產品司機注冊，優點：不會讓用戶二次提交資料；缺點：提交資料重點不明顯、注冊之后還是會有重新審核認證過程；且需要手動填寫的內容過多，容易引起用戶體驗不適。

右圖為A公司調研市面招募司機提交簡易資料而做的產品設計，設計目的：注冊提交簡易資料，用戶可進入系統看產品提供基礎功能；需要操作更多功能時必須提交認證，可以確保司機是真實用戶。

step5：需求文檔撰寫

3個月的時間，留給產品的并不多，從產品邏輯梳理到原型設計，再到給業務方、BOSS過。有一句打忽悠的話：“過產品方案除了20%的能力，還得靠80%的運氣。”

產品方案過了就是最重要的寫需求環節，也同時是可以進入UI、UE設計環節。

立場：后端、測試、前端、甚至運營；

目的：寫詳細的需求文檔，讓你所面對的立場用戶能夠快速進入啟動工作狀態；

那么你的需求要寫的多詳細？

1. 修訂記錄，每一次修改都要做好記錄，方便舉證。那么如何記錄，舉個例子：

2. 項目背景說明

BOSS告訴我，今天要做個小功能，為什么要做這樣的功能就必須讓BOSS講出來來龍去脈，如果是他覺得應該這么加個功能，你也要懷抱十萬個為什么的心態。當然，適當挑戰老板。

研發面對我們是一樣的道理，你的需求文檔需要告訴研發，這個項目的背景，產品設計時為什么出現這個模塊，為了解決什么？

3. 動態結構

模擬用戶在頁面上的操作路徑，讓開發測試人員能夠直觀了解頁面功能組成，直接上個示例圖：

4. 詳細需求文檔

詳細需求文檔，每個企業的產品文化導致需求文檔有不同的寫作方法，比如：就在原型旁邊注釋；用Word編寫；等，筆者舉個直接在原型上注釋的例圖：

登錄：用戶使用手機號+驗證碼方式

5. 需求完成及時安排需求評審，及時完善修正各部門同事對于需求評審時提出的問題。

6. 正式進入研發階段，產品經理（項目經理）要進行工期排期，不過A公司給的時間只有3個月。

筆者與各個部門負責人將工作原本長達3個月的工期，拆分成了3個月開發、測試3個小迭代，最后在統一上線，可以各部門人員飽滿工作時間，敏捷開發也是最高效的工作方式。

下圖舉例其中一個小迭代的安排：

7. 產品驗收

產品上線前的驗收，也是產品經理要做的重要工作之一。

驗收注意點：

（1）系統全流程是否通過，邏輯是否正確

（2）用戶體驗是否友好

（3）功能點是否設計完整

（4）UI

（5）交互功能是否正常

（6）各業務角色功能是否配合流程完整。來個圖例，驗收紀要：

小結：故事二對于產品經理的工作流程做了一個簡要梳理，這也是初次接觸產品經理崗位的小白可以參考的工作點。

故事三：王婆賣瓜自賣自夸之運營推廣

王婆不夸自己的瓜，買家就不知道瓜甜。

產品經理不需要做運營推廣的具體工作，但一定要有自己的一套產品運營思維，針對A公司的這一套物流業務系統，筆者是如何做的運營方案：根據用戶群，設計運營方案。

面向的用戶群體歸類僅為兩類：貨主、司機。

那么對于貨主群體如何設計運營方案？

司機群體如何設計運營方案？

小結：運營方案的制定簡單，但實時操作及后續會產生的問題多樣，筆者將在未來的更新中將本文中所涉及運營中建立渠道、積分體系以及為什么筆者的運營方案中沒有出現SEO/SEM等線上推廣方式，筆者將做詳細的獨立篇章介紹。

故事四：蜀道難，難于上青天之產品roadmap

川蜀地區山多路彎，要向前走，要向上去，要看更好的風景就要經過這些艱難。

每一個產品在推出的時候，一定是符合當前業務模式及滿足技術能力的。但是技術會不斷進步，用戶的需求也在不斷更新，品牌也會隨著市場而擴展。

產品的roadmap實際在項目規劃初期就會確定，筆者之所有放在最后描述，主要原因歸屬于產品的迭代路徑會隨著用戶需求，市場的趨勢而做調整。

舉例如何規劃roadmap：

首先：同BOSS、業務一同確認經過驗證的業務地圖，如下圖所示：

其次：根據業務地圖，確認實現支撐各個業務階段的功能地圖，如下圖所示：

小結：產品的迭代路徑，切記要根據企業的業務規劃來做具體規劃，面向B端的業務系統與面向C端的產品不同點，就在于B端業務系統多數由用戶更高的需求及市場的趨勢決定，而不僅僅是由用戶體驗所決定。

總結

產品經理從得到一個項目創意，再到這個創意落地會經歷幾個階段：

第一階段：分析并摘選符合該創意的用戶群。

第二階段：分析并驗證該項目是否可以賦能用戶，是否有利于企業自身的發展。

第三階段：分析所屬用戶群體的真實痛點（一個業務系統給用戶賦能的特點）、業務邏輯、束流系統的功能特點。

第四階段：產品設計。

第五階段：運營推廣。

第六階段：產品的迭代規劃及后續維護。

這幾個階段都是一個獨立的但又承上啟下密不可分的精彩充滿了創意、創造力、活力的故事。