產品經理的用研手冊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

推薦閱讀：