首頁 精選文章 如何評估商品需求的可行性?...

如何評估商品需求的可行性?

29
0

如何評估商品需求的可行性?

當一個需求出現的時候,如何評估做不做?我們針對這個問題進行了分析梳理,從2個大方向對這個問題總結了自己的看法。作為一個產品人員,接收需求已經成為家常便飯,無論是來各種行業、運營、用戶或者同行建議,經常可能遇到的問題是:這麽多的需求,我到底做不做?什麽時候做?

作為大家熟知的重要緊急四象限,不知道被多少人說爛了。但是,問題就在於,你要如何去填充這個四象限?從個人的一個從業經歷中,結合日常接觸的業務,總結了這麽幾個方向去拓展細分:

一、這個需求類屬於bug或是類屬於新功能?
如果,這個需求類屬於bug,一般情況下需要去分析:

這個bug是否影響產品的業務主流程?這類型的bug屬於救火型,一刻不得耽擱。
這個bug影響的用戶基數有多少?這個取決於你這個產品的體量。如果是百萬用戶,影響一兩百個無關痛癢;如果是剛起步的,這個 就即為致命了,不改=等死。
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. 回歸最根本,必須考慮的一個問題:新功能上線的成本
成本這東西,簡單來說:需要多少人,需要多少錢,需要多少時間。相信,很多的產品經理,這部分都能考慮的很周到,在基於公司當前項目安排的情況下,都能處理好。

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

留下一個評論

Please enter your comment!
Please enter your name here