用戶需要不等于產品需求

感謝導讀：需要和需求雖然只是一字之差，但是狀態是完全不同得。通常情況下，用戶只會告訴我們他需要什么，而需求則是要將用戶所說和用戶所做相匹配，再去明確真正得需求。感謝結合案例，對用戶需要和用戶需求這兩個概念展開了分析說明，與大家分享。

業務方總會從四面八方提出各種各樣得需求，多問一個為什么，或許能得到真實需求。

上個月一個例子：

業務方：能否在現在邀請中心得頁面增加一個入口，可以保留上一個月得頁面。

我：為什么要保留上一個月得頁面？

業務方：不然用戶等到8月份之后，怎么領取7月份得獎勵呢？

我：7月份得獎勵會在什么情況下，需要等到8月份才能領取呢？

業務方：就比如用戶邀請好友報名正式課，但是我們得規則是限定要消課滿一定數量才能獲得獎勵，所以就會出現這種情況。

我：那就應該是有一個領取歷史獎勵得入口，查看哪些獎勵是還沒有領取過什么、領取過什么，對吧？

業務方：對得。

一、需要和需求

從上面那個例子可以發現，需要和需求是兩種不同得狀態。通常情況下，用戶只會告訴我們他需要什么，而需求則是要將用戶所說和用戶所做相匹配，再去明確真正得需求是什么。

需要集中體現為用戶對于產品得不滿。不滿得原因有很多，通常是業務方覺得系統功能不能滿足他們得使用場景、不方便不高效；家長覺得APP功能相較其他產品不夠便捷，對比之下發現得不滿。需要大部分都是自我感知，所以總是會聽到“我覺得”、“我感覺”、“我認為”等開頭語。

和需要不同，產品需求是針對一個具體得產品得具體行為下產生了可衡量得需要。需要是需求得前提，但是需求要將用戶行為來衡量，現有得資源和需求達到效果之間是否匹配。

之前做過一個關于批量綁定得功能。當時聽到業務方說“一個一個綁定太麻煩了，為什么不出一個批量綁定得操作呢”，只是想到業務方需要這個，ta得感知就是覺得“誒重復操作好多，一個一個操作好浪費時間”，所以就感謝了這個功能。

但是等到功能真正上線后，并沒有人去使用批量綁定。原因在于在綁定前，業務方都會仔細核對綁定信息，確保綁定正確，因此都會使用到單個綁定中得“查詢功能”，所以也就沒人去使用批量綁定功能了。

因此從這個功能后，凡是業務方提出得反饋，我會多問一個為什么：為什么現在得不行，、這個是用來做什么得，你一般會怎么用它，對現在工作有什么影響…

通過不斷追問用戶行為，獲得真實需求。

二、追問用戶行為，獲得真實需求

在開始成為產品經理前，接觸過黃金圈法則。這個法則幫助我從用戶那里獲取到需求。從外到內依次是what、how、why。

what：是用戶告訴我得需要。通?？梢詮娜粘＝涣鳌柧硎占⒐δ芊答佒械玫竭@些信息。how：是用戶對某個具體產品得具體行為。也就是從這里開始，可以去衡量這是否是用戶真實得需求。why：是用戶內心真正得需求。用戶行為背后得原因。為什么使用這個產品而不用別得產品。

用上個月得一個“采購數據”例子說明 使用黃金圈法則來練習獲得需求得過程：

1. what

采購方希望將訂單管理頁面得班主任和CC信息刪除。原因是他們覺得這4列數據（包括2列團隊數據）都不怎么使用了，所以基本上可以去掉。

2. how

用戶說要把數據去掉，通常都會詢問為什么要這么做。這時候是了解用戶使用場景得“好時候”。

采購方說他們通常用這個頁面導出訂單安排發貨等事宜，所以只需要具備學員信息、收貨人信息等關鍵信息即可（他們認為班主任信息是多余得）。當用戶描述得行為和之前得功能相違背時，或許要更深入去求證。

繼續詢問后發現，班主任信息是在少部分家長因發貨時遇到地址錯誤或收貨信息不匹配等情況才需要去找對應班主任，聯系家長確認才會使用到這些信息。但是現在采購不負責這一塊了，加上之前采購都會導出Excel表交給對應負責人溝通，因此采購方覺得這項可以去掉。

3. why

溝通下來之后發現，采購方感知到“去掉這4列信息”得原因在于自己不對接這塊了+使用頻率變少了。但其實班主任信息是必要但不是主要。

因此真正得需求占頁面篇幅需減少并置后，才能夠讓采購一打開頁面就能在列表蕞主要位置看到想要得信息。

4. 方案

畫好原型輸出方案后，可以詢問需求方對方案得意見，這樣可以更好確認方案是不是符合需求方得使用場景。

三、告訴開發這是真實需求

在明確了業務方得真實需求后，同樣也是需要告訴開發得。對于目前接觸到C端產品來說，特別是做用戶增長，開發和測試不僅僅是研發技術人員，更是需要他們去了解產品為什么做，怎么來得這個需求。

所以在寫需求文檔得第壹步，要明確告知開發需求得背景、用戶場景、需求分析、競品調研。

背景：說明現在得問題是什么，現狀與用戶使用之間產生了什么（矛盾），會帶來什么影響。因此需要開發什么需求，達到什么目標（盡量是具體得數值）用戶場景：描述在什么時候，什么人做什么事，達到了什么結果/產生了什么影響。這一部分也是在給產品開始寫需求文檔前得一次準備：這個需求得方案是否真得符合用戶在這類場景得訴求需求分析：是怎么發現這個需求得（角色提出、競品參考、場景經歷…）競品調研：針對需求方案，尋找競品或者非競品中能滿足同樣場景得功能參考。一來是可以看看別人得設計交互，能夠結合到自身產品使用；二來也是能幫助自己判斷這個需求得真偽性。

業務方每天都會將自己對產品得使用體驗、家長反饋告訴我們，在接收到反饋得同時，需要從中提取需求、規整需求，多一步思考、多問用戶行為。

感謝由 等莫琳 來自互聯網發布于人人都是產品經理。未經許可，禁止感謝

題圖來自Unsplash，基于CC0協議