必讀｜關於用戶需求，你不知道的11個真相

只有當自己知道需要什麼的時候，才有可能會獲得它，這也是探索需求的必要性。

我們常常談需求，但是需求真的是我們想像的那樣嗎？下面我就給大家梳理一下，關於需求你可能誤解了的11個真相。

1. 寫需求其實並非是在談需求。

需求活動主要不是編寫需求文檔，相反，它專註於理解業務問題，並為之提供解決方案。

怎麼樣才算理解了業務問題呢？

即你做的是哪個行業的產品，就對這個行業的商業模式、產業鏈、競爭狀態等要有所了解。而只有深入了解了業務本身，才有助於發現使用場景，並為之提供解決方案，讓用戶用得爽。

2. 如果我們必須構建產品，那麼它必須為擁有它的人提供最理想的價值。

除非產品提供了利益，否則擁有產品者不會付錢

作為產品開發者或設計者，要深諳一點：即我們關注最終結果的擁有者，只是間接地關注用戶。但是在免費時代，很多公司並不靠產品本身盈利，所以不能孤立地看這個上圖中的曲線，應當將整個產品生態搭建起來，看看哪個環節是贏利點。

很多大公司，平台級的產品均是不盈利的，通過專心打磨產品獲取千萬級的用戶，然後通過其他方式進行盈利，例如在線廣告、增值服務或電商。

3. 你必須知道要求是什麼，才能構建正確的產品。

要理解產品打算為用戶完成什麼，以怎樣的方式完成，就必須理解擁有者的業務工作。產品經理得到需求，描述產品的功能（做什麼）以及產品的屬性（做到什麼程度）。

不幸地是，交流的無奈導致需求並非總是被恰如其分地理解了。

4. 構建一個產品和解決一個業務問題之間，存在巨大的差別。前者不一定實現後者。

這一點是對第一點的補充。做一個產品就是為了解決一個業務問題，因此開發工作必須從問題開始，而不是從解決方案開始。

5. 需求不一定要寫下來，但是構建者必須知道它們。

需求文檔是為了更好的溝通想法，一份高效準確的需求文檔能夠讓開發人員和設計人員非常明確需求是什麼，從而實現它。但很多時候，口頭溝通更方便、直接，特別是一些細節的確認，往往需要口頭表達。

但值得注意的是，口頭溝通需求效率雖然高，但是不是所有需求都能用這種方式來溝通。編寫需求是為了讓利益相關者和產品經理徹底地理解需求，也有利於追蹤文檔。

6. 客戶不一定能給你正確答案，有時候他也不知道要什麼。

利益相關者在描述一個需求時是由困難的，交流的無奈是存在的。所以產品經理應該把握業務的複雜性和規模。

有時候，產品經理應該如實記錄下客戶的要求；有時候，應該從解決方案中導出需求，有時候必須提出創新，得到更好的解決方案。

7. 需求不是偶然得到的，要通過某種有序的過程得到。

做產品就像拍電影，要先有一個劇本，確保劇情有序地發生。

任務的次序、重點和應用程度需要採用該過程的人或團隊來決定，參與這個過程的人必須能看到為什麼不同的任務是重要的、哪些任務對項目最重要。但優先順序是可以調整的，過程中要靈活變通。

8. 怎麼迭代都行，只要理解了業務的需求。

敏捷迭代越來越成為新寵，取代著原始的瀑布流開發方法。但是冷靜的頭腦在開發之前已經將需求過程吸收到開發的生命周期中了。

聰明的辦法不是廢除需求，而是從一個不同的方向接近需求。真正值得關注的是，既要發現需求，又不必編寫無用的、不成熟的文檔。

9. 所有的方法和工具都無法彌補糟糕的想法和糟糕的手藝。

這一點是對第7點和第8點的補充。

有序的過程並不能替代思考。需求收集、驗證、編寫文檔的過程並不是一種流程，而是由提交的產物驅動的。

要記住，自動化的工具只是輔助手段，產品經理最重要的工具就是：腦袋、眼睛和耳朵。

10. 要想成功地實現需求，需求就必須可度量、可測試。

需求可以主要分為以下三類：

功能需求：產品支持其擁有者的業務時必須做的事情。

非功能需求：產品要再擁有者的環境中取得成功，必須將功能完成得多好的量化描述。

限制條件：全局性的需求。

例如，產品有一個需求是「應該對新用戶有吸引力」：

建立可測量的指標即：註冊時間少於2分鐘、數據項（例如姓名、郵件地址等）猶豫時間不超過5秒。

可以很肯定地說，如果你不能為需求找到測量指標，那麼它就不是需求，只是一種無根據的想法。

11. 作為產品經理，你終將改變用戶思考這個問題的方式。

產品經理的部分工作就是幫助人們儘早理解和質疑他們的需求，這樣他們就可以幫助你發現它們真正的需求。

當產品經理開始理解需求時，尤其是在需求來自於不同利益相關者時，就開始建立起一套抽象概念，通過展示業務過程的模型漸漸參透工作的本質，得到清晰、可測量的需求，並把這些反饋給利益相關者。

在做這些事情的時候，產品經理就在漸漸改進（改變）他們對業務的看法。

簡言之，需求就是產品支持其擁有者的業務所必須完成的事。而產品經理的工作就是理解需求，理解到應該做什麼、做到什麼程度，並建立起一套解決問題的方案，反饋給產生需求的人。

推薦閱讀：