中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

編輯導讀：作為一個B端產品，它的商業模式都是跟公司現有產品或業務有關聯性的。如果要從零開始設計一款B端產品，要注意什么呢？本文將梳理整個B端產品完整的設計過程，與你分享。

某天Boss招呼老文去他辦公室，坐下來，點上一根香煙之后便開始最近工作的近況的閑聊。相信很多看官都熟悉這個畫面，唯一不同的可能是你們只有故事沒有煙。

聊著聊著，Boss突然話鋒一轉，最近我有個這樣的想法，業務是這樣的：現在物流供應鏈相對還比較落后，咱們也很有機會，如果結合金融進行輔助，那不就可以……聽明白了么？你看看如何設計一下，下周我過來的時候給我一個具體的方案。

接下來，老文便會根據自己的理解重述一下Boss剛剛的想法，必要時會白板上寫寫畫畫。經過可能長達幾個小時的溝通后，Boss也覺得差不多了，便說方案盡快給出來哈，還抽根煙么？云云~~然后離開辦公室腦袋一片空白。

Boss的這個想法可能來自于深思熟慮，可能來自于圈內大佬的交流總結，可能來自于某篇文章。有時候我想：也有可能來自于昨晚的一個夢。但是不管來自哪個腦洞，咱們該如何開展接下來的工作呢？接下來老文將經驗進行分享。

根據這個話題背景，Boss是想設計一款物流+供應鏈金融系統，那咱們梳理一下，一個完整的B端產品設計要經過哪些步驟？先來看看總體設計架構：

一、設計前：分解Boss的想法

1. 業務現狀梳理

B端產品的某個想法和商業模式的探索一定是基于某一個行業，大部分的時候都是跟公司現有產品或業務有關聯性。因為沉淀一個行業的資源需要相對長的時間，所以不會突破行業突然來個創新型的idea，然后去予以實現，或者是公司轉型和非主營性業務。

我們首先要做的就是將Boss的想法結合行業現狀去梳理清晰，整理出來一個大致的流程和方案，然后匹配到公司現有的業務中，哪個事業線的負責人更有經驗和權威。通過請教他來了解現有行業中的操作方式及痛點等，如果有機會的話最好是自己親身去體驗需求場景中去。

如老文公司是做公路物流的，所以經常去到物流公司或集散中心的操作現場去和一線的用戶和操作員去聊天和了解業務現狀。

通過以上方式將會對現有的業務現狀有個初步的了解，并且能夠和實際的業務場景有所結合，形成草稿式的文檔，不限于采用什么形式。這個也是基于我們不是很了解行業的時候采取的方式，假設本來就深入了解業務，那就直接進行梳理即可。

目的就是為了將需求貼合實際的業務，分析出來業務問題并整理基礎的解決問題的思路，而不是僅憑自己的主觀經驗去理解，脫離了線下的實際業務，最終設計出來的產品將會是一座空中樓閣。

2. 競品分析&調研

B端產品設計時，不管是競品分析還是市場調研，是具備一定難度的事情，因為有時候根本就找不到競品，即便找到競品想要獲取測試賬號也是很難的一件事情，實際的用戶調研有可能是在飯桌上。

但是如果在行業中已經生存過一段時間，那么總會有一些熟悉的行業網站或者系統供應商，可以從這里去搜集到一些信息（咱們這里只討論外部客戶這種場景，不討論內部用戶和系統），然后慢慢擴展搜尋。

如何找到B端產品競品我的經驗如下：

• 基于第一點業務現狀梳理，明確競品分析的目的和核心需求，找到切入點和方向。不要把網撒太大了，這樣容易迷失在各類信息中。
• 找到對應事業線同事并與其溝通，他們有些是行業中的業務專家，他們可能曾經使用或聽過其他公司的同類產品。切記記錄好產品的公司及名稱，有什么特點之類的，盡可能多的了解產品的信息。假設公司找不到對應的事業線，那就拜托事業線的同事找行業中其他的客戶或朋友，然后去那里調研。
• 通過行業網站、公眾號、競爭對手等找到同類型的產品，瀏覽過程中某些文章或者論文也許還能夠啟發一些思路。
• 尋找行業中的軟件供應商，每個行業基本上都會有一些軟件外包公司或者標準化的軟件供應商。可以約他們進行商務溝通，也能夠得到一些很有用的信息。
• 最后，輸出競品分析報告，通過分析比較得出結論和對業務現狀梳理結果論證。

