編輯導讀：需求，每個互聯網從業者耳熟能詳的詞。許多人認為需求就是將用戶想要的東西一一實現，客戶怎么說，我就怎么做。但是需求工作，做的是一個編譯器，而不是錄音筆。用戶的錯誤描述、相互沖突的需求會變成偽需求。本文作者將對此進行分析，與你分享。

這篇文章是根據我的經驗和前人的知識，總結了6類常見的偽需求。好了，話不多說，進入正文吧。

“需求”可能是所有產品經理、甚至是所有IT行業從業人員談及最多的詞之一，當提到用戶需求時，所有人都能說上幾句。

許多需求工作者會把客戶的話一模一樣的帶回來，客戶怎么說，我就怎么做，其發揮的作用約等于一支錄音筆。需求分析人員如果不能夠做到通過客戶的闡述，把客戶的需求拆解、翻譯，那么需求分析工作的意義也就不存在了。

需求工作，做的是一個編譯器，而不是錄音筆。

在展開說需求之前，我們先來看一張圖：

圖中包括這么幾個要素：用戶、場景、任務、需要解決問題（也有人叫訴求、痛點）、用戶對訴求的描述。

當然，這幾個要素也不都是需求的組成，用戶對訴求的描述是對前面四個要素的文字解釋，所以不屬于需求的范疇。一個完整的需求應該包括：用戶、場景、任務、需要解決問題。

基于這四個要素，加上用戶的錯誤描述、相互沖突的需求，共同組成了這么6類常見的偽需求：

• 錯誤的場景
• 錯誤的用戶群體
• 沒有建立在核心任務的基礎上
• 沒有需要解決的問題
• 用戶詞不達意
• 相互沖突的需求

本文將從這幾個角度出發，介紹幾類常見的偽需求。

01 脫離了真實場景

大家一定見過很多拍腦袋、頭腦風暴想出來的需求吧，通常就是屬于這一類，大家在辦公室的場景下和實際用戶在第一線使用時候的場景是不同的，腦海里的想法更不可能一樣。

這是需求里面最重要的一個要素，如果連用戶在什么情況下會有這樣的訴求都不清楚，那么后續的所有結果都充滿不確定性。

脫離了場景的需求常見有這么兩種：

• 脫離了業務場景；
• 太過超前，大背景不支持；

脫離了業務場景，往往是對實際情況不明確，就可能會造成產品的實際效果和預期相差甚遠。

就好比你在一個出行APP上前定了一張高鐵票，定完之后在預定成功的提示頁下面給你推薦了買菜的廣告。場景不同，即使擁有巨大的流量，也很難為你所用。

如果說脫離了業務場景是資源浪費，那么脫離了大背景無疑會把產品送上絕路。

2017年，曾今接觸過一個在做“云上香”產品的創業者，希望為那些想給祖先上香祭拜，卻遠在他鄉無法實現到場祭拜的人，提供一個在線祭祀的網站。

后來這個網站在運營幾個月后關停，草草收場。該網站是在5線城市的小縣城里運營和推廣，沒有人知道，什么樣的情況下，能夠讓祭祀者放棄幾千年的習俗，在網上對著一個電腦上香。

而到了2020年疫情期間，祭祀者無法出門祭祀，“云上香”反而火了一把。

產品在新的品類中最容易出現這種怪像：我幫你填滿了所有的坑，卻只是在為大環境下的后來者培養用戶習慣。

02 并非目標用戶

脫離了用戶群體的需求，常見有這么三類：

• 把自己的需求當成用戶的需求；
• 不是我們的用戶；
• 過于小眾的用戶群體；

經?？吹接腥苏f產品經理的同理心，要發現用戶的需求。我覺得這是個偽命題，產品經理很難深入一線在每一個真實場景的下完成所有任務，即使是產品深度使用者，也很難代表整個用戶群體。

但是，常常有老板會樂此不疲的強調所謂的“同理心”，似乎這樣能夠讓自己看起來更專業。

與其說產品經理的同理心是要發現用戶的需求，不如說是要了解和驗證用戶遇到的問題。

除去這種的常見的投射效應，非目標用戶提出來的需求也是屢見不鮮。

