編輯導讀：需求，每個網際網路從業者耳熟能詳的詞。許多人認為需求就是將使用者想要的東西一一實現，客戶怎麼說，我就怎麼做。但是需求工作，做的是一個編譯器，而不是錄音筆。使用者的錯誤描述、相互衝突的需求會變成偽需求。本文作者將對此進行分析，與你分享。
這篇文章是根據我的經驗和前人的知識，總結了6類常見的偽需求。好了，話不多說，進入正文吧。
“需求”可能是所有產品經理、甚至是所有IT行業從業人員談及最多的詞之一，當提到使用者需求時，所有人都能說上幾句。
許多需求工作者會把客戶的話一模一樣的帶回來，客戶怎麼說，我就怎麼做，其發揮的作用約等於一支錄音筆。需求分析人員如果不能夠做到透過客戶的闡述，把客戶的需求拆解、翻譯，那麼需求分析工作的意義也就不存在了。
需求工作，做的是一個編譯器，而不是錄音筆。
在展開說需求之前，我們先來看一張圖：
圖中包括這麼幾個要素：使用者、場景、任務、需要解決問題（也有人叫訴求、痛點）、使用者對訴求的描述。
當然，這幾個要素也不都是需求的組成，使用者對訴求的描述是對前面四個要素的文字解釋，所以不屬於需求的範疇。一個完整的需求應該包括：使用者、場景、任務、需要解決問題。
基於這四個要素，加上使用者的錯誤描述、相互衝突的需求，共同組成了這麼6類常見的偽需求：
- 錯誤的場景
- 錯誤的使用者群體
- 沒有建立在核心任務的基礎上
- 沒有需要解決的問題
- 使用者詞不達意
- 相互衝突的需求
本文將從這幾個角度出發，介紹幾類常見的偽需求。
01 脫離了真實場景大家一定見過很多拍腦袋、頭腦風暴想出來的需求吧，通常就是屬於這一類，大家在辦公室的場景下和實際使用者在第一線使用時候的場景是不同的，腦海裡的想法更不可能一樣。
這是需求裡面最重要的一個要素，如果連使用者在什麼情況下會有這樣的訴求都不清楚，那麼後續的所有結果都充滿不確定性。
脫離了場景的需求常見有這麼兩種：
脫離了業務場景，往往是對實際情況不明確，就可能會造成產品的實際效果和預期相差甚遠。
就好比你在一個出行APP上前定了一張高鐵票，定完之後在預定成功的提示頁下面給你推薦了買菜的廣告。場景不同，即使擁有巨大的流量，也很難為你所用。
如果說脫離了業務場景是資源浪費，那麼脫離了大背景無疑會把產品送上絕路。
2017年，曾今接觸過一個在做“雲上香”產品的創業者，希望為那些想給祖先上香祭拜，卻遠在他鄉無法實現到場祭拜的人，提供一個線上祭祀的網站。
後來這個網站在運營幾個月後關停，草草收場。該網站是在5線城市的小縣城裡運營和推廣，沒有人知道，什麼樣的情況下，能夠讓祭祀者放棄幾千年的習俗，在網上對著一個電腦上香。
而到了2020年疫情期間，祭祀者無法出門祭祀，“雲上香”反而火了一把。
產品在新的品類中最容易出現這種怪像：我幫你填滿了所有的坑，卻只是在為大環境下的後來者培養使用者習慣。
02 並非目標使用者脫離了使用者群體的需求，常見有這麼三類：
- 把自己的需求當成使用者的需求；
- 不是我們的使用者；
- 過於小眾的使用者群體；
經常看到有人說產品經理的同理心，要發現使用者的需求。我覺得這是個偽命題，產品經理很難深入一線在每一個真實場景的下完成所有任務，即使是產品深度使用者，也很難代表整個使用者群體。
但是，常常有老闆會樂此不疲的強調所謂的“同理心”，似乎這樣能夠讓自己看起來更專業。
與其說產品經理的同理心是要發現使用者的需求，不如說是要了解和驗證使用者遇到的問題。
除去這種的常見的投射效應，非目標使用者提出來的需求也是屢見不鮮。
先不妨來看個故事：
（背景：產品是一個資源管理系統，主要提供圖片、影片的錄入和共享）
客戶領導：我覺得你們這個系統有點不好用啊！
PM ：是嗎？哪裡不好用了？
客戶領導：你看，你們這個上傳，上傳的時候，都沒有要求要打標籤。
PM：這個是考慮到便捷性，不然每一張圖片都要手動打標籤，大家都不願意傳了。
客戶領導：你不要這樣想，只有每張圖片都必須填寫這麼多資訊，大家才會覺得這個事情不容易，才會重視這個事情。
PM：……（心裡一萬句MMP）
很多提需求的人其實並不是我們的目標使用者群體（或許提需求的人自己認為是），所以提出來的需求並沒有太大的實際價值。
有趣的是，在B端的產品中，有時候非目標使用者提出來的需求會更受重視，可能他們才是直接付費者。
還有部分使用者，可能確實有需求，需求也合理，但是這部分人極少，所以不考慮。
大家都知道B站最初是一個ACG影片創作、分享網站，某天一個ACG愛好者想給一個女生買一個包，想看看B站有沒有相關的影片，結果沒找到。於是他覺得B站這點沒做好，應該開設“奢侈品包”這樣一個欄目。很顯然， 沒有哪個產品經理會理會這個需求，因為B站的主流使用者的畫像和奢侈品包包的購買群體重合度極低。
03 脫離了核心任務脫離了核心任務的需求常見這麼幾類：
- 使用者並不想完成任何任務；
- 需求偏離了核心任務；
- 和核心任務流程相悖；
有些使用者並不會在產品上完成任何一個任務，但是如果你讓他提需求或改進意見，他卻可以頭頭是道的跟你說出個子醜寅卯。
常見的莫過於ToB產品的客戶領導，他並不需要完成任何任務，卻可以從你的幻燈片中看到產品的不足和需要改進的地方。
許多人想把產品做的大而全，這恐怕是最常見的和核心任務偏離了。
來看個關於大而全的故事：
（背景：產品是一個媒體採編系統，核心任務為使用者提供寫稿、編輯、釋出的功能）。
領導：我們到後面要做統計，把資料統計出來並生成報表給使用者。
PM：這個是要做的，已經在考慮了。
領導：我們要做個網盤，使用者可以自己上傳東西上來，採寫稿件的時候可以用到。
PM：額，這個應該不是那麼重要吧。
領導：我們還要做個雜誌閱覽的功能，我上次看有些客戶有自己的出版物，可以放上來，到時候就不需要找書翻資料了；
PM：……
故事中的領導可能是很多領導的縮影，就是我什麼都想要，這就容易陷入一個泥潭，越是想做大而全，越是容易做成大而“爛”。
避免大而“爛”，確認產品定位是關鍵，否則，所有的需求不算超出產品的邊界，因為我的產品邊界就是整個網際網路的邊界。
和使用者的核心任務流程背道而馳，其實就是我們常說的“不符合使用者習慣”的一種。其實這裡面又可以分為三種：
- 簡化使用者核心任務流程；
- 複雜化使用者核心任務流程；
- 脫離了原有的任務流程；
嚴格意義上講，三種都可以是偽需求。可是實際上，簡化了使用者的任務流程的需求，一般不會被定義成偽需求，因為這一類需求往往被認為是解決了所謂的“操作流程複雜”的問題（實際上，即使簡化任務流程，也需要經過無數次驗證）。
04 沒有需要解決的問題使用者沒有這樣的訴求或者是說使用者並沒有遇到任何的問題，也不需要你提供任何的解決方案，但是依舊有許多的產品人像是疊積木一樣，不斷在產品上累加新功能，這往往來自產品經理或者老闆的不自信，可能來自兩個原因：
一是因為別人有這個功能，所以我也要有，似乎這樣能夠在介紹產品的時候顯示產品的“強大”。使用者其實並不關注你有多少功能，更不可能所有的任務都在一個產品上處理，他們只在乎自己的問題是否得到了很好的解決。
二是不開發點新功能模組，就感覺我沒做什麼工作，或展現不出我的水平。
於是就有了接下來的這一幕，產品經理把成熟市場中驗證過的產品功能，跨界移植到自己的產品中。最終產品演化成了一個四不像。
05 使用者的描述≠真實需求其實這一類可能並不是一個完整的需求，但是許多初級的產品經理卻對這一類“需求”格外執著，有一些會樂此不疲的做著這些沒有意義的工作，還有一些產品會認為這些提需求的使用者都是奇葩。
使用者說出來的話其實往往是和這四個要素脫離開的，單純的把客戶的話帶回來，往往是最簡單省事的辦法。不合格的需求分析看什麼都是奇葩需求，高階的需求往往能透過表面，瞭解其中原委。
使用者的描述經常會出現這麼幾個現象：
如果跑到使用者面前去問使用者想要什麼，使用者會告訴你“我想要這個地方加個按鈕，實現……”、“我想讓系統進入的時候預設展示個人資訊”、“我想讓點選提交按鈕的時候，出來一個選擇框，用來選擇……”。
大部分使用者告訴你的並不是需求，而是說出了一個他以為的解決方案。
（難道這就是所謂的人人都是產品經理？——關於問題的解決方案似乎每個人都可以說幾句）
來看一個案例：
福特：你想要什麼？
使用者：我想要一匹更快的馬。
讓我們來看看需求的黃金圈法則：
使用者說出來的解決方案，往往是和他內在的需求有一定的聯絡，或許也能解決，但是對於我們的產品來說，不一定是最好的解決方案。
如果使用者給你提了個解決方案，不妨問這幾個問題：使用者是想做一件什麼事？一般做這件事的頻率？為什麼要做這件事？除了提需求的人，還有哪些人、群體需要做這件事？人數大概是多少？目前是怎麼做這件事？目前做這件事遇到什麼問題？除了使用者提出來的這個方案，還有沒有其他方案？
除了提解決方案的使用者，還有許多隻是單純抱怨的使用者，這一類使用者或者是抱怨價格太高，或者是抱怨服務不好，或是抱怨其他。總的來說這一類評價可能會對產品的演化、運營方向有參考意義，但是絕不是一個需求，也千萬別太過認真。
某外賣平臺APP評論
06 衝突的需求這一類的需求嚴格意義上不算是偽需求，他有明確的場景，建立在任務之中，也有自己的訴求，但是由於他和我們的主體方向偏移了，也就註定和我們的產品無緣。
衝突的需求常見這麼幾類：
使用者有時候會提出兩個完全衝突的需求，不過使用者有可能自己並不會發現，當然也有更多衝突的需求是不同使用者提出來的。
不管怎麼樣，當兩個衝突的需求出來的時候，我們選擇了一個，也就註定把另外一個需求視為“偽需求”了。
也有些衝突的需求，產品經理為了把他們全部解決，最終把產品做成了大而全。
比如一個網盤應用，A希望能過把資料夾簡便上傳上去，B希望每次上傳一個檔案並填寫相應的說明。…… 於是產品經理就設計出來了可以配置的上傳功能。
比起相互衝突的需求，和產品衝突的需求似乎就好分辨很多了，簡單點的一句話，“我們的產品本來就不是給你去解決這個問題的！”，不過也有些需求會隨著產品定位的變化，最後變成需要解決的了。
07 發現偽需求需要對問題的深入瞭解需求是一個寬泛又嚴謹的詞，把使用者的任意的一個想法當成需求，那是外行人乾的事。對於產品人來說，每一個需求一定是能解析、有來龍去脈的。否則我們看需求就會產生四個不知道：看到需求不知道使用者為什麼提出來，設計出來的功能不知道為什麼要這麼設計，看到方案不知道有沒有更好的方案，最關鍵是自己還不知道自己啥也不知道。
其實識別偽需求的最直接方式——問幾個問題：
- 場景、使用者、要執行的任務、要解決的問題是否真實？
- 是否有足夠的數量基數？
- 是否要用產品幫使用者解決這個問題？
- 是否會影響其他需求？
本文由 @產品李 原創釋出於人人都是產品經理。未經許可，禁止轉載
題圖來自Unsplash，基於CC0協議