當一個需求出現的時候，如何評估做不做？本文作者對這個問題進行了分析梳理，從2個大方向對這個問題總結了自己的看法，與大家分享。

作為一個產品人員，接收需求已經成為家常便飯，無論是來自老板老板、運營、用戶或者同行建議，經?？赡苡龅降膯栴}是：這么多的需求，我到底做不做？什么時候做？今天，借著最近許久沒提筆總結，來和大家一起討論，也希望評論中能夠有指正和補充。

作為大家熟知的重要緊急四象限，不知道被多少人說爛了。但是，問題就在于，你要如何去填充這個四象限？

從個人的一個從業經歷中，結合日常接觸的業務，總結了這么幾個方向去拓展細分：

一、這個需求類屬于bug或是類屬于新功能？

如果，這個需求類屬于bug，一般情況下需要去分析：

1. 這個bug是否影響產品的業務主流程？這類型的bug屬于救火型，一刻不得耽擱。
2. 這個bug影響的用戶基數有多少？這個取決于你這個產品的體量。如果是百萬用戶，影響一兩百個無關痛癢；如果是剛起步的，這個 就即為致命了，不改=等死。
3. bug是否影響到特定人人群？如果你的產品比較特殊，比如是一款游戲，bug對99.9%的用戶沒有影響，可就是讓那么一小部分的氪金大佬難受了，那就麻溜的抱著程序員大腿去改吧！畢竟，這些是真正的衣食父母。

BUG型需求，一般考慮這三個要素就可以了，而非BUG型需求嗎，可能就比較復雜了，我們繼續討論

二、新功能類別的需求要如何處理？

對于新功能的一個評估，個別參數和BUG的有所類同，也不用著急，我們來一個個的探討。

1. 這個需求面向的用戶在產品中扮演的角色是什么？【B TO C】

舉個比較好玩的例子B TO C TO C，也就是常見的如美團外賣。產品涉及到商家、用戶、以及外賣員。外賣員送外賣經常會遇到延遲被投訴的情況，從而導致差評或者罰款。

但是，有很多時候，外賣延遲送達可能是因為商家做的慢了，交通堵塞了等客觀因素。

如果你作為外賣平臺的產品經理，收到外賣員給你提的需求：增加一個申訴提交功能，需要可以拍照，用來證明延遲送達外賣不是我的問題，要取消部分差評和罰款。

這個時候，這個需求對外賣員是合理的，真實的。但是，作為平臺的產品，基于國情，你大概是不能做的。

企業都是為了賺錢，他們不會去考慮外賣員的營收如何，他們會在意c端用戶舒不舒服，他們也會在意b端商家會不會因為一次延遲送達失去一位c端用戶，但是他們真的很難在意外賣員舒不舒服。為什么呢？因為外賣員這個角色，真的太多了，隨時可以替換。

這也是為什么，我要說，當一個需求出來，我們需要分析需求面向的用戶，扮演的角色是什么？如果是產品在意的用戶，那這種需求可以考慮。否則，請慎重。

2. 繼續衍生上一個問題，在常見的TO C產品中，我們要考慮的就是這個需求面向的用戶基數如何？以及這部分用戶是否為核心用戶

大多數的TO C產品，很少回去區分核心用戶（上面提過的游戲類的除外）。一般是去區分，這個功能面對的用戶基數如何。

比如，微信要和QQ一樣增加一個偏向低領用戶的功能?？赡?，在微信中就不會太實用。畢竟現在微信成人的基數和使用頻率更高。

3. 這個功能上線后，是否會大家都喜歡，是有隱患？

可能，你接受到一個需求，這個需求覆蓋了95%的用戶，那么我們需要慎重的是：這些功能是否大家都喜歡？

繼續舉例，你作為一個餓了么產品經理，你收到一個用戶留言：能不能增加一個定時下單功能，這樣我們就可以提前幾天把一周額的外賣都定好了。

你一看，哎呦，不錯??！這個想法看著很牛逼，于是呢，快馬加鞭的就把功能上線了。那么，讓我們一起來看看，你可能會遇到哪些問題？

針對C端用戶，你滿足了這個人的需求，那么，存在的隱患有哪些呢？

首先是紅包機制，一次下五單，減免的金額和五單分開下單的減免金額是一樣的，用不了幾次用戶會發現，你這是在坑我的紅包??？

再說個人喜好，我在三天前，下單今天中午要吃肯德基，那么會出現什么情況呢？

可能我今天不想吃了，但是我忘記我預定了，當外賣送到，如何處理；可能我今天和朋友約了出去吃飯，但是我忘記預定了，當外賣送到，如何處理；可能今天我上火了，我吃不了炸的，當外賣送到，如何處理；

以及更多諸如此類的問題。

針對B端用戶，隱患又有哪些呢？

再說商家可能存在的隱患：一些小作坊，可能突然就不干了，可能突然就停業休息一天。那么，這時候，下單這些商家的用戶要怎么維護？他們的損失有誰來彌補？

這么聯動下去，是不是還得需要增加一套的考核標準，押金體系等等？

再回過頭來說說對產品本身的影響

日活：可能每天打開兩次，現在一周打開一次

轉化：可能一些金主投放的廣告，曝光率瞬間就下降了幾倍，那這部分的損失完全就不可估量了。

所以呢，接收一個需求的時候，一定要考慮好這個需求中的隱患有哪些，切勿被用戶牽著鼻子走

4. 辨別用戶的需求是否只是一個用戶期望的解決方案

這個也是一個老生常談的話題，一個最耳熟能詳的例子：古人對驛站說，我想要一匹跑得快的馬！

這個就是典型的，用戶把解決方案當需求的案例。在這個案例中，用戶的需求其實是：我想要更快的交通工具。在互聯網中，這種案例也是很多，也希望大家互相提醒，避免踩坑。

5. 回歸最根本，必須考慮的一個問題：新功能上線的成本

成本這東西，簡單來說：需要多少人，需要多少錢，需要多少時間。相信，很多的產品經理，這部分都能考慮的很周到，在基于公司當前項目安排的情況下，都能處理好。

至于其他更多的方方面面，其實就沒必要細究了。能夠掌控好以上的幾點，其實也就差不多夠用了。

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

題圖來自 unsplash