如何評估需求的可行性?

1 評論 12594 瀏覽 81 收藏 9 分鐘

當一個需求出現的時候,如何評估做不做?本文作者對這個問題進行了分析梳理,從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

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 高考作文跑題了吧

    來自山東 回復