在上一篇文章“如何定義B端產(chǎn)品的MVP（上）”里面，我們談到了定義MVP產(chǎn)品的前面三個步驟，確定產(chǎn)品定位，找到種子用戶，確定產(chǎn)品路線，今天我們再來聊聊后面的幾個步驟。

1.?確定用戶業(yè)務(wù)流程圖

在產(chǎn)品路線確定完成之后，基于產(chǎn)品定義的路線，我們要基于業(yè)務(wù)目的來確定用戶的業(yè)務(wù)流程圖。

還是拿人事模塊來進(jìn)行舉例，幾個關(guān)鍵的用戶業(yè)務(wù)流程圖就包含比如說：員工入職流程，員工合同管理，員工異動流程（調(diào)職），員工離職流程等等。

確定用戶使用流程圖的目的是為了保證產(chǎn)品能夠?qū)Ω鱾€角色的日常業(yè)務(wù)進(jìn)行支持，在梳理的時候盡量完整，不要遺漏，也是為了后面梳理每塊業(yè)務(wù)功能點清單以及定義優(yōu)先級做好準(zhǔn)備工作。這方面的文章也很多，筆者就不細(xì)說了。

2.?確定功能點清單

基于產(chǎn)品的用戶使用流程圖，確定每個功能的線上功能點清單，類似下圖所示：

在定義完成每個流程的功能點之后，要做一件事情，就是要確定哪些功能點事放在線上來實現(xiàn)，哪些功能點還是要維持線下的方式，這個也是很重要的一個步驟，可以參考一下如下的原則：

（1）線下處理極其靈活，沒有什么規(guī)則，也很難通過梳理將目前的業(yè)務(wù)邏輯規(guī)范化的流程或者功能建議線下處理。

要知道軟件的一個基本原則就是建立一套標(biāo)準(zhǔn)流程或者自動化的規(guī)則，如果線下處理極其靈活，很難將規(guī)則標(biāo)準(zhǔn)化，那么這樣的功能是不太適合做成標(biāo)準(zhǔn)產(chǎn)品功能的，留一點標(biāo)準(zhǔn)的通用口子給到客戶，讓客戶線下處理，將數(shù)據(jù)輸入線上就可以了。

舉一個例子，在薪資里面為什么有那么多稅前調(diào)整項，稅后調(diào)整項目，就是各種各樣的情況太多，無法標(biāo)準(zhǔn)化，就留了一些口子給用戶而已。

（2）線下處理比線上處理要方便很多。

每個業(yè)務(wù)流程如果你嚴(yán)格的去梳理功能點，發(fā)現(xiàn)會有各種各樣的情況需要進(jìn)行處理，這個時候非?？疾霣端產(chǎn)品經(jīng)理化繁為簡的能力，打一個大家都會碰到的公司里面請假的比方吧，會有很多人考慮設(shè)計如下的功能：

1. 如果員工申請了休假，老板還沒有批的時候，是否需要一個撤銷功能，讓員工可以撤銷可以提交已經(jīng)申請的單子??？
2. 如果老板長時間沒有審批，是否要設(shè)置一個幾天自動審批通過的功能，不同公司默認(rèn)審批通過，審批拒絕是否還要設(shè)置一個參數(shù)??？
3. 如果申請休假，老板拒絕了，是否可以支持在原來的單子上面直接修改之后直接提交啊？

說實話，現(xiàn)實中筆者特別怕碰到這種邏輯嚴(yán)謹(jǐn)，又沒有梳理能力的產(chǎn)品經(jīng)理，盲目增加功能點，增加的功能點會帶出很多其他的特殊情況，導(dǎo)致功能越來越復(fù)雜。實際在MVP階段，這些場景統(tǒng)統(tǒng)不需要支持，但是要保證的一點是這些場景發(fā)生的時候，業(yè)務(wù)不至于走不下去。

事實這種情況MVP階段只要保證支持最基本的業(yè)務(wù)流程，員工可以提交請假，老板可以審批通過或者拒絕，上次這三種情況前期就都可以支持：

對于場景a，用戶可以跟老板口頭或者微信說一下，讓他拒絕就解決了。

對于場景b，不好意思，老板這么久沒有批，現(xiàn)在通訊這么發(fā)達(dá)，微信跟老板說一聲。

對于場景c，老板拒絕后，重新提交一張請假單子，輸入日期和選擇假種有那么大的工作量嗎？

3.?確定功能點的優(yōu)先級

確定功能點的優(yōu)先級一般來說需要依據(jù)如下幾個維度：