先不妨來看個故事：

（背景：產品是一個資源管理系統，主要提供圖片、視頻的錄入和共享）

客戶領導：我覺得你們這個系統有點不好用??！

PM ：是嗎？哪里不好用了？

客戶領導：你看，你們這個上傳，上傳的時候，都沒有要求要打標簽。

PM：這個是考慮到便捷性，不然每一張圖片都要手動打標簽，大家都不愿意傳了。

客戶領導：你不要這樣想，只有每張圖片都必須填寫這么多信息，大家才會覺得這個事情不容易，才會重視這個事情。

PM：……

很多提需求的人其實并不是我們的目標用戶群體（或許提需求的人自己認為是），所以提出來的需求并沒有太大的實際價值。

有趣的是，在B端的產品中，有時候非目標用戶提出來的需求會更受重視，可能他們才是直接付費者。

還有部分用戶，可能確實有需求，需求也合理，但是這部分人極少，所以不考慮。

大家都知道B站最初是一個ACG視頻創作、分享網站，某天一個ACG愛好者想給一個女生買一個包，想看看B站有沒有相關的視頻，結果沒找到。于是他覺得B站這點沒做好，應該開設“奢侈品包”這樣一個欄目。很顯然， 沒有哪個產品經理會理會這個需求，因為B站的主流用戶的畫像和奢侈品包包的購買群體重合度極低。

03 脫離了核心任務

脫離了核心任務的需求常見這么幾類：

• 用戶并不想完成任何任務；
• 需求偏離了核心任務；
• 和核心任務流程相悖；

有些用戶并不會在產品上完成任何一個任務，但是如果你讓他提需求或改進意見，他卻可以頭頭是道的跟你說出個子丑寅卯。

常見的莫過于ToB產品的客戶領導，他并不需要完成任何任務，卻可以從你的幻燈片中看到產品的不足和需要改進的地方。

許多人想把產品做的大而全，這恐怕是最常見的和核心任務偏離了。

來看個關于大而全的故事：

（背景：產品是一個媒體采編系統，核心任務為用戶提供寫稿、編輯、發布的功能）。

領導：我們到后面要做統計，把數據統計出來并生成報表給用戶。

PM：這個是要做的，已經在考慮了。

領導：我們要做個網盤，用戶可以自己上傳東西上來，采寫稿件的時候可以用到。

PM：額，這個應該不是那么重要吧。

領導：我們還要做個雜志閱覽的功能，我上次看有些客戶有自己的出版物，可以放上來，到時候就不需要找書翻資料了；

PM：……

故事中的領導可能是很多領導的縮影，就是我什么都想要，這就容易陷入一個泥潭，越是想做大而全，越是容易做成大而“爛”。

避免大而“爛”，確認產品定位是關鍵，否則，所有的需求不算超出產品的邊界，因為我的產品邊界就是整個互聯網的邊界。

和用戶的核心任務流程背道而馳，其實就是我們常說的“不符合用戶習慣”的一種。其實這里面又可以分為三種：

• 簡化用戶核心任務流程；
• 復雜化用戶核心任務流程；
• 脫離了原有的任務流程；

嚴格意義上講，三種都可以是偽需求?？墒菍嶋H上，簡化了用戶的任務流程的需求，一般不會被定義成偽需求，因為這一類需求往往被認為是解決了所謂的“操作流程復雜”的問題（實際上，即使簡化任務流程，也需要經過無數次驗證）。

04 沒有需要解決的問題

用戶沒有這樣的訴求或者是說用戶并沒有遇到任何的問題，也不需要你提供任何的解決方案，但是依舊有許多的產品人像是疊積木一樣，不斷在產品上累加新功能，這往往來自產品經理或者老板的不自信，可能來自兩個原因：

一是因為別人有這個功能，所以我也要有，似乎這樣能夠在介紹產品的時候顯示產品的“強大”。用戶其實并不關注你有多少功能，更不可能所有的任務都在一個產品上處理，他們只在乎自己的問題是否得到了很好的解決。

二是不開發點新功能模塊，就感覺我沒做什么工作，或展現不出我的水平。

