本文從三個步驟分析了如何做需求可行性分析。

產(chǎn)品經(jīng)理在熟悉自家產(chǎn)品脈絡(luò)后，一般會承接一些小的功能模塊的需求。而承接需求的第一步就是判斷需求可行性。

01 為什么要判斷需求可行性

為什么要判斷需求可行性，主要基于三點(diǎn)：

1. 保證科學(xué)性

沒有經(jīng)過審視的人生是不值得過的，同樣，沒有經(jīng)過審視的需求也是不值得做的。產(chǎn)品經(jīng)理作為需求的第一負(fù)責(zé)人，有責(zé)任保證需求本身的正確性。

2. 說服團(tuán)隊成員

產(chǎn)品經(jīng)理作為需求的第一承接方，承擔(dān)著說服開發(fā)、UI以及公共服務(wù)部門的職責(zé)。如果自己都沒有搞明白需求是否可行，很難說服團(tuán)隊的其他成員。

3. 防甩鍋

如果你經(jīng)歷過上司甩過來一個需求，你哼哧哼哧做了，最后拿給上司看的時候，對方一臉鐵青地說：“這不是我想要的，你當(dāng)初為什么不問我？” 你就知道我在說什么了。

02 如何判斷需求可行性呢

那么如何判斷需求可行性呢？說來話長了。

第一步是思考需求的目的

以人為主體的活動，總是目的先行。需求只是表象，歸根結(jié)底是需求來源方的利益訴求。

一款產(chǎn)品的需求來源方，可以籠統(tǒng)分為三類：經(jīng)營者、使用者和合作者。經(jīng)營者即產(chǎn)品的擁有方和背后的投資者。使用者即以使用產(chǎn)品的功能性模塊為主的用戶，合作者則指廣告、資源置換、線上線下聯(lián)動等非功能性活動組織者。

不同類別的需求來源方，背后的利益訴求也各不相同：

• 經(jīng)營者在乎的是產(chǎn)品的成本收益，以及產(chǎn)品是否可以作為渠道串聯(lián)外界資源，打造品牌；
• 使用者在乎的是產(chǎn)品能否解決現(xiàn)實(shí)場景下的實(shí)際需求，以及使用當(dāng)中的用戶體驗(yàn)；
• 合作者在乎的是廣告位的曝光量和轉(zhuǎn)化效果。

我們不妨在場景中感受一下不同需求來源方的需求差異：

背景：一款背單詞軟件words.

場景1：words的老總給產(chǎn)品經(jīng)理提了需求，要求上線新用戶領(lǐng)七天紅包活動。

場景2：words接收反饋的后臺，產(chǎn)品經(jīng)理看到有用戶吐槽，許多單詞的釋義都不全。

場景3：words的線下合作者，公校老師們想要互通有無，因此希望在words上有一個溝通社區(qū)。

按照判斷需求可行性的第一步，我們其實(shí)應(yīng)該找對方的需求方調(diào)研，找出背后的目的，于是，完整的因果鏈就出來了：

背景：一款背單詞軟件words.

場景1：words目前正在尋求融資，而融資方的要求是產(chǎn)品的七日留存率得達(dá)到30%。為了達(dá)到這個目的，words的老總給產(chǎn)品經(jīng)理提了需求，要求上線新用戶領(lǐng)七天紅包活動。

場景2：words接收反饋的后臺，產(chǎn)品經(jīng)理看到有用戶吐槽，許多單詞的釋義都不全，調(diào)研得知，這里的不全主要是指查詞時。

場景3：words的線下合作者，公校老師們想要互通有無，因此希望在words上有一個溝通社區(qū)。

第二步是思考目的本身是否和產(chǎn)品現(xiàn)有邏輯沖突，以及有沒有更好的解決辦法

仍以上述場景為例：

產(chǎn)品的七日留存率達(dá)到30%

這類問題一般有兩個步驟：窮盡所有的方案，核算成本收益。譬如讓產(chǎn)品留存率達(dá)到30%，有5種解法，其中七天紅包的成本最低。

但目前產(chǎn)品中已經(jīng)有類似的打卡活動，七天紅包會影響到打卡活動的活躍度。這時又應(yīng)該考慮到系統(tǒng)和全局問題，做出綜合判斷。

