產品經理的用研手冊03 - 成也需求,敗也需求

如果你根本不知道自己在討論什麼,那麼對其強求精確是毫無意義的。 —— 馮·諾依曼

我們用「產品」這個詞來表示那些試圖滿足一系列複合期望的產物。複合意味著它們來自許多人。找到誰是這些「人」,是明確需求的一個主要部分。上一篇,00 分享了一些如何分類和描述用戶的經驗。

接下來,我們將要走進需求的沼澤,深入產品開發險惡的腹地,看看需求這個妖孽如何把眾多產品經理拖入泥潭之中。

需求很關鍵,可現實往往是,人們不知道自己想要什麼;而且,產品經理不知道人們想要什麼;雪上加霜的是,產品經理不知道人們不知道他們想要什麼……產品開發再高效也好,都是一種浪費。認真探索需求,我們才不會做出然並卵的產品。

關於萬惡的需求,有兩個最最關鍵的問題:

能清楚回答第一個問題,是合格的產品經理,能正確回答第二個問題,才是好的產品經理。

需求是什麼

從前,有一隻狡猾的妖孽,叫做「需求」。

它長著一張模糊的臉,而且是一張會千變萬化的臉,最善於迷惑那些苦苦尋找它的人。不同的人看到這個妖孽,描述出來的樣貌都不一樣,似乎從來沒有人能識別它的真面目 —— 還是說,它就沒有真面目?(攤手)

區分需求和解決方案

人們之所以經常被需求妖孽所迷惑,還因為他/她/它經常跟另外一個妖孽「解決方案」互換軀殼,所以懵圈的人們經常追著「解決方案」喊「需求」。為了早日讓需求妖孽現身,我們需要練就一雙區分它倆的廢眼,哦不,慧眼。

舉個栗子

在編輯模塊中,用戶需要一個預覽頁面

在抓需求妖孽的時候,一不留神,我們會在急忙之中抓過來一隻解決方案妖孽,睜眼瞎地指著它說:呔!這就是需求,快給我拿下~ 這個例子中,預覽頁面就是被誤捉的解決方案妖孽,而需求妖孽還在附近不知道哪個角落悠閑地遊盪著。

捉錯妖孽,會給我們製造很多麻煩:

  • 誤解實際的需求
  • 帶著過多假設和預判去思考
  • 錯過更佳的解決方案

在這裡,00 介紹一個識別兩隻妖孽的簡便方法。

需求妖孽往往這樣長著這樣的嘴臉:

我想【達到什麼目的】

需求一般應該帶有更多關於狀態、行為、態度的描述。

解決方案則往往可以這樣描述:

我要【有什麼特點的東西】

它已經開始描述對象是什麼樣子。

來來來,下面進入栗子時間。我們活捉一隻妖孽,聽聽它說了些什麼。

我想要一個循環播放的按鈕

嗯哼?

開始描述對象了。這廝是解決方案妖孽!

別著急把它推開,每當我們發現又捉錯了妖孽時,不妨對它進行逼問,它會老實告訴你需求妖孽的藏身之處。逼問的方法很簡單,只有三個字 ——「為什麼」:

S 妖:我想要一個循環播放的按鈕

你:為什麼?

S 妖:我想循環播放歌曲

你:為什麼?

S 妖:我想連續播放喜歡的歌曲

你:為什麼?

S 妖:你是復讀機么?…… 我想在睡前連續播放喜歡的歌曲

你:為什麼?

W 妖:媽呀救命這是復讀機妖……我希望在不能/不想人為操作重複播放時,我喜歡的歌曲能夠連續播放

逼問過程中,需求妖孽自動現形了!這就是歪歪歪復讀機大法。

在更具體的需求描述中,類似場景信息如「睡前」、體驗預期如「不想人為操作」、隱含需求「播放喜歡的歌曲」等,都會浮現,這對具體的方案設計提供了更多決策信息。

更多關於用戶需求的挖掘和分析,請留意本系列後續的文章。

區分用戶需求和業務需求

好了,需求妖孽總算抓到了。

不過這廝可不是省油的燈,一不留神,它又使出分身術,變成兩個妖孽:一個叫用戶需求妖,一個叫業務需求妖。用人間的話來說,用戶需求是「用戶想要什麼」,業務需求是「我們應該怎麼做」。

難道用戶想要的不就是我們應該做的嗎?是,也不是。

用戶想要的是結果,我們應該做的是保證得到這個結果的所有環節,包括用戶看到的每一個界面、從他們那裡得到的輸入數據、帳戶生成和標識、數據存儲和傳輸、計算、請求、加密等等等等,全部都是業務需求。

業務需要達到一定的使用量、訪問量、購買量、轉化率,這些需求都跟用戶需求有關,但實際要做的遠不止用戶所表述的需求。用戶並不需要註冊,但是業務需要獲取和保存用戶信息;用戶不需要統計上報自己的數據,但是業務需要數據輔助分析和決策,等等。

你的團隊,如何處理業務需求和用戶需求的關係?

需求值不值得做

需求捉妖過程對產品經理來說,已經足夠有挑戰了,但真正的好 (da) 戲 (keng) 還在後面。

產品開發的資源永遠有限,哪些該做?哪些該先做?

關於值得不值得的問題,實質是 ROI (投入產出比)的問題。如果能算清「用多大成本實現了多大價值」這筆賬,做出合理的判斷應該不難。

困難的是,這筆賬似乎永遠都是一筆糊塗賬。

我們來嘗試理理思路。