通過以上的方式基本上能夠完成競品分析的工作，關鍵點在于如何提煉對于分析有用的信息。至于如何找到同行系統的測試賬號、產品介紹等，那就需要各憑本事去套路了。

關于進行B端產品市場調研我的經驗如下：

• 市場調研主要還是以線下拜訪為主，親臨業務現場比聽到的任何高談闊論都有意義。
• 其次，如果公司有條件，能夠提供實操的環境，或者能夠在用戶崗位提供學習的機會，那這就是最好的市場調研方法。
• B端產品的調研對象分為兩大塊，第一個為管理層，第二個為員工層。因為有可能做決定的管理層并不一定是使用用戶，所以和員工層的溝通也是至關重要的一個環節。他們也是特別重要的干系人，一定程度上決定了產品能夠在客戶處走多遠。
• 提前準備好業務問題，最好是有一定的層次和針對性，分不同的對象去了解，不同的業務角色需求、目的、痛點不同。
• 最后，不管調研的效果如何，一定要輸出調研報告，將收集的業務問題做一個優先級，明確用戶痛點，為后續的產品方案設計和實施提供決策支持。

光是市場調研這個板塊都是可以獨立出來寫很多內容的，如調研的流程、方法、報告總結等。

咱們產品設計過程中也不能忘記這一環節，另外作為產品經理只有經歷過一線才會對業務有更深刻的理解，然后做出正確的決策。每多去一次一線，就能少拍一次腦袋，每少拍一次腦袋，就能多一分成功。

3. 藍圖設計：商業模式

B端產品商業模式的設計是非常復雜的設計，涉及到的方式也比較多。落實到產品層面，就是我們常說的BRD文檔。但是如果咱們是剛剛接觸這個行業或者產品崗位，商業模式的設計基本可以忽略，畢竟設計好產品本身的業務邏輯才是重點。

一般的情況，B端產品的商業模式的建立也不是我們來做決定，我們也相對比較少接觸，這里還需要根據產品運營的形式來決定盈利方式。

既然咱們上面做了競品分析，競品的盈利方式當然我們也是需要分析的。所以可以結合競品分析報告及公司的現有業務模式給出一定的建議，將產品后續的藍圖提前規劃，做到這個層面基本完成要求。

二、設計中：從不缺席的那個PPT

老文這部分的經驗大部分是從我們CTO那里學習到的，相當于他帶我入門，然后再從他如何設計產品的過程中自己去摸索沉淀，還有一部分來源于學習產品部的小伙伴們。所以現在部門慢慢形成了一個這樣的文化，從0開始設計產品時，產品經理必然會寫一篇類似上述思維導圖一樣的結構性PPT。

每次產品設計時，都會先寫一個思路相對整體的PPT，可以讓后面產品詳細設計的時候少走很多彎路。目前我們部門的表現形式為PPT，其實使用什么文檔類型并不重要，Word也可以，主要是要描述清楚下面的流程即可。

此PPT的意義：

1. 將需求方的想法和需求做一個全面的整理，并且可以用于與需求方進行溝通，使其意見達成一致。
2. 可以減少資源浪費，如果深思熟慮后發現此需求并不成立，就不必要進入產品的詳細設計階段，更不需要浪費研發資源。
3. 可以作為產品詳細設計階段的藍本，也可以作為工作安排的依據，可以以此分解工作任務給到產品團隊成員。
4. 可以作為項目組認知此產品的基礎文檔，對產品整體性達成共識，防止技術方案設計時，不符合產品設計要求。此PPT通過之后，架構師即可開始工作，這樣產品和技術則可以同步進行工作。
5. 可以作為項目管理的尚方寶劍，因為這個就是和Boss達成一致的相對詳細的文檔。如果后面Boss認為產品方向偏離，則可以對照此PPT。也可以作為和技術團隊的參照物。
6. 最后，這個PPT也是后面寫產品介紹PPT的原型，將會為后面的工作打下基礎，所以事實上它從不缺席。

