B端產(chǎn)品從業(yè)務(wù)診斷到形成方案
B端產(chǎn)品從前期的業(yè)務(wù)診斷、業(yè)務(wù)分析,到后期的方案形成,這個過程中,大致會經(jīng)歷怎樣的環(huán)節(jié)或步驟?這篇文章里,作者便做了相對完整的梳理,不妨來看看,或許會對產(chǎn)品同學(xué)們有所幫助。
一、B端產(chǎn)品的市場分析與業(yè)務(wù)調(diào)研
1. 分析市場并細(xì)分客戶群體
任何商業(yè)行為的核心都可以用一句話描述,即:給誰用,提供什么價值,解決什么問題。
商業(yè)的起點,首先要分析市場,確定目標(biāo)客群,從而針對目標(biāo)客群的痛點設(shè)計產(chǎn)品解決方案。
前期的市場分析步驟以及目標(biāo)分析點如下:
注意:
在現(xiàn)實中,B端產(chǎn)品切入的方式不止這一種,有的企業(yè)甚至并沒有嚴(yán)格遵循以上步驟做市場分析,而僅僅是在某個行業(yè)深耕久了,對行業(yè)比較了解或者摸索到了該領(lǐng)域還存在潛力,進(jìn)而選擇了自己熟悉的賽道去做探索;或者機(jī)緣巧合工作過程中接到了一個大客戶訂單,通過和客戶的項目制合作,完成了對該業(yè)務(wù)領(lǐng)域的學(xué)習(xí)和認(rèn)知,進(jìn)而深耕于該領(lǐng)域。
2. 針對選定的目標(biāo)做市場調(diào)研
第一節(jié)已經(jīng)分析完如何選定目標(biāo)市場或目標(biāo)客戶,接下來我們從客戶的內(nèi)部視角,探討具體的業(yè)務(wù)問題調(diào)研和分析。
尤其是商業(yè)軟件產(chǎn)品,在啟動設(shè)計階段,不可能憑空基于對業(yè)務(wù)的假想完成設(shè)計,更不可能針對一個有代表性的標(biāo)桿客戶進(jìn)行充分調(diào)研,透徹理解業(yè)務(wù),并刻畫出MVP版本。
1)業(yè)務(wù)調(diào)研的五個環(huán)節(jié)
2)業(yè)務(wù)調(diào)研的三個階段(初期-中期-后期)
3)業(yè)務(wù)調(diào)研的目的
B端產(chǎn)品面向企業(yè)用戶,產(chǎn)品目標(biāo)是更好的支持業(yè)務(wù)運轉(zhuǎn)。所以調(diào)研目標(biāo)是分析業(yè)務(wù)現(xiàn)狀和業(yè)務(wù)問題,為方案設(shè)計提供支撐,最終解決企業(yè)的業(yè)務(wù)問題,提升運轉(zhuǎn)效率。
C端產(chǎn)品直接面向終端用戶,而且一般承載著公司的商業(yè)目的(可能是變現(xiàn),也可能是獲取更多流量等)。所以調(diào)研目標(biāo)是獲取真實有效的用戶體驗的用戶需求和體驗感受,以便后面結(jié)合用戶的需求,痛點設(shè)計解決方案最終實現(xiàn)商業(yè)訴求。
3. 業(yè)務(wù)分析的三層架構(gòu)
在企業(yè)開展新業(yè)務(wù)時,首先要結(jié)合自身的戰(zhàn)略地位、組織發(fā)展階段,思考業(yè)務(wù)目標(biāo)和當(dāng)前情況,從而推導(dǎo)出基本的管控模式,再進(jìn)一步設(shè)計組織結(jié)構(gòu)與績效激勵體系,基于這些頂層設(shè)計,最后才是業(yè)務(wù)開展的具體流程體系。
B端業(yè)務(wù)分析框架:
二、B端產(chǎn)品的整體方案設(shè)計
1. 通過精益畫布構(gòu)建商業(yè)模式
產(chǎn)品不是憑空想出來的,尤其是業(yè)務(wù)型B端產(chǎn)品,設(shè)計這類產(chǎn)品最怕拿個榔頭(產(chǎn)品)找釘子(客戶),這樣多半會失敗,而應(yīng)該是先找到釘子,然后去拿榔頭釘釘子。
精益畫布中給出了商業(yè)模式構(gòu)建的九個關(guān)鍵要素,這九個關(guān)鍵要素可以幫助我們把商業(yè)運作的關(guān)鍵問題都想清楚,如圖示:
2. 使用PMF(product/Market Fit)進(jìn)一步對初期市場進(jìn)行驗證
PMF將新產(chǎn)品市場評估為四個階段:
- 概念階段:提出了早期的產(chǎn)品創(chuàng)意想法和產(chǎn)品概念。
- 原型階段:將產(chǎn)品的外觀實現(xiàn)出來,可以讓潛在客戶試用并提出感受。
- MVP階段:定義產(chǎn)品的最小可行性版本并實現(xiàn)。
- PMF階段:將MVP版本投入市場,檢驗市場接受度(需要從留存率,頁面訪問深度,跳出率等多個指標(biāo)判斷產(chǎn)品是否契合了市場達(dá)成PMF)
盡管業(yè)務(wù)型B端軟件比較厚重,但在商業(yè)層面的運作上,一定要始終秉承“尊重市場,尊重客戶,找準(zhǔn)定位,快速迭代”的理念。
3. 確定核心業(yè)務(wù)流程
現(xiàn)在讓我們回到產(chǎn)品設(shè)計本身,我們要梳理核心業(yè)務(wù)流程,定義問題邊界,并確定產(chǎn)品定位。
從核心業(yè)務(wù)流程切入產(chǎn)品設(shè)計,是開展整個設(shè)計工作非常好的起點。核心業(yè)務(wù)流程代表業(yè)務(wù)的主干脈絡(luò),需要思考業(yè)務(wù)的各個參與方和涉及的系統(tǒng)。
只有定義清楚業(yè)務(wù)邊界,才能定義產(chǎn)品邊界。很多時候我們發(fā)現(xiàn)產(chǎn)品的定位模糊混亂,這是因為設(shè)計時對產(chǎn)品要解決的業(yè)務(wù)問題的邊界和場景定義得就不清晰。
在核心業(yè)務(wù)流程繪制過程中,只需要繪制關(guān)鍵場景和節(jié)點,不用陷入細(xì)節(jié)流程。
4. 明確產(chǎn)品定位
產(chǎn)品定位是產(chǎn)品設(shè)計的指導(dǎo)思想和靈魂,梳理了核心業(yè)務(wù)流程和業(yè)務(wù)場景后,我們對客戶的問題、痛點有了明確的范圍界定,接下來我們從宏觀和執(zhí)行兩個層面來探討產(chǎn)品定位。
1)宏觀層面的產(chǎn)品定位
宏觀層面來講,產(chǎn)品定位是指對于一個選定的目標(biāo)市場,企業(yè)如何設(shè)計產(chǎn)品來承載價值主張來解決目標(biāo)客戶的痛點和訴求。用一句話來概括就是:產(chǎn)品的目標(biāo)客戶是誰?解決了他的什么問題?為他提供了什么價值?這也是精益畫布中1、2、3點描述的要素。
針對企業(yè)自研自用系統(tǒng),也需要明確宏觀層面的產(chǎn)品定位,但自研系統(tǒng)不存在目標(biāo)客戶群體的概念,因為服務(wù)的目標(biāo)客戶就是自己公司的業(yè)務(wù)方。
2)執(zhí)行層面的產(chǎn)品定位
任何一套復(fù)雜的軟件產(chǎn)品,都不太可能只靠一套獨立系統(tǒng)來運作, 而會由若干子系統(tǒng)來協(xié)同運作,支撐業(yè)務(wù)。
在B端產(chǎn)品設(shè)計中,我們要逐步分解、細(xì)化產(chǎn)品設(shè)計,在確定了產(chǎn)品整體定位后,下一步我們要思考應(yīng)該設(shè)計幾套子系統(tǒng)來匹配不同的業(yè)務(wù)場景,支撐業(yè)務(wù)運作,這也是執(zhí)行層面的產(chǎn)品定位問題,我們要說清楚,產(chǎn)品由幾套子系統(tǒng)組成,每套子系統(tǒng)的目標(biāo)用戶是誰,解決他們的什么問題。
劃分子系統(tǒng)時,可以通過目標(biāo)用戶與場景進(jìn)行子系統(tǒng)的定義和拆分。拆分的目的是讓系統(tǒng)從業(yè)務(wù)層面上邊界更加清晰,易于理解和使用,這也會傳導(dǎo)到技術(shù)實現(xiàn)上,讓系統(tǒng)底層的設(shè)計邏輯更加嚴(yán)謹(jǐn)、完備,在高粒度層面做到松耦合、高內(nèi)聚。
另外,產(chǎn)品經(jīng)理也要認(rèn)識到,多套子系統(tǒng)的定義只是在應(yīng)用層面上的劃分,在技術(shù)實現(xiàn)上很可能是一套統(tǒng)一的底層加多套前端的表皮而已。
5. 梳理應(yīng)用架構(gòu)
所謂應(yīng)用架構(gòu),是公司所有軟件系統(tǒng)的整體結(jié)構(gòu)和布局,任何公司的應(yīng)用架構(gòu)都不是隨意設(shè)計的,都有復(fù)雜的設(shè)計思想蘊(yùn)含在其中。
1)自研軟件系統(tǒng)的應(yīng)用架構(gòu)
在設(shè)計一套新的系統(tǒng)時,要考慮如何和公司現(xiàn)有的系統(tǒng)架構(gòu)融合,不同系統(tǒng)的模塊之間如何銜接。這項工作復(fù)雜度較高,不僅需要有豐富的架構(gòu)經(jīng)驗,而且需要深刻理解業(yè)務(wù)特點和可能的演進(jìn)方向,還要熟悉本公司的系統(tǒng)架構(gòu),這樣才能快速的提煉出相關(guān)問題。
如果公司已經(jīng)發(fā)展了多年,軟件體系結(jié)構(gòu)已經(jīng)相對成熟,這就意味著在設(shè)計一套新的系統(tǒng)或產(chǎn)品時,完全可以復(fù)用現(xiàn)有的部分系統(tǒng)或模塊,從而快速實現(xiàn),提高系統(tǒng)建設(shè)效率,減少重復(fù)開發(fā),更重要的是可以保證整體系統(tǒng)架構(gòu)合理。
舉例,支持分銷系統(tǒng)的公司整體應(yīng)用架構(gòu)圖如下:
2)商業(yè)化軟件平臺的應(yīng)用架構(gòu)
首先,任何一個商業(yè)化軟件產(chǎn)品,在實施過程中都要考慮和甲方已有架構(gòu)的融合問題,如果產(chǎn)品經(jīng)理不懂應(yīng)用架構(gòu)的常識,在軟件的集成能力設(shè)計,模塊的通信設(shè)計上就會出問題。這不單純是技術(shù)問題,還是一個業(yè)務(wù)問題,甚至是商業(yè)問題。
其次,乙方廠商如果有多產(chǎn)品線協(xié)同,同樣需要考慮應(yīng)用架構(gòu)的體系設(shè)計問題。一方面,產(chǎn)品矩陣背后需要有一體化的架構(gòu)設(shè)計思考,另一方面,為提升公司研發(fā)效率需要避免重復(fù)造輪子等問題。
所以不論是甲方企業(yè)背后的應(yīng)用架構(gòu),還是乙方產(chǎn)品體系的應(yīng)用架構(gòu),沒有本質(zhì)的區(qū)別,因為軟件工程和管理應(yīng)用系統(tǒng)從底層到上層的設(shè)計思路都是相通的。
6. 定義場景與功能模塊
從場景到功能模塊,有三種經(jīng)典的模塊抽象思路,分別是基于業(yè)務(wù)領(lǐng)域抽象模塊,基于業(yè)務(wù)場景抽象模塊,基于業(yè)務(wù)對象抽象模塊。
1)基于業(yè)務(wù)領(lǐng)域抽象模塊
最常見的模塊劃分方式是基于業(yè)務(wù)領(lǐng)域的,業(yè)務(wù)領(lǐng)域是一個很寬泛的概念,可能包括業(yè)務(wù)部門、業(yè)務(wù)單元、業(yè)務(wù)主體等。業(yè)務(wù)領(lǐng)域作為模塊劃分依據(jù),讓模塊之間體現(xiàn)了更強(qiáng)的內(nèi)部聚合性及松耦合性。
如下圖所示展示了典型的系統(tǒng)功能模塊設(shè)計,體現(xiàn)了基于業(yè)務(wù)領(lǐng)域劃分模塊的特點:
基于業(yè)務(wù)場景抽象模塊和基于業(yè)務(wù)領(lǐng)域抽象模塊的區(qū)別之處是后者的內(nèi)聚屬性更強(qiáng),和技術(shù)架構(gòu)的模塊設(shè)計比較貼合;而前者更多從用戶體驗和業(yè)務(wù)邏輯出發(fā)來做模塊劃分,在場景菜單下可能會融合多個模塊的功能。
2)基于業(yè)務(wù)場景抽象模塊
有時候通過業(yè)務(wù)場景來定義菜單反而邏輯更清晰,更容易理解。例如,在某些流程屬性比較重的業(yè)務(wù)系統(tǒng)中,通過業(yè)務(wù)場景劃分模塊也能較好的做到功能模塊解耦合的抽象歸類。如下圖的菜單設(shè)計,一級菜單學(xué)員管理,課程管理,直播管理,助學(xué)管理等模塊,都是典型的教學(xué)場景。
3)基于業(yè)務(wù)對象抽象模塊
還有一種比較少見的模塊抽象思路,即基于業(yè)務(wù)對象抽象模塊,也就是將業(yè)務(wù)開展中的對象(人、事、物都有可能)定義成模塊。
如圖所示,在該人員管理系統(tǒng)中,用戶,角色,部門,崗位都是關(guān)鍵業(yè)務(wù)對象,在關(guān)鍵業(yè)務(wù)對象背后其實也影射了場景。
以上分享了三種劃分模塊的思路,在實踐中,往往會將幾種思路融合在一起,沒有絕對的原則和方法論。企業(yè)的運作管理體系已經(jīng)發(fā)展多年并非常成熟,對應(yīng)的管理軟件建設(shè)也十分成熟;任何形態(tài)的管理軟件系統(tǒng),B端產(chǎn)品,在模塊劃分和抽象設(shè)計中都要盡量參考同類業(yè)務(wù)軟件系統(tǒng)的設(shè)計思路,這是前人重要的總結(jié)沉淀,蘊(yùn)含著對業(yè)務(wù)的深刻理解和洞察,切勿自己發(fā)明創(chuàng)造,浪費時間。
7. 規(guī)劃演進(jìn)藍(lán)圖
通過繪制系統(tǒng)的功能模塊圖,我們可以明確業(yè)務(wù)和系統(tǒng)的規(guī)劃脈絡(luò)。將能想到的功能集合都列出來,這是一個做加法的過程。但是我們不可能一次實現(xiàn)全部功能,而要根據(jù)業(yè)務(wù)優(yōu)先級,拆分成幾期來完成,所以接下來需要做減法:確認(rèn)產(chǎn)品的功能規(guī)劃與實現(xiàn)節(jié)奏,就是常說的演進(jìn)藍(lán)圖(roadmap)。
對于一個新系統(tǒng),我們一般分幾期來實現(xiàn):
- 一期項目聚焦解決最基本的業(yè)務(wù)流程線上化問題及核心痛點,也就是支撐業(yè)務(wù)能閉環(huán)運行的最小功能集合,其中有一個原則可以參考:凡是可以手動處理和解決的問題,暫時都不做系統(tǒng)支撐。
- 二期項目聚焦于解決部分特殊業(yè)務(wù)剛需的訴求。
- 三期項目聚焦風(fēng)險控制,并強(qiáng)化運營功能。
隨著設(shè)計的深入,以及業(yè)務(wù)的開展、變化、功能模塊可能需要修正和調(diào)整,但只要業(yè)務(wù)的本質(zhì)模式?jīng)]有變化,功能模塊就不應(yīng)該出現(xiàn)結(jié)構(gòu)性的改動。功能模塊圖和演進(jìn)藍(lán)圖代表的是概要性方案,指明了整體的產(chǎn)品方向,是后續(xù)細(xì)化設(shè)計的指引和準(zhǔn)則。
8. 數(shù)字技術(shù)賦能業(yè)務(wù)
單獨從業(yè)務(wù)效能優(yōu)化的角度來講,數(shù)字技術(shù)賦能業(yè)務(wù)可以總結(jié)為五個階段,這五個階段循序漸進(jìn),逐步推演,對業(yè)務(wù)進(jìn)行全面優(yōu)化和賦能。
這五個階段分別是流程化,線上化,自動化,數(shù)據(jù)化,智能化,如下圖:
三、B端產(chǎn)品的細(xì)節(jié)方案設(shè)計
B端產(chǎn)品的細(xì)節(jié)方案設(shè)計,通過對整體方案中總結(jié)出的業(yè)務(wù)場景,逐個進(jìn)行深入分析,包括業(yè)務(wù)數(shù)據(jù)建模、頁面流轉(zhuǎn)設(shè)計、界面設(shè)計、權(quán)限設(shè)計等,再對關(guān)鍵場景的各個擊破中梳理出系統(tǒng)全貌的細(xì)節(jié)。這些工作流程和任務(wù)都是產(chǎn)品經(jīng)理的必修課,即便沒有經(jīng)歷從0到1的設(shè)計過程,也會在日常的迭代過程中經(jīng)常接觸。
1. 業(yè)務(wù)數(shù)據(jù)建模
業(yè)務(wù)數(shù)據(jù)建模也叫實體關(guān)系,指將業(yè)務(wù)的核心數(shù)據(jù)對象特征進(jìn)行提煉,歸納并設(shè)計對應(yīng)的底層數(shù)據(jù)模型的過程。
B端產(chǎn)品進(jìn)行細(xì)節(jié)設(shè)計的常見流程是,首先梳理業(yè)務(wù)流程,接下來提煉背后的數(shù)據(jù)模型,然后基于流程和數(shù)據(jù)模型確定頁面流轉(zhuǎn)圖,再著手進(jìn)行每個頁面的具體設(shè)計同時提前規(guī)劃好系統(tǒng)用戶角色,最后完成權(quán)限設(shè)計。
為什么數(shù)據(jù)建模這么重要呢?這是因為軟件系統(tǒng)的核心本質(zhì)上是對現(xiàn)實世界的對象和規(guī)則的抽象與管理。軟件系統(tǒng)設(shè)計的難點恰恰在于合理地總結(jié)客觀世界的對象和關(guān)系,并實現(xiàn)最基本的數(shù)據(jù)模型設(shè)計。只有總結(jié)并設(shè)計出正確的數(shù)據(jù)模型之后,才能思路清晰地完成功能模塊和交互操作的設(shè)計
實際上,業(yè)務(wù)數(shù)據(jù)建模是數(shù)據(jù)庫設(shè)計中最重要的部分,會影響數(shù)據(jù)庫表結(jié)構(gòu)的設(shè)計,體現(xiàn)了設(shè)計者對業(yè)務(wù)本質(zhì)的理解和認(rèn)知。很多產(chǎn)品經(jīng)理常常忽略業(yè)務(wù)數(shù)據(jù)建模只關(guān)注功能界面設(shè)計,最終陷人混亂的邏輯中。一定要在設(shè)計細(xì)節(jié)方案初期就進(jìn)行業(yè)務(wù)數(shù)據(jù)建模。
針對數(shù)據(jù)建模可總結(jié)為三個步驟:找到實體、梳理關(guān)系、確定關(guān)鍵屬性,如下圖所示:
參考:不同實體關(guān)系實例圖
2. 流程和角色
接下來,我們開始設(shè)計分銷客戶管理場景下業(yè)務(wù)的流程和角色。流程合理、角色清晰是系統(tǒng)正確設(shè)計的前提和保障,流程確定后,再繪制頁面流轉(zhuǎn)圖,最終完成頁面細(xì)節(jié)設(shè)計。
通過跨職能分系統(tǒng)流程圖,可以清晰的看出誰(操作角色)在哪兒(哪個系統(tǒng))做什么(完成什么工作)。
角色在業(yè)務(wù)開展初期已經(jīng)存在,但是在系統(tǒng)設(shè)計過程中,需要結(jié)合業(yè)務(wù)流程進(jìn)一步梳理,并修正完善,以保證各角色的工作內(nèi)容是明確并固定的,各角色之間盡量避免職責(zé)交叉,這樣才能保證團(tuán)隊成員分工明確,共同協(xié)作,達(dá)成業(yè)務(wù)目標(biāo)。
主業(yè)務(wù)流程圖示例圖如下:
3. 繪制頁面流轉(zhuǎn)圖
對于系統(tǒng)設(shè)計來講,業(yè)務(wù)流程圖依然屬于比較粗粒度的概要性設(shè)計,如何將它與軟件產(chǎn)品的頁面設(shè)計對應(yīng)起來,繪制頁面流轉(zhuǎn)圖是一個很好的銜接方式。
頁面流轉(zhuǎn)圖描述的是,用戶完成某項工作需要訪問的頁面及頁面跳轉(zhuǎn)順序。繪制頁面流轉(zhuǎn)圍可以幫助設(shè)計人員審視、思考系統(tǒng)中的頁面設(shè)計方案,包括系統(tǒng)中總共需要哪些頁面,哪些頁面可以重復(fù)使用,哪些頁面需要定制化開發(fā)。
一般來講、我們繪制頁面流轉(zhuǎn)圖時,都是針對某個單一角色繪制某個特定場景下的頁面訪問和跳轉(zhuǎn)邏輯,從用戶的視角來梳理一遍所有相關(guān)頁面,每到一個新頁面時都要思考:需要新做一個頁面,還是可以復(fù)用原有頁面? 最終整理出系統(tǒng)涉及的所有頁面的初稿。
頁面流轉(zhuǎn)實例圖如下:
4. 提煉匯總頁面功能清單
不同的場景有可能會涉及相同的頁面,因此非常有必要統(tǒng)一整理不同場景涉及的所有頁面。有時,在頁面清單的梳理中就可以將關(guān)鍵功能點也整理出來。
頁面功能清單示例圖:
5. 界面設(shè)計
我們已經(jīng)完成了功能模塊設(shè)計、演進(jìn)藍(lán)圖設(shè)計、業(yè)務(wù)數(shù)據(jù)建模、業(yè)務(wù)流程梳理、頁面流轉(zhuǎn)梳理,功能清單等一系列環(huán)節(jié),已經(jīng)細(xì)化到每個操作需要訪問哪個頁面、總共有哪些頁面、現(xiàn)在需要為每個頁面設(shè)計具體的交互功能以及具體呈現(xiàn),即進(jìn)行界面設(shè)計。
雖然在整個界面設(shè)計之前的流程很長,但在此梳理期間,我們對整個業(yè)務(wù)形態(tài)已經(jīng)了然于心,對整個項目和產(chǎn)品的掌控力越來越強(qiáng)。此時再去做界面設(shè)計,已經(jīng)是水到渠成之事。
界面設(shè)計流程:
注:
本篇文章只挑選了部分業(yè)務(wù)場景作為例子進(jìn)行講解,并沒有覆蓋整個系統(tǒng)所有的細(xì)節(jié)功能設(shè)計。在實踐中,我們在細(xì)節(jié)方案設(shè)計階段,要挑選優(yōu)先級和重要程度比較高的業(yè)務(wù)場景,進(jìn)行進(jìn)一步的業(yè)務(wù)調(diào)研,梳理每個場景背后的業(yè)務(wù)流程,完成功能設(shè)計,最終匯集得到完整的產(chǎn)品方案。
本文由 @梅維斯白 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理,未經(jīng)許可,禁止轉(zhuǎn)載
題圖來自 Unsplash,基于 CC0 協(xié)議
該文觀點僅代表作者本人,人人都是產(chǎn)品經(jīng)理平臺僅提供信息存儲空間服務(wù)。
目前看到側(cè)重于業(yè)務(wù)調(diào)研這個階段較詳細(xì)的文章,具備實操思路對我現(xiàn)在開展新業(yè)務(wù)打開了思路,感謝分享。另外,想了解下項目立項計劃書有模板可以分享嗎?
產(chǎn)品經(jīng)理做到這種程度,需求分析師做什么呢?僅僅是需求規(guī)格化嗎?
現(xiàn)在對產(chǎn)品要求是比較高的就是包括了需求規(guī)劃師的工作的