本文中，筆者將結(jié)合自己參與產(chǎn)品重構(gòu)以及做SaaS產(chǎn)品的實踐，與大家分享一些關(guān)于產(chǎn)品功能設(shè)計的思考，希望對你有所啟發(fā)。

在上篇文章《關(guān)于「產(chǎn)品架構(gòu)設(shè)計」，我的實踐思考》中，講述了當時我們是如何做的架構(gòu)設(shè)計。

但在實際工作中，我們更多的還是做功能設(shè)計。

如果說架構(gòu)是骨，那么功能就是其中一塊塊的肌肉，而字段屬于連接整體的經(jīng)絡(luò)，最后這個系統(tǒng)會像人一樣運作起來。

在產(chǎn)品基礎(chǔ)完善期（即生命周期的萌芽期）， SaaS 產(chǎn)品為了滿足核心場景的需求，會不斷的增加功能，滿足對方的業(yè)務(wù)訴求。

如何高效完成 SaaS 產(chǎn)品的功能設(shè)計，這是我作為產(chǎn)品新人的主要工作，因此需要不斷的積累經(jīng)驗，提高產(chǎn)品方案的質(zhì)量。

接下來，我會與你分享關(guān)于 SaaS 產(chǎn)品功能設(shè)計的一些思路，希望對你有用。

01 這個問題，需要通過功能來解決嗎？

我剛?cè)胄袝r，當面對一個業(yè)務(wù)問題的時候，首先想到的是我該用一個怎樣的功能來解決它，流程是什么樣的，以及原型該怎么畫。

而實際上我提出的解決方案不僅解決不了本質(zhì)問題，同時因為方案被無數(shù)次打回來，導(dǎo)致對自信心的打擊很大，甚至那時候覺得自己不適合做產(chǎn)品。

那么，問題到底出在哪了？

經(jīng)過這段的時間的沉淀，我發(fā)現(xiàn)之前自己「解決問題」的思路不對。

在分析問題時，應(yīng)該「先定義，再發(fā)散，后收斂」。

而不是重復(fù)做「收斂」的動作，那樣只會跟無頭蒼蠅一樣亂撞。

因此我總結(jié)了一下，當面對一個問題時，應(yīng)該先明確以下這幾個點。

1. 確定問題與現(xiàn)狀

最常見的方式就是提問，我們需要通過合理和高效的提問，圍繞著問題去收集相關(guān)信息。

作為產(chǎn)品經(jīng)理要時刻謹記一句話，對方說的往往只是解決方案，而非問題和現(xiàn)狀。

意識到這一點，通常我會問這么幾個問題搞清現(xiàn)狀。

（1）你們遇到了什么困難？

要知道，當你用「困難」作為提問關(guān)鍵詞時，對方的表達就不再是「我要怎么樣」，而是會說「現(xiàn)在是怎樣」。

因此以這個問題作為開頭，對方會下意識回顧事情發(fā)生的始末，回答過程中也會連帶出很多相關(guān)信息。

產(chǎn)品經(jīng)理需要做的，就是基于對業(yè)務(wù)的理解，對流程、角色、利益關(guān)系等關(guān)鍵信息保持敏感，完成信息的初步采集。

（2）在系統(tǒng)上如何操作？

我們的目的，肯定是希望產(chǎn)品能夠為對方提供完善的服務(wù)。

所以通過「問」和「看」對方在系統(tǒng)上的操作，不僅能確定問題在系統(tǒng)層面的不足，還能發(fā)現(xiàn)其他的一些操作問題。

（3）目前是如何解決的？

最常見的情況，就是系統(tǒng)還沒有做相關(guān)的解決方案，也就是這部分業(yè)務(wù)問題在系統(tǒng)上是缺失的。

那么我們就需要做相關(guān)的業(yè)務(wù)調(diào)研，從功能的層面去解決這個問題。

2. 最簡解決方案

我們都說做產(chǎn)品要做 MVP（最小可行性），其實做功能也是一樣。

我們要以最簡單的方式來解決對方的問題，方便日后的拓展，或是重做。

這里要切記「最簡」不代表「缺失」，業(yè)務(wù)閉環(huán)是做 SaaS 產(chǎn)品基本邏輯。

（1）已有功能的優(yōu)化

有的時候不是我們沒有這個功能，而是這個功能對方不知道，或者是說用不起來。

作為產(chǎn)品經(jīng)理，需要對當前系統(tǒng)已有功能非常的了解。