我將此部分內容分為兩大部分，12個分點。第一部分為總體概要設計，包括01-07點；第二部分為模塊詳細設計，包含08-12點。

1. 產品背景

以前從0至1設計產品時，我也對這塊的內容存在疑惑，感覺產品背景的描述過于虛幻，不僅是現在PPT中需要描述，咱們的后續的需求文檔中也需要。有時候都不知道怎么下筆，又不能直接把Boss的那個夢進行描述。直到現在稍微有那么一些感覺了，下面給各位看官提供一下我的思路。

大致可以分為四點：

1. 背景描述：一個是將行業背景分析并進行描述，再一個將公司背景和業務進行描述。
2. 核心訴求：闡述需求方或用戶的核心訴求，如提高效率？解決某個業務問題？降低成本？
3. 項目評估：此處可以描述高層決定，所需資源，以及少許的風險描述。
4. 預期目標：時間目標、系統目標、業務目標等，如：3個月完成XX系統的研發并上線，系統能夠支持業務XX年。

2. 產品定位

產品定位的描述就涉及到產品設計的本身業務，定位的描述可多可少，多的描述會涉及到業務支持的范圍、預期目標的詳細描述、簡要的業務架構、產品角色業務支持等。少的描述集中于產品在公司產品中的定位以及邊界定義。

產品定位和產品背景的區別在于背景更多的還是行業背景、痛點描述，定位將是描述你設計此產品的整體性描述和概要總結，并且對產品功能邊界、系統or模塊邊界進行定義。

經驗總結，目前我們部門的做法是：

1. 首先，先會做一個產品定位圖，用來表述大致的業務以及和公司其他產品的連接。
2. 其次，將產品定位圖進行解釋，讓文檔閱讀者能夠清晰的認識產品定位，篇幅兩頁PPT基本搞定。

產品定位圖：

3. 角色說明

產品中的角色大致可以分為兩類，業務角色和系統操作角色。系統操作角色設計在系統的權限管理中，可以靈活的賦予角色不同的權限和功能。

業務角色本身就存在于實際的業務過程中，他們被賦予了不同的工作場景和使命，當然和系統操作角色一樣也有同時承擔多個角色的主體存在。

經驗總結，業務角色定義的用處：

• 角色的定義和描述是在重塑用戶畫像的過程，能夠使文檔閱讀者更清晰的認識業務過程中的操作，以及快速理解角色的定義和來源。
• 可以規范產品模塊的邊界，哪些角色需要在哪個系統or模塊中操作，并且可以檢驗產品業務流程的閉環性。
• 促進與業務部門進行分析時，達成對業務角色的理解一致，防止出現產品經理對某一塊業務的不熟悉導致理解偏差。
• 能夠給系統的技術架構提供參考，也可以為后臺人員提供業務理解的基礎，因為產品及技術中后臺的部門，很多對前臺的業務并不是很熟悉。

業務角色雖然一開始就存在于業務過程中，但是把其映射到產品中來的時候也是需要進行一定包裝，并且需要結合整體的業務流程進行不斷的完善和修正。

4. 核心業務流程

相信在前面分析鋪墊的基礎上，梳理起來核心業務流程將不會是一件特別讓人頭疼的事情了。我們有了角色說明之后，根據實際的業務流程將他們通過一定的業務操作串聯起來。這些業務操作一定是系統非常具有代表性的操作，并且角色相互之間是需要溝通和交流的（兩次握手）。

經驗總結，建議：

• 核心業務流程一定需要使用流程圖來進行描述，純文字性描述起來相對不會那么清晰，流程圖輔以部分文字說明是相對比較好的實現方式。
• 實現方式建議使用具有一定代表意義的圖標，包括序號、箭頭、顏色等進行區分，這樣整個圖不會顯得很死板，因為這里還沒有到詳細流程圖的設計。

業務流程圖：

5. 核心資金（支付）流程