幫助用戶實現價值,業務和產品就有價值,從而獲得收益。假設這個推論成立,那麼問題可以描述成:哪些需求可以放大用戶價值?想一想平時我們離不開的產品,它們帶來了哪些價值,為什麼離不開?00 總結了一個判斷用戶價值的簡易公式:

需求強度

人們有多需要一個東西,由兩個問題決定:

  • 有多痛/癢?
  • 有多稀缺?

痛癢的問題,其實就是我們常說的是否「剛需」。但是剛需也因人而異,比如說,VPN 對我來說是剛需,對我媽則不是。那麼怎麼可以更好判斷出痛點/癢點呢?

一個角度,是從使用者自身出發,分析這個需求的四個特性:

  • 價值:比如,多大程度上幫我省錢省時間,實現人生目標
  • 預期:比如,買個旅行機票,幫我把簽證都辦了
  • 可陳述程度:比如,美顏只是顯性的,萬人迷是隱性的
  • 已滿足程度:這個就不用距離了

另外一個角度,則是從外部同類產品的比較來看,著名的 Kano 模型:

根據滿意程度和重要程度劃分功能需求:

  • 及格線:大家都有的你沒有,就會被罵辣雞
  • 備胎線:恰好達到行業平均水平,也只是個可以當備胎的良民
  • 粉絲線:人無我優,遠超期望,用戶一接觸就會內心驚呼「卧槽」,然後路轉粉,粉轉腦殘粉

以上是痛/癢問題。稀缺問題則比較好理解。市場上有哪些同類或類似的解決方案?你的產品有多獨特?用戶通過什麼渠道接觸到?這些渠道你有多大的份額、影響力、把控能力?物以稀為貴,稀少的東西,總是能加強痛點和癢點。

使用頻率

判斷出需求強度以後,還需要考慮使用頻率。典型的例子是旅行市場,需求巨大,但就是頻率太低,活躍度和留存率都不好做。考慮使用頻率,可以從用戶比例和場景頻率兩個維度出發。

  • 多大比例用戶想要?
  • 需求場景的頻率如何?

這兩個問題雖然很難得到準確的數據,但是仍然要想辦法估算。上一篇文章介紹的用戶快照這個時候就能夠派上用場。

  • 如果與實現用戶的行為目標強相關,使用頻率應該較高。比如,電商平台的購物車功能
  • 如果最重要的用戶類型需要它,使用頻率相對較高。比如,某直播平台最重要的用戶類型是遊戲玩家,那麼主播的遊戲等級可能就變得重要
  • 典型場景的客觀發生頻率較高,使用頻率應該較高。比如,用來 p 朋友圈圖片的工具
  • 典型場景在用戶生活中地位重要,使用頻率相對較高。比如,每天上下班要在地鐵里呆上兩小時,看書聽歌看視頻的頻率就會更高。

花了這麼長的篇幅分析了如何判斷用戶價值,這只是 ROI 的 R (Return)部分,至於 I (Investment)的分析又是另一門學問。畢竟這個系列寫的是用研手冊,產品經理專職範疇內的難題,就不繼續展開了。

警惕偽需求

需求妖孽之所以是妖孽,不但因為行蹤詭秘,而且容易被冒名頂替。偽需求們是資源的黑洞,怎麼填都填不滿。如何識別偽需求呢?它們一般會以這些面目出現:

偽裝成解決方案。這個上文已經仔細分析過。

偽裝成常見場景。作為果粉 + watch 黑,00 一直覺得 Apple Watch 把邊緣場景成功偽裝成常見場景。在一個手機不離身的時代,手錶真正能替代手機的場景有多少呢?

偽裝成大部分人的需求,實際上只是枝節需求。如果不清楚自己產品的用戶類型,不清楚哪類用戶是最重要的,這種偽裝就容易矇混過關。比如當年已經做出來但沒有最終上線的微信朋友圈濾鏡功能。濾鏡多好啊,大家都需要,Instagram 是成功案例,新浪微博有,QQ 空間也有,為什麼不做呢?微信一定能做出強大好用的濾鏡,但是,微信為什麼要提供一款濾鏡功能呢?大家發朋友圈的動機到底是什麼呢?如果沒有好友關係的沉澱,豐富有趣的互動方式和氛圍,就算在微信裡面再造一個 Instagram 又有什麼意義呢?

偽裝成可以脫離商業模式而存在。這是最可怕的偽裝。沒人不喜歡 Kano 模型中遠超預期的功能,但是這些功能為什麼往往大家都沒有提供?原因多半是:不經濟,不可持續。

關於折磨人的需求,就討論到這裡。

下一篇我們介紹用戶研究主要能解答什麼類型的問題。

專欄文章

  • 產品經理的用研手冊04 - 做問題求解者,先對症後下藥
  • 產品經理的用研手冊02 - 你真的懂用戶嗎?

  • 產品經理的用研手冊01 - 朦朧的用戶,懵懂的你

  • 最好的時代,最壞的時代:一個互聯網職業迷茫症患者的問題清單

如果你還需要:

  • 深入討論本文的內容
  • 本系列文章的更新通知
  • 關於產品、設計、用研、職業發展等問題想問 00
  • 精選書單等資源的推薦

歡迎加入「你丫全棧」微信交流群。入群方法:請加微信 artncode,稍後會拉你入群。

如需轉載本文,請聯繫 uegeek@gmail.com

推薦閱讀:

2017年值得嘗試的SEO策略,用戶體驗對流量影響巨大
那就把你的手機貼膜撕了吧
UX 設計師顏色工具包
《用戶體驗設計師的必修課 》知乎Live筆記(1)
數據圖表化的兩個關鍵點

TAG:产品经理 | 用户研究 | 用户体验 |