起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識B端產品的設計理念：如何落地一個需求？
和C端的產品經理一樣，B端產品經理工作的核心在于處理需求。但是如果照搬C端的方法論去處理B端需求，可能會有一些水土不服。這里我想嘗試總結一下我的個人方法論，建議能帶入著去好好讀一下，我相信對于做B端的你，或多或少有點幫助。
為什么B端的需求這么難做？
（1）產品架構復雜，功能龐大
往往B端系統數據結構比較復雜，而事故嚴重度又比較高，對產品經理考慮的嚴謹性要求比較高
（2）用戶思維和客戶思維的轉化更難
往往產品經理剛入門的時候，會去在意用戶的體驗性，考慮交互、樣式和用戶心理；但是到了B端，價值 》流程 》體驗，如果過分考慮體驗，那么就本末倒置了。B端的業務，產品經理很難站在用戶的立場思考問題，因為你很可能不是這個場景下的使用者。
（3）難以深入理解業務和市場
如果B端的產品經理不能深入理解業務和市場，在你聊需求的時候，你可能跟客戶都是牛頭不對馬嘴。B端產品經理對自己的要求，永遠是要比客戶更加懂業務！
（4）客戶角色多，需求描述不清
客戶角色多元，需求提出方可能并不是系統的使用者。管理者提出的需求可能會干擾需求的優先級決策；很多B端產品經理無法區分關鍵角色，從而對需求的本質判斷不正確
是不是所有的需求都值得做？
其實今天想討論的并不是需求值不值得做的問題，這個問題大到足夠再寫一篇《B端產品系統如何規劃》。
但是并不是所有提出的產品需求都需要去做，或者說需要馬上去做的。舉個產品社區經常討論的問題：拼多多是否應該去做購物車？
討論價值的時候，我們需要不斷的反問幾個問題。
暫時把它稱為提問法，我覺得產品經理在討論需求價值的時候，一定要有問到底的精神，等一層一層揭開后，答案就很明顯了。
拼多多可以不做購物車，因為購物車的價值在于給予用戶思考周期和囤貨的選擇，而拼多多的商業模式是以商品聚人，打造拼團的緊迫模式，用戶的思考周期越短越好。就算不做購物車，拼團的主流程仍然正常進行，所以商業模式決定拼多多目前可以不做購物車。
確定要做一個需求之后，我要做什么？
我拿一個小需求舉個例子。曾經聽過團隊中的新人產品經理與客戶溝通需求，需求的大概是做一個停車場的訪客車輛管理系統，我們的產品經理“便秘”式地跟客戶了解需求，想到一個問一個，雙方溝通非常的累。
訪客車進場算臨時車嗎？
算吧。
那訪客車輛入場免費嗎？
免費啊
那就存在漏洞可以一直添加免費車了啊
也對，那免費3個小時吧。
……
類似這樣的對話，一直在上演著。
B端產品設計步驟
（1）明確使用場景
遇到上述場景的時候，其實是沒去思考場景。
就訪客車的需求，我們先理一下，什么時候會用到訪客車輛管理功能。
- 小區，不允許臨時車進入，業主和物業有臨時拜訪的車輛的需要；
- 大型企業園區，只有預約過拜訪/面試的車輛能進入。
（2）確定核心價值
核心價值：做一件事的根本需求，核心目的。
我們之所以先去不斷推演功能的使用場景，是希望能從使用場景中得到功能的核心需求。
比如我們發現上述場景中，訪客車輛管理最重要的目的是減少/取代停車場保安登記車輛信息的需求。想的再全面點，就是車輛信息的登記管理、進出記錄統計、異常處理（車輛停放問題，緊急需要聯系訪客車主）。
而不是訪談中關心的免費、收費功能。
（3）參與角色、端、子業務
我們在上一篇文章中已經聊過角色、端和子業務了，現在我們看看怎么把他們帶入我們的產品設計。
參與角色：訪客管理可能涉及到的角色有：業主（拜訪對象）、物業（設置訪客權限的人）、訪客（有訪客需求的人）、保安/收費員（登記核實的人）。
產品設計到的端：按照不同角色，對應到系統不同的端。物業需要在管理后臺設置權限（PC），業主和訪客可以在用戶端（H5或小程序）、保安/收費員智慧收費終端（移動端或PC）。
涉及到的子業務 ：
（4）流程與異常
已經明確了功能設計的角色、端和子業務，在畫圖之前還有一部必不可少的工作：理流程。
之所以要強調必不可少的原因是，我發現越來越多的產品經理不愿意或者不會這一步了，其實與C端不同的是，B端太重業務，業務的復雜度決定我們是繞不開流程圖的。
舉一個訪客自助登記的流程作為例子：
流程圖要點：
- 一個功能可能有多個子業務，盡量把子業務拆開畫多個流程圖；比如訪客系統中，可以拆成業主主動邀請、訪客協助登記、訪客車輛入場等子流程圖；
- 流程圖先從簡單的主流程考慮，不要一開始畫流程就考慮全景和細節，容易迷失；
- 主流程確定后，盡可能得考慮分支異常；對流程圖來說最重要的就是異常。
（5）信息結構圖
看產品群里很多剛入群的新手總是提問信息結構圖是什么，大家還是簡單一點理解，就是按頁面為單位，把頁面上的元素都列出來。
我覺得產品結構圖是必要的，2個原因：
- 考慮的更加充分；
- 在這一步區分元素的優先級。
（6）demo設計
完成以上之后，這份產品設計其實已經完成90%的工作量了，接下去就剩下畫圖了。
有很多剛入行的朋友，一直在我們產品交流群里問交互如何如何做？? 我覺得畫圖，本質目的是什么？是把我們的想法用圖形化的語言描述出來，讓我們的聽眾（開發組、客戶等）能簡單直接的明白。
所以用什么樣的工具（axure、sketch、墨刀）不重要，多細致的交互不那么重要，甚至美不美化也可以不重要。
原型圖的設計，從我理解來說，下面這些才是要點：
特別是最后一點，我覺得別浪費我們平時的工作財富，抽一些時間，整理屬于產品“組件庫”。
自己的，總是最好用的。
（7）需求文檔
需求文檔（此處省略一萬字）。
總結
這只是很簡單的總結，落地需求只是B端產品工作里面的一項。是需要很長的時間去積累和沉淀的。
這是這個系列的第二篇文章，其實B端產品不像C一樣上線后就關注各種數據，B端產品上線前后還是在圍繞著“業務”走，具體還要注意哪些，下一章我們再詳細聊聊。
本文由 @柒哥和歐醬 原創發布于人人都是產品經理。未經許可，禁止轉載
題圖來自Unsplash，基于CC0協議
言簡意賅，清晰透徹，圈粉了
受益匪淺！感謝前輩！
清晰透徹
新手2b產品表示受益匪淺～感謝大佬 ??
有價值