談談用研過後的「需求」

首先在確保用研對象是目標用戶之後，用戶所提出的所有合理需求(不包括用戶提出我就是喜歡這個顏色這種)都是有活生生的使用場景支持的，肯定是用戶在使用過程中確實遇到了這樣的問題。很多時候用戶不會告訴你我遇到了什麼問題，他們不會想展示他們蠢的一面，他們只會告訴你他們想要的解決方式，然而這個解決方式並不一定是合適的或者是具有片面性的。所以在分析需求的過程中我覺得有以下幾個比較重要的點。

1.思考有多少人有這個需求。很多時候需求是具有片面性的，一些用戶提出這個需求只是出於個人習慣或者特殊場景，因為能參與用研的一般都是高玩，他們的一些需求可能並非是普通人具有的。曾經在一款社交產品中遇過加入「運動記錄」這個功能的需求，用戶在運動世界中希望有一個可以直接記錄運動數據然後直接發送到動態或者分享給朋友的功能。當時提出這個需求的是深圳跑步社團的一位運動達人，出於對身份不同的考慮我們對這個需求也會有一些疑慮，用戶到底是不是需要這樣一種功能。

在對這個需求的深入了解後發現跑步區76%是普通運動愛好者，他們並不會希望把一些不太漂亮的數據分享給別人或者炫耀，會做這種事情的一般都是一些在跑步方面的高玩可以達到一些不錯的數據，所以他們樂於去分享這些數據並感到自豪。結合了市面上一些運動產品的調研後我們發現，更多的用戶傾向於把運動消耗的卡路里量作為一種完成目標的方式作為分享，以此激勵自己等。所以在這個需求上面做成一個卡路里數的消耗並通過一些運營的手段鼓勵用戶去做這一件事情，在這個過程中可以通過高玩的需求中發現大眾需求，使需求更加具有普遍性。

2.確定一個需求的價值，看人們現在滿足它願意付出的成本有多大，我個人非常認同這個觀點。人實現任何操作都是有成本的，時間體力精力心情等等。如果一件事情在現有解決方法下需要人們消耗很大的成本才能搞定，那說明這背後隱藏著巨大的需求。以前做的一款社交產品時我負責企業版這麼一個板塊，在對接企業負責人時接到這樣一個需求，他們希望能夠在企業版加入視屏直播的功能方便大型企業會議，大型公開課的舉行。首先我們把他們的需求轉化在移動端有一種能夠方便，快速共享視頻直播的功能。

後來我提出了一個方案，在評審會的時候發現了一些技術上的難點以及帶來給用戶的不便性，首先是同步性和流量的問題，接下來是考慮到卡頓等視頻經常遇到的問題等。用戶肯定不會付出那麼大的成本去做一件體驗那麼差的事情，這樣做下去跟我們的初衷肯定是相違背的，再經過一輪的分析之後我們把需求轉化為在移動端有一種能夠滿足實時共享的方式。接下來就是後續的分析需要有什麼樣的元素組成這樣的一個條件，最後是採用了PPT+語音相結合的方式，有點類似現在紅點做的事情。在這個過程中我們把「視頻直播」轉換成了「PPT+語音」的方式，評估開發周期直接從兩個月變成了兩周半。

3.這個需求是用戶什麼樣的痛點，說白了這個實現這個需求到底能解決用戶什麼樣的問題。曾經在參與一款針對學生市場的團體旅遊產品的時候，有一次通過用研時得到一個需求：學生班長們希望能夠在出行路線的選擇上增加投票的功能，加快路線的決定。這個需求咋一眼看上去確實是非常有必要，在用戶出行的時候線路的選擇確實是比較糾結的地方，投票確實可以比較有效的解決這個問題。

但是在項目深入進行的同時我會去想 線路的選擇在出行過程中確實是個比較難選擇的問題，但是團體出遊實際上線路的選擇並不多，而且在出行天數確定的情況下基本上在沒有線路之前就會腦子裡面有概念到底是要去深圳海邊還是出市外，縮小的範圍之後像深圳海邊其實就那麼幾個地方，決定用戶會選擇出行地點的我認為更大程度上是目的地的項目有什麼是更吸引他們的。可能一部分人想去東涌是沖著野炊去的，一部分人沖著較場尾是沖著民宿去的，所以線路的選擇完全可以通過群聊的方式去解決，對項目的投票可能才是比較有價值的點。出於對投票功能工作量的評估和具體技術的實現，我決定簡化這個功能 做成一個「我想去」的板塊 每個人可以通過點贊的方式體現更想去的項目。在這個需求的過程中我把「對線路選擇進行投票」轉移成了「對想去項目點贊」這就是一個從用戶需求找出真實需求再結合項目實際轉化成適合自己產品的需求這樣一個方式。

辨別用戶真偽最主要的還是去分析需求，以上三個是在分析需求的過程中比較值得注意的點。其實這是非常有意思的問題，這也是一個產品經理最重要的價值的體現之一。上文所說的都是在用研獲得需求之後對需求的一些處理分析，不包括創造需求或者初期確定需求的一些方面。