還有特殊情況，即單一解法的上限低于目標(biāo)要求，假如七天紅包本身不足以推動留存率提升至30%，還需要和次優(yōu)解法組合。這里存在的難點(diǎn)是對七天紅包留存率的判斷和組合后的效果重疊值。但這只能靠經(jīng)驗(yàn)或歷史數(shù)據(jù)彌補(bǔ)了。

查詞界面的單詞釋義不全

查詞界面和背單詞界面完全是不同的場景，查詞時要求的是全面，但背單詞時要求的是快速并且只需求記住高頻釋義。如果這個需求點(diǎn)沒有弄清楚而盲目地把查詞界面和背單詞界面的釋義都改了，那麻煩就大了。

公校老師想要互通有無

按照解題的步驟，窮盡方案，核算成本收益。不難得出，相比于自建社區(qū)，不如利用QQ群等三方社交工具進(jìn)行解決。這樣一來，溝通社區(qū)的需求就顯得不很劃算。當(dāng)然，如果不是to C的產(chǎn)品，那又另當(dāng)別論了。同樣的情景，換成to B業(yè)務(wù)，主體的滿足對象其實(shí)轉(zhuǎn)移成了運(yùn)營方，自建社區(qū)則成為了增加營收的手段。

第三步是判斷需求在已知約束條件內(nèi)能否如期完成

任何的團(tuán)隊，資源配比都是有限的。有時候一個需求，要么抽派不出人手，要么人手抽派出來，實(shí)現(xiàn)需求的最佳黃金時間已經(jīng)過了。這一塊主要的限制在于：

• 人力資源，沒有足夠的人手
• 技術(shù)限制，當(dāng)前的技術(shù)條件不支持
• 邏輯復(fù)雜，單一需求牽涉到的功能模塊實(shí)在太多
• 時間限制，對于一些運(yùn)營性的活動需求，很講究時間

其中：

• 人力資源的限制，應(yīng)該在解法出下功夫，即使是小需求也嘗試畫出roadmap，找出能實(shí)現(xiàn)的mvp方案，小步迭代。
• 技術(shù)限制，要么換方案，要么嘗試人為簡化算法。當(dāng)然，硬件上面的問題就看公司資源是否支持了。
• 邏輯復(fù)雜，牽一發(fā)而動全身的需求，說明產(chǎn)品的架構(gòu)和技術(shù)實(shí)現(xiàn)有問題，無法實(shí)現(xiàn)模塊化。這時候不要盲目地增添新的功能，最應(yīng)該做的是重新梳理產(chǎn)品架構(gòu)，增加架構(gòu)本身的可擴(kuò)展性。
• 時間限制，這是溝通不利導(dǎo)致的問題。產(chǎn)品和運(yùn)營應(yīng)該在需求剛出爐時即探討實(shí)現(xiàn)周期，并保證實(shí)現(xiàn)該功能的人力資源。

上述三步，基本上就是判斷需求可行性的全部。這一塊本就不復(fù)雜，核心仍在于思考的深度。需求的背后到底是為了什么，能得到什么，會有哪些成本？當(dāng)然，得到和成本也需要一套邏輯來分析，初期的產(chǎn)品經(jīng)理可以多從前輩那兒，或是競品的迭代記錄中找到可參照的案例和經(jīng)驗(yàn)。

最后再格外強(qiáng)調(diào)一點(diǎn)的是，外部風(fēng)險問題。有的業(yè)務(wù)需求，譬如違規(guī)爬蟲，是違反了當(dāng)前的政策法律的。再譬如游戲化的教育產(chǎn)品，游戲化本身也是受到相關(guān)部門的監(jiān)管的，這些外在的宏觀因素，也是在做需求時要警惕的因素。

以上則是本章的全部內(nèi)容，感謝讀閱。

#專欄作家#

善寶橘，微信公眾號：善寶橘，人人都是產(chǎn)品經(jīng)理專欄作家。一個崇尚終身學(xué)習(xí)的互聯(lián)網(wǎng)斜杠青年，擅長學(xué)界理論與業(yè)界實(shí)踐結(jié)合，專注新媒體、游戲領(lǐng)域的運(yùn)營策劃。當(dāng)然，偶爾會寫點(diǎn)互聯(lián)網(wǎng)時事評論。

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

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