這部分的內容，并不是所有的B端產品都是必須的，比如常見的OA系統、客服系統等并不具備這些功能，因為類似這樣的產品只是為了解決企業內部的某些效率問題。并且里面的角色并不參與業務交易。

但是，作為一款商業型的B端產品，大部分都會涉及到資金流程，但是不一定會涉及支付流程。這里咱們要區分開的是，資金流程可以理解為一個記賬的過程，比如財務模塊、應收應付管理等功能，這些功能不一定會觸發真實的資金支付流程。

支付流程又是另外一個獨立的流程和體系上的內容，支付流程的設計也關系到公司是否已經存在支付系統，還有產品支付渠道的選擇等，B端產品的支付和C端的支付差別相當大，因為涉及資金的限制也不同。比如老文的公司使用了很多銀企直連接口，這些渠道也將會影響產品后續的設計，所以一開始最好是有所準備。

經驗總結，建議：

• 如果涉及到資金相關的流程，先考慮資金流程和業務流程的匹配度，是否滿足業務要求，再去考慮支付流程的工作。
• 資金流程中需要考慮到各系統之間的結算、利潤等，如果產品涉及到公司多個業務系統，也要同財務部門和對應事業部進行前置溝通。
• 資金流程也需要考慮各角色之間的結算、利潤，平臺運營主體的利潤等。
• 盡早讓財務部的同事參與進來，或者提前進行溝通，防止出現設計的資金流程違背的了財務部門的要求。

6. 發票流程

發票流程的設計緊跟資金流程設計，整體原則就是誰收錢誰開票。所以，發票的內容基本上都是和資金流程同步出現的。

但是發票流程的設計并非如此簡單，特別是遇到復雜的業務流程的時候。還有關于發票模塊和流程的設計，往往容易被忽略，因為大多數情況發票都是一個線下的動作，實際上，對于一個商業型的B端產品，并且產品中擁有多個企業主體，又涉及到資金結算等業務，那必然會出現發票流程。

經驗總結，建議：

• 設計階段盡早讓財務部的同事參與進來，可以少走很多彎路，特別是很多對公司本身的財務規則不熟悉的小萌新。
• 盡早確定系統的運營公司主體，因為不同的公司主體營業范圍不一樣，可開的發票也不一樣。如果沒有對應的公司主體，則需要提前去準備，防止出現系統上線后無運營主體的情況。
• 發票流程的設計需要符合公司財務部的習慣和要求，這里具備一定的專業性，不能一味的只考慮產品交互層面的實現。

7. 系統應用架構：功能模塊

之前老文也說過，B端的產品經理如果具備技術背景將會是優勢之一，如果是有技術知識的話，這塊的內容寫起來將會更加得心應手。這個也叫做業務架構圖，也是產品功能模塊的雛形，將核心的功能模塊進行定位。這個和產品定位不同的是站的角度和層面不一樣。

業務架構更多的是考慮產品內部功能模塊之間的定義和關系，以及與公司其他系統的關聯關系和布局。剛剛開始可能會覺得用處不大，但是這里還是蘊含著一系列的設計思考，這也會受到公司本身的技術架構影響，比如我們常說的SaaS、中臺思想等。

經驗總結，建議：

• 如果經驗不夠，架構圖畫起來比較別扭，那就提前請教做的好的同事或者技術同事，不然換種方式實現。
• 提前和CTO或者架構師進行溝通，不同的實現方式，所需的資源不一樣，達到的效果也不一樣，比如小程序和APP。
• 好的系統應用架構應該得到技術團隊的認可，也可以使產品能夠達到預期的使用期限，所以不能為了實現而實現。
• 這一步我認為是非必要步驟，也可以在后續的功能模塊分解時做簡要描述，將兩者結合起來去實現。

最后：為什么文章沒結束？

原本在文章架構上使用一篇文章寫完，但是感覺篇幅過長，閱讀起來將會很累。所以采用了兩篇文章，喜歡的小伙伴，可以關注老文的下一篇文章《2B產品設計：2B產品經理做的那些2B事（二）》。

本文由 @老文 原創發布于人人都是產品經理，未經作者許可，禁止轉載。

題圖來自Unsplash，基于CC0協議。