這幾年隨著產品經理氾濫，還有乙個被說爛的詞，「需求」。很不幸，我也加入到這個神化的行當，每天需求中來，需求中去。
程式設計師問：「為什麼加入這功能?」答：使用者「需求」啊!
老闆問：「這個功能一定要加嗎?」答：得加!使用者「需求」，他們都需要!
客服人員：這是使用者「需求」，都說了很久了，下個版本得加上!
一下子，彷彿不說需求，產品經理就沒法當了。伴隨著「需求」，還有許多詞，如使用者需求、產品需求、強需求、弱需求等等。其實，我不禁要問：我們弄懂了這些「需求」了嗎?
先來乙個耳熟能詳的例子吧。福特汽車公司創始人亨利·福特說：如果在汽車時代早期詢問客戶有何需求，很多人可能都會回答說「要一匹跑得更快的馬」。使用者壓根不知道自己需要什麼，直到你把它擺在他面前，賈伯斯如是說。
需求是什麼?一匹更快的馬?使用者都需要呢。還是一輛汽車?畢竟使用者都很喜歡。需求到底是什麼?此時此刻，我想增加乙個名詞，就叫做「使用者期望」。其實現在很多產品人員裡嚷著的更像是「期望」，而不是「需求」。先回到這個例子上，由於使用者基於他們的閱歷與認識，他們習慣把自己的需求套到現實中可實現的方法或物質中。所以，回答一匹跑得更快的馬，並不意味著這就是他們的需求。需求可能不被察覺，經過大腦翻譯然後輸出，成了被我們理解成需求的期望。而這裡就是那匹更快的馬。逆著翻譯，我們也不難得到他們的需求是「速度更快的代步工具」。
使用者需求找到了，但是福特並沒有給他們一匹更快的馬，而是一輛福特汽車。而這輛汽車，我們稱為「產品需求」。產品需求是什麼?與使用者需求又有什麼關係?首先，產品需求在我看來，實際上是基於使用者需求，結合產品形態，企業戰略的需求。使用者需求是底層，是內包含的。實現產品需求，實際上也在實現著某些使用者需求，是使用者需求的進一步提煉。
上圖是《使用者體驗的要素》中的提到的經典模型，而戰略層實際上我們就可以理解成產品需求，是**(產品)目標與使用者需求的融合。
好了，我們再梳理一下：
當使用者提出很多意見時，往往夾著他們給這個問題的定性與解決方案。所以我們往往聽到的是你這裡加個xx按鈕，你這不行得這樣才行。其實就像使用者使用產品只是想完成他們的任務，而不是來體驗的一樣。他們給你提各種期望也僅僅是為了更好的完成任務。所以我們需要對這些期望過濾，得到使用者的需求。然後再結合自身得到產品的需求，最終迭代到產品。
但是道理很簡單，但是說時容易做時難，很多人聽到使用者的聲音，便已經定性為使用者需求，或許他也知道需要過濾，然而在潛移默化中卻成了真的使用者需求。有時候不是不知道，而是混了。所以我更傾向於用「使用者期望」這個詞，與需求區分，也更加貼切。
下面再補充兩小點：
期望很多，該聽誰的?
讓我回答的話，忘掉專家使用者的話吧，專家包括xx觀察者、分析師、同行、同事，因為他們不是主流使用者。主流使用者只是想完成他們的任務，而專家是吹毛求疵。過分相信專家注定與主流擦肩。
產品需求與盈利
記住，商業化其實並沒有什麼不好，只要滿足一定使用者需求的前提下。任何不以盈利為目的的企業都是耍流氓。盈利沒什麼可丟人的，只有盈利，才能更好的服務，這是乙個閉環。切斷了，最後就只會獨木難支而死掉。產品需求或許就可以被理解為使用者需求與商業化的平衡需求。
產品需求背後的使用者動機
ucd 以使用者為中心的設計 方法可以說是當前產品構建時，最流行的一種設計思想。這種方法的核心思路是 使用者知道自己想要什麼。使用者知道自己為什麼使用一款產品 很清楚自己想要的功能是什麼 自己已有偏好的使用習慣，在進行產品開發時，應該將使用者的參與納入到開發的每乙個階段。圍繞使用者的需求來進行產品的...
產品經理如何了解使用者的需求？
今天特別想跟大家聊聊需求這件 小事 人人都是產品經理這句話說得不無道理，無論你從事哪個行業，都會提到 使用者需求 這個詞 尤其是對網際網路產品經理來說，需求是一切之始，先有了需求，才有了產品經理的一切職責的發揮空間，如果沒有需求，一切都無從談起，產品經理這個職位也就沒有了存在的價值。作為產品經理的你...
TUP 分享產品背後的技術和使用者體驗
上期程式設計師雜誌做了 網際網路產品十年 的特別報道，本期又推出tup專欄，csdn的線下活動也已冠以tup,tup是技術 technology 使用者體驗 user experience 產品 product 英文的簡寫，tup宗旨是分享產品背後的技術和使用者體驗故事.為什麼要提出這樣的口號，我想...