那么面對這種情況，可以選擇先做系統(tǒng)層面的講解，然后再去考慮如何優(yōu)化。

（2）視覺或交互上的調(diào)整

這里的核心理念，還是用最小成本去解決對方的問題。

比如組織架構(gòu)的樹狀展示方式，單擊是選中，雙擊是折疊 / 收起操作，這就能解決他們查看對應(yīng)層級人員的視覺干擾問題。

（3）利用通用功能（增刪改查）來解決

這些功能既通用，認知成本又低，作為基礎(chǔ)的解決方案正合適。

比如客戶存在任務(wù)執(zhí)行一半，要求不必再做的問題，我們需要先考慮「刪除」這個功能能否解決問題，而不是上來就做一個「任務(wù)停用」的功能。

如果上面這些問題你都搞清楚、弄明白了，那么接下來就會進入到功能設(shè)計的階段。

02 設(shè)計功能，滿足客戶的個性化需求

對于 SaaS 產(chǎn)品來說，客戶的需求存在多樣化，因此在設(shè)計功能時一定會考慮「可配置」。

這么做的目的，一是希望前端頁面簡潔高效、內(nèi)容清晰，且能夠滿足不同客戶的業(yè)務(wù)需求。二是對于后端的功能配置，能夠做到歸類清晰、不雜亂。

那么我們該如何去做呢？

首先我們需要判斷，業(yè)務(wù)流程與現(xiàn)有方案差別的大小。

如果差別大，我們需要從系統(tǒng)層面來配置，比如線下教育行業(yè)的上課流程存在兩種。

那么對于少數(shù)企業(yè)的情況，可以考慮在面對這些用戶時，將系統(tǒng)邏輯后臺寫死。

但如果業(yè)務(wù)流程與現(xiàn)有方案差別小，那僅從功能層面進行配置即可，這種就很常見了。

然后就進入到具體的功能設(shè)計流程，主要分為 3 個步驟。

1. 找到對應(yīng)模塊

如果說每個模塊是解決「一類業(yè)務(wù)問題」，那么每個功能就要對應(yīng)解決「單個業(yè)務(wù)問題」。

例如我之前做的一家少兒編程機構(gòu)的管理后臺，主模塊分為市場管理、銷售管理、教師管理、教務(wù)管理等。

那么對于線索回海這個業(yè)務(wù)問題，肯定要在銷售管理模塊下做功能設(shè)計。

2. 判斷是否做成可配置

先用一套四象限法則，介紹一套判斷的方式。

上圖來自網(wǎng)絡(luò)

先說一下第二象限，對于 SaaS 產(chǎn)品來說，如果我們選擇要滿足企業(yè)的個性化需求，尤其是他們占比還比較小，那我們要重點考慮「商業(yè)價值」。

如果對方希望你能幫他解決，但不愿意付錢，那么就要提高警惕了，這個業(yè)務(wù)問題對企業(yè)來說不價值沒那么大。

再說一下第四象限， 這里重點要從 SaaS 產(chǎn)品公司的 ROI（投入產(chǎn)出比）來分析，不能為了滿足客戶而忽略公司的生存。

最后就是第一象限和第四象限，這其實比較好理解，這里就不做過多贅述。

3. 設(shè)計它的默認設(shè)置項

這里需要產(chǎn)品經(jīng)理能夠從大量客戶的個性化場景中，找到最核心的場景，并以此為依據(jù)將該選項作為功能的默認配置。

這樣做的本質(zhì)，是希望減少誤操的可能性。

寫在最后

當然，任何事物都存在兩面性，實際中也不要將所有功能都作為「可配置」。

一來這樣會降低系統(tǒng)的易用性。

要知道，客戶要的不是你的可配置，而是能高效、簡潔的完成自己的工作內(nèi)容，而每個配置項意味著對方需要多一步思考。

過多的配置項不僅造成頁面的不簡潔，同時也會增加流程的步驟。

二來會帶來極高的開發(fā)成本。

如果配置項中的另一種選擇沒有客戶使用，這無疑也是在浪費開發(fā)資源。

而這個問題的起因，又回來到了產(chǎn)品經(jīng)理對業(yè)務(wù)的理解能力不足，需要加強業(yè)務(wù)調(diào)研的能力。

以上就是我對 SaaS 產(chǎn)品功能的設(shè)計的理解，接下來就是希望你我在實踐中，不斷的理解與調(diào)整。

愿你我一起加油，共同成長~

作者：空；公眾號：小木盒產(chǎn)品記

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

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