起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識如何規劃一個從0到1的產品PRD，做出一個讓主邏輯跑通的MVP？
本文作者分享一份比較完整的PRD，來自他曾主導規劃的一個項目，這是一款搭載在微信服務號上的生活服務類應用，針對家庭生活廢品回收的試探性項目。enjoy~
近些年，移動互聯開始流行風口文化，許多創業者們都聞風而動，奮力爭當風口上的豬，風口就如潮水浪花般一波又一波，把弄潮兒高高捧起又重重的摔落，放眼望去大批大批的被拍死在沙灘上，真正能駕馭浪尖的高手屈指可數。
能看清時局，審時度勢，做到進退自如也是創業者需要修習的一門功課，作為一個產品經理能夠清醒幫助創業老板在眾多項目選擇中大膽試錯、小步快跑也是必修的功課，《精益創業》MVP，亦或是敏捷開發對產品經理來說尤為重要，憋著發大招又或者邏輯跑不通都是要規避的。
凱哥曾參與數個項目，也主導規劃了一些從0到1的項目，這里也分享一個曾自己主導規劃的項目，這是一款搭載在微信服務號上的生活服務類應用，針對家庭生活廢品回收的試探性項目，當時就是秉著MVP的思維落地運轉起來。
最好的學習就是輸出，所以我把自己數年前寫的從一份比較完整的PRD文檔干貨分享出來（有些許調整優化和刪減，敏感信息已做處理），如何做出一個讓邏輯跑通的MVP，適合產品新人學習借鑒，快速從某片樹葉跳出來看到整個樹枝，并朝著看清整顆大樹乃至整片森林方向發展，也希望借此能得到更多大牛指點。
為了方便瀏覽，先放一張本文的結構圖（如果圖片不清楚可以右鍵在新窗口打開放大查看）：
1. 產品簡介
1.1 項目背景
該項目是一款基于家庭（商鋪）廢品交易的搭建在微信端的CtoB搶單平臺，當下城市和互聯網快速發展的時代，然而城市（社區）廢品回收依然處在一個非常落后的環境，存在時間、信息不對稱，服務落后等問題，根據調研的統計信息研判，快速開發一個最小可行性項目，以便快速投入市場進行驗證。…………
1.2 需求場景
1.3 功能列表
根據市場調研采集的功能含有：
- C：綁定手機、下單功能：定位、語音、分類、文字、照相圖片、選擇商家、查看商家地圖、廢品名稱錄入、廢品重量錄入、廢品價格列表、廢品計價功能、積分兌換功能、預約時間功能、快速下單；查看訂單、取消訂單、實名信息、個人資料修改、賬戶密碼注冊登陸、刪除訂單、撤銷訂單、積分商城功能、客服反饋功能。
- B：綁定手機、注冊審核、個人資料查看與修改、地理位置上報、訂單實時推送、搶單功能、訂單自動匹配功能、查看訂單（列表）、快速撥打電話、修改訂單信息功能：分類信息、價格、重量、積分、取消訂單、支付功能、客服反饋功能。
- S：角色權限功能（級別、增刪改查）、C端注冊用戶信息查看和修改、B端商戶信息列表與審核、數據看板（B端申請量／審核通過率／活躍信息：搶單量／完單率／每單成交價格／日、月、季度、年交易額／類別占比，C端PV／UV／注冊量／天、月、季度、年下單量／成交價格曲線／類別占比）。
最終v0.1.0版本功能列表：
2. 版本信息
3. 產品邏輯
3.1 整體業務邏輯
3.2 資金流圖示
3.3 E-R實體關系圖
3.4 第三方注冊登陸流程（微信）
3.5 頁面流程邏輯
3.6 頁面信息結構
（1） C端用戶頁面信息結構
（2）B端商戶頁面信息結構
（3）S端（后臺）頁面信息結構
4. 產品設計、功能詳述
由于篇幅較多，各位可以先對照Axure上的頁面結構來查看以下內容：
4.1 全局說明
需要等待服務器返回信息的時間，以及流程正常進行中的提示都采用如下交互，245ms自動消失：
如果在一級頁面遇到流程錯誤，需要重新操作，需要彈窗提示，PC端也會用到對話框下方紅字提示錯誤信息：
4.2?功能說明
（1）通用-登陸（01手機驗證）
（2）通用-反饋（02建議反饋頁面）
（3）C端用戶下單功能詳述
下單界面：（03C端下單頁面）
訂單詳情頁：（04 C端訂單詳情）
訂單列表頁：（05 C端訂單列表）
（3） B端頁面功能描述
審核頁面（06 B端實名審核）
地理位置上報（07地理位置上報）
搶單頁面（08搶單頁面和訂單詳情頁面）
訂單列表頁（09訂單列表頁）
（4）S端（后臺）頁面功能描述
登陸以及權限（10登陸）
角色管理（11角色管理）
用戶管理（12用戶管理）
審核管理（13商戶審核）
訂單管理（14訂單管理）
反饋管理（15反饋處理）
數據看版（16數據看版）
設置-修改密碼（17設置）
結語
整個項目從立項到上線大概花了一個來月，產品經理期間需要跟不同部門進行不斷的溝通，需要做出整體項目計劃表、本項目計劃表以及個人工作計劃表來把控項目的進度和質量，另外還與運營和市場部門一同策劃和參與了推廣運行活動，通過實際在社區設點運作，收集用戶的真實使用情況。
最近凱哥學習了谷歌的設計沖刺的方法，講述如何5天對一個項目進行快速驗證，不過要實施起來還是比較考驗企業文化環境的。歡迎各位朋友與我多多交流心得和經驗。
作者：毛凱祺（微信號公眾號：凱哥開小灶），2年自主創業+4年互聯網產品設計經驗，有近10個產品項目管理經驗
本文由 @毛凱祺 原創發布于人人都是產品經理。未經許可，禁止轉載。
題圖來自 Pexels，基于 CC0 協議
有沒有源文件，發一個.15160969243@163.com
非常適合新人學習
產品從0到1確實不容易，但對我這樣的入門小白（技術出身轉型做產品）來說，上面的流程的的確是個不錯的學習資源，只是這個產品的思維要如何去修煉，一直很苦惱，不知道凱哥有沒好的指引，謝謝。
Axure有些字太小看不清，凱哥能分享一下源文檔么？
非常感謝凱哥?。?！如果有時間的話可以在寫一個關于MRD或者是BRD、需求分析這類的文章嘛 ，愿意付費閱讀??！對于新入門的產品真的有很大的幫助?。?/p>
大大你好，請問產品中的需求場景是想象出來的嗎？是不是所有的PRD都需要這個部分？
有做市場調查，當時做了線下問卷調查、社區居民走訪、回收人員行為跟蹤和回收站定點統計等。這個部分確切地說應該是屬于MRD部分，PRD不是必要構成。
謝謝大大解答~ ??
個人理解您圖中E-R實體關系圖畫法不能完整的表達出整個系統的實體之間的關系，建議采用業務實體關系圖，可以用UML類圖來展現，主要強調實體之間的關系。至于實體的屬性可以單獨列出業務實體屬性來表達。
感謝哦仔細閱讀文章??，那兒是沒寫對，UML類圖確實會更好。很多加我好友的都是仔細閱讀過文章，在頁面跳轉、異常描述、功能排序、項目排期等方面一起探討并提出許多寶貴的建議。
ER圖，C端用戶和訂單的關系畫反了。圖中意思是多個C端用戶發布一個訂單，應該是一個C端用戶發布多個訂單才對
受教了，打算照你的流程自己做個完整的（以前都糊里糊涂一個產品就做完了）
我的天，小白看前面還好，中后階段看不懂！不過太牛鼻了！這就是產品經理的實力嘛？大佬，厲害了?。。?！
到此一游?！獊碜砸粋€one-month-old的產品
全面，不錯。對這個項目有沒有做過商業BRD文檔
我（1歲產品）的經驗是，寫個文檔都要花上一周了，畫個原型也得花上一周，時間都過半個月了 ??
我也是這樣的遭遇，感覺這里的交流不錯，只是很多時候，他們級別太高，輸出的內容都不太能理解。共勉。
真的不錯，但是對于一個初來乍到的產品經理來說有點復雜，還沒有搞清楚一個PRD最精簡的需要寫點什么，反正漲見識了
超級贊?。。?！
真正的全流程設計啊，小白受教了，謝謝前輩?。?！