1、試圖滿足各種“用戶需求”，最後發現衆口難調。往往在細小的、具體的功能上，我們很在意“用戶需求”。用戶說出來的要求通常是不繫統的，是想起啥就要啥。如果產品的設計者只是簡單的按用戶的要求去做產品，那麼後果是…“隱身，對其隱身，隱身對其可見…”按照這種“惟用戶需求是從”的方式做一陣子，設計者往往會感嘆衆口難調，於是很容易陷入另外一種錯誤中…
2、認爲用戶其實不知道自己想要什麼
“如果我問我的用戶，他們只會說要一匹更快的馬。”—亨利•福特
“如果只按用戶需求來做，永遠也不會有walkman。”—很多講產品策劃的老師都這麼說
在這個標榜“用戶價值”的時代裏，誰一張嘴都是“用戶有這樣的需求…”“…這是用戶需求啊~”或許過分嘲諷類似的說法並沒有什麼積極的意義，產生這樣的說法還是因爲我們並沒意識到濫用“用戶需求”概念的害處。
因此用戶的需求到底是什麼就需要“用戶需求分析”，所謂"需求分析"，是指對要解決的問題進行詳細的分析，弄清楚問題的要求，包括需要輸入什麼數據，要得到什麼結果，最後應輸出什麼。可以說，在軟件工程當中的“需求分析”就是確定要計算機“做什麼”，這就是用戶故事。 可以工作的軟件能夠更好、更真實的反應項目進度狀況。精力和智力所限，人天生只能關注很小的部分。
因此用戶的需求到底是什麼就需要“用戶需求分析”，所謂"需求分析"，是指對要解決的問題進行詳細的分析，弄清楚問題的要求，包括需要輸入什麼數據，要得到什麼結果，最後應輸出什麼。可以說，在軟件工程當中的“需求分析”就是確定要計算機“做什麼”，這就是用戶故事。 可以工作的軟件能夠更好、更真實的反應項目進度狀況。精力和智力所限，人天生只能關注很小的部分。
根據排隊原理，用戶故事的不確定性是導致系統開發週期非線性膨脹的主要因素。不確定因素主要有：不確定的迭代長度，不確定的用戶故事集合，用戶故事大小差距很大，團隊成員不固定發佈時間，不固定新的需求到達時間。解決的方案就是讓一切變得確定，穩定。需要把大的任務切成類似大小的小的用戶故事。這樣就大大減小了不確定性，提高了效率。
每個小功能的完成都是一個反饋點，可以及時溝通信息。大塊需求導致很多需求的缺陷往往在最終測試的時候才發現的，如果不能及早完成，儘快測試，缺陷會越來越難以解決。軟件很少一次就做好，多次反饋以及不斷演進纔是一個真正能把功能做好的策略。溝通更加及時，有問題可以及時發現，立刻解決，而不需要過長時間的等待。
使用用戶故事，也讓需求變得簡單、明瞭，一次很容易讓不同人同時去完成。