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

1.?確定用戶業務流程圖

在產品路線確定完成之后，基于產品定義的路線，我們要基于業務目的來確定用戶的業務流程圖。

還是拿人事模塊來進行舉例，幾個關鍵的用戶業務流程圖就包含比如說：員工入職流程，員工合同管理，員工異動流程（調職），員工離職流程等等。

確定用戶使用流程圖的目的是為了保證產品能夠對各個角色的日常業務進行支持，在梳理的時候盡量完整，不要遺漏，也是為了后面梳理每塊業務功能點清單以及定義優先級做好準備工作。這方面的文章也很多，筆者就不細說了。

2.?確定功能點清單

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

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

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

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

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

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

每個業務流程如果你嚴格的去梳理功能點，發現會有各種各樣的情況需要進行處理，這個時候非?？疾霣端產品經理化繁為簡的能力，打一個大家都會碰到的公司里面請假的比方吧，會有很多人考慮設計如下的功能：

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

說實話，現實中筆者特別怕碰到這種邏輯嚴謹，又沒有梳理能力的產品經理，盲目增加功能點，增加的功能點會帶出很多其他的特殊情況，導致功能越來越復雜。實際在MVP階段，這些場景統統不需要支持，但是要保證的一點是這些場景發生的時候，業務不至于走不下去。

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

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

對于場景b，不好意思，老板這么久沒有批，現在通訊這么發達，微信跟老板說一聲。

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

3.?確定功能點的優先級

確定功能點的優先級一般來說需要依據如下幾個維度：

（1）基于功能需求的強烈度

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

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

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

頻率也是功能優先級一個重要的指標維度，比如說組織架構調整的調整，有些公司可能一年都做不了一次組織架構的調整，那么組織架構調整的功能就可以優先級不要那么高。

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

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

功能點的取舍是考驗產品經理水平的一個很重要的衡量標準，不同的產品定位，不同的公司資源，不同的團隊能力，同樣的題目的最佳答案一定是不一樣的。

（3）避免過度設計

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

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

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

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

相關閱讀

如何定義B端產品的MVP（一）

作者：李東林（微信公眾號：SaaS產品說；微信號：jianguzhuxin），原ADP大中華區產品負責人，14年To B研發與產品設計，團隊管理經驗，主導過多款大型企業管理軟件的設計、研發、上線，也有過2年移動互聯網TO C的創業經驗。

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

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