于是就有了接下來的這一幕，產品經理把成熟市場中驗證過的產品功能，跨界移植到自己的產品中。最終產品演化成了一個四不像。

05 用戶的描述≠真實需求

其實這一類可能并不是一個完整的需求，但是許多初級的產品經理卻對這一類“需求”格外執著，有一些會樂此不疲的做著這些沒有意義的工作，還有一些產品會認為這些提需求的用戶都是奇葩。

用戶說出來的話其實往往是和這四個要素脫離開的，單純的把客戶的話帶回來，往往是最簡單省事的辦法。不合格的需求分析看什么都是奇葩需求，高級的需求往往能透過表面，了解其中原委。

用戶的描述經常會出現這么幾個現象：

• 用戶只是提出了一個解決方案；
• 用戶其實只是單純的在抱怨；

如果跑到用戶面前去問用戶想要什么，用戶會告訴你“我想要這個地方加個按鈕，實現……”、“我想讓系統進入的時候默認展示個人信息”、“我想讓點擊提交按鈕的時候，出來一個選擇框，用來選擇……”。

大部分用戶告訴你的并不是需求，而是說出了一個他以為的解決方案。

（難道這就是所謂的人人都是產品經理？——關于問題的解決方案似乎每個人都可以說幾句）

來看一個案例：

福特：你想要什么？

用戶：我想要一匹更快的馬。

讓我們來看看需求的黃金圈法則：

用戶說出來的解決方案，往往是和他內在的需求有一定的聯系，或許也能解決，但是對于我們的產品來說，不一定是最好的解決方案。

如果用戶給你提了個解決方案，不妨問這幾個問題：用戶是想做一件什么事？一般做這件事的頻率？為什么要做這件事？除了提需求的人，還有哪些人、群體需要做這件事？人數大概是多少？目前是怎么做這件事？目前做這件事遇到什么問題？除了用戶提出來的這個方案，還有沒有其他方案？

除了提解決方案的用戶，還有許多只是單純抱怨的用戶，這一類用戶或者是抱怨價格太高，或者是抱怨服務不好，或是抱怨其他?？偟膩碚f這一類評價可能會對產品的演化、運營方向有參考意義，但是絕不是一個需求，也千萬別太過認真。

某外賣平臺APP評論

06 沖突的需求

這一類的需求嚴格意義上不算是偽需求，他有明確的場景，建立在任務之中，也有自己的訴求，但是由于他和我們的主體方向偏移了，也就注定和我們的產品無緣。

沖突的需求常見這么幾類：

• 兩個需求相互沖突；
• 和產品定位沖突；

用戶有時候會提出兩個完全沖突的需求，不過用戶有可能自己并不會發現，當然也有更多沖突的需求是不同用戶提出來的。

不管怎么樣，當兩個沖突的需求出來的時候，我們選擇了一個，也就注定把另外一個需求視為“偽需求”了。

也有些沖突的需求，產品經理為了把他們全部解決，最終把產品做成了大而全。

比如一個網盤應用，A希望能過把文件夾簡便上傳上去，B希望每次上傳一個文件并填寫相應的說明?！?于是產品經理就設計出來了可以配置的上傳功能。

比起相互沖突的需求，和產品沖突的需求似乎就好分辨很多了，簡單點的一句話，“我們的產品本來就不是給你去解決這個問題的！”，不過也有些需求會隨著產品定位的變化，最后變成需要解決的了。

07 發現偽需求需要對問題的深入了解

需求是一個寬泛又嚴謹的詞，把用戶的任意的一個想法當成需求，那是外行人干的事。對于產品人來說，每一個需求一定是能解析、有來龍去脈的。否則我們看需求就會產生四個不知道：看到需求不知道用戶為什么提出來，設計出來的功能不知道為什么要這么設計，看到方案不知道有沒有更好的方案，最關鍵是自己還不知道自己啥也不知道。

其實識別偽需求的最直接方式——問幾個問題：

• 場景、用戶、要執行的任務、要解決的問題是否真實？
• 是否有足夠的數量基數？
• 是否要用產品幫用戶解決這個問題？
• 是否會影響其他需求？

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

題圖來自Unsplash，基于CC0協議