（1）基于功能需求的強(qiáng)烈度

判斷功能需求的強(qiáng)烈度，用戶痛感強(qiáng)烈程度的指標(biāo)是很重要的維度，比如說員工入職流程是否要支持員工自助入職（員工輸入自己的基本信息），如果對于一個中小公司來說，一年也沒有幾個新員工入職，那么這種信息的輸入完全放在HR端進(jìn)行輸入就可可以了。員工自助入職功能根本不需要，或者很后期才考慮就好。

如果目標(biāo)客戶是針對特大客戶，每天新員工入職的量是很大的，如果這個是客戶一個提升效率的主要訴求。那么前期的優(yōu)先級就需要提高。切記所有的考量都要基于產(chǎn)品的定位以及業(yè)務(wù)場景，是任何判斷的一個基準(zhǔn)。

（2）基于功能使用的頻率

頻率也是功能優(yōu)先級一個重要的指標(biāo)維度，比如說組織架構(gòu)調(diào)整的調(diào)整，有些公司可能一年都做不了一次組織架構(gòu)的調(diào)整，那么組織架構(gòu)調(diào)整的功能就可以優(yōu)先級不要那么高。

筆者曾經(jīng)看到一些項目的設(shè)計，前期就考慮了很多非常極端低頻的事務(wù)處理。前期在極端情況處理的開發(fā)上面花費(fèi)了大量時間，最后產(chǎn)品開發(fā)周期極其長。另外在產(chǎn)品設(shè)計上面，極端case的處理也揉在了正常流程中，導(dǎo)致產(chǎn)品極其難用。實際上這些極端低頻的功能幾年都用不了一次，完全可以放在后期。

另外前面一些年刮起了B端一切功能移動化的風(fēng)潮，將很多低頻使用，或者大多時候是用戶坐在PC面前使用的功能移動化，實際上沒有人用，浪費(fèi)了很多人力物力，也因為復(fù)雜的功能讓管理系統(tǒng)的移動端疲憊不堪，體驗極差。在移動化如此盛行的今天，筆者想問您一句，您真的需要將功能移動化嗎？

功能點的取舍是考驗產(chǎn)品經(jīng)理水平的一個很重要的衡量標(biāo)準(zhǔn)，不同的產(chǎn)品定位，不同的公司資源，不同的團(tuán)隊能力，同樣的題目的最佳答案一定是不一樣的。

（3）避免過度設(shè)計

有些產(chǎn)品經(jīng)理考慮問題因為還是比較窄，也由于沒有技術(shù)背景，不太了解不同設(shè)計對應(yīng)的開發(fā)工作量，經(jīng)常容易過度設(shè)計，那個提出app皮膚要根據(jù)手機(jī)殼顏色進(jìn)行適配需求的產(chǎn)品人就是一個很典型的例子。

我也舉一個非常簡單的例子，在進(jìn)行員工或者客戶信息維護(hù)的時候，經(jīng)常有員工或者客戶的地址需要進(jìn)行維護(hù)的情況，有些人有一個地址，有些人二個，最多有些人三個地址，于是可能有些產(chǎn)品設(shè)計很自然就設(shè)計對地址進(jìn)行行級支持，支持無限添加擴(kuò)展。

如果最極端的情況是三個地址，你的產(chǎn)品定位又不是支持可以全世界大客戶，類似sap的定位，用列級支持最多三個地址就夠了，開發(fā)工作量小，對于用戶來說前端也挺易用。

整體來說，基于產(chǎn)品定位，業(yè)務(wù)場景，團(tuán)隊情況對于大小問題化繁為簡，設(shè)計最佳，最簡路徑是非常重要的。通過上下篇這些步驟，希望可以幫助大家定義出一個B端產(chǎn)品的MVP功能。也歡迎大家留言討論！

相關(guān)閱讀

如何定義B端產(chǎn)品的MVP（一）

作者：李東林（微信公眾號：SaaS產(chǎn)品說；微信號：jianguzhuxin），原ADP大中華區(qū)產(chǎn)品負(fù)責(zé)人，14年To B研發(fā)與產(chǎn)品設(shè)計，團(tuán)隊管理經(jīng)驗，主導(dǎo)過多款大型企業(yè)管理軟件的設(shè)計、研發(fā)、上線，也有過2年移動互聯(lián)網(wǎng)TO C的創(chuàng)業(yè)經(jīng)驗。

本文由@李東林 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)許可，禁止轉(zhuǎn)載。

題圖來自Unsplash， 基于CC0協(xié)議。