需求的重要性續集

這裡是it修真院產品分享課，今天要分享的是

【需求的重要性續集】

很多時候需求的提出方可能並不是我們自己，是由他人提出的。記錄需求的提出方是誰有助於我們重新梳理當時的決策過程，如果提出的是失敗需求，就算不是我們自己。

那麼也應當思考：為什麼自己沒有阻攔這次需求，反而是讓失敗的需求順利的上了線？當時如果提出了質疑，為什麼我們沒有繼續說服別人？如果是我們自己提出的，就更應當反思了，當時在做出決策的時候是哪個方面的原因使我們產生了誤判？這種誤判是自己的思維習慣還是思維漏洞？

這些都是值得我們深刻反思的。

所有的需求都必須有明確的需求依據，缺乏明確依據的需求一概拒收。

從上面四個依據中，不難發現：資料分析的依據是最難的，需要對需求的詳細分解和推斷之後才能給出結論，並且產品上線後也需要持續的觀察資料的變化，以判斷產品的改動是否符合預期。

使用者調研往往也需要耗費一定的時間和精力，需要蒐集一定量的使用者資料後經過分析才能得出一些初步的結論。而競品分析相對不是很靠譜，在很多人理解起來就是競爭對手做撒，我們跟著做就好了。而個人經驗是最簡單的，也是最不靠譜的，全憑個人的感覺和判斷，也就是純粹的個人yy。

失敗的需求大多有個特點：有著極強的個人主觀經驗判斷，而缺乏嚴謹的資料分析和使用者調研。大多時候是由什麼內部的「決策層頭腦風暴」之後提出的，嚴重缺乏資料的依據和使用者的反饋。

明確產品的發展階段很重要！清晰自己這個階段什麼能做、什麼不能做很重要！

我們都知道產品是有生命週期的，不同階段產品的側重點也是不一樣的。我們也都有這樣的經歷：在做產品的時候突然的靈光一現，想出乙個極好的創意，興奮的不行。

但是如果把這個創意放在kano模型中思考一番後，我們發現產品當前還處於需求驗證階段，最核心的任務是驗證需求的真偽，而自己想出來的很多創意往往只是一種興奮需求——有了更好，沒有也影響不大。

用kano模型進行分析的主要目的是——讓團隊能夠更加的聚焦：將產品的重點放在核心的需求上，而非過於發散的提出一些所謂的「奇思妙想」，雖然這些奇思妙想在某些時候的確很重要，但是大多數時候，我們還是要著眼於產品當前階段的核心任務，腳踏實地。

我們在以後提出需求的時候，更加謹慎、思考的更加全面，影響範圍較大的時候，我們更多應當採用ab測試的方式，或者先上馬甲包，等資料穩定後再做判斷。

做產品時間長了之後，我觀察出來乙個現象：團隊的決策很多時候不一定比個人決策更明智，團隊的決策反而會提公升失敗的概率。

背後的原因大概有兩個方面：

1、團隊決策的時候責任是分散的，所以會一定程度上為了追求團隊和諧而導致中庸意見佔據上風；

2、因為很多問題需要的不是集思廣益，而是極其深度的思考，由於團隊將責任分散了，所以在思考的深度上不一定比乙個人強。

評估的過程，其實就是加深我們對團隊的認知和理解——團隊整體的氛圍是怎樣的？團隊成員是否都有表達觀點的機會？團隊的意見是否會被個別人左右？團隊的決策是更明智的還是更中庸的？等等。

「評估過程」之後，你會發現：每次產品的需求討論會議，都經常被決策層的個別人員所左右，導致其他部門的人難以有太多表達意見的機會，這次我索性直接將需求討論會議進行了拆分。

和決策層進行戰略討論會議，和執行層進行需求評審會議——這是非常奇葩、非常有公司特色的，但是效果卻出人意外的好！很多平常基本上不說話的開發小哥哥，在這種調整之後也有了表達意見的機會。

做產品的人都知道，在產品發展的初期，互動和設計對產品本身的影響是比很小的。從「使用者體驗要素」的層面講，設計和互動都屬於產品表現層的東西，影響也是有限的。

但是因為設計和互動是千人千面的，人人都能說上幾句的，所以才被那些「不懂行的人」給予了太多的關注。覆盤和反省我們是否遵循了mvp原則，有利於團隊將整個注意力和重點，放在核心需求的驗證上，而非千人千面的設計和互動上。

這其實也是對團隊成員在知識層面進行不斷降維打擊的做法——很多人都認為自己特懂產品，擁有最好的想法。這個時候我們要做的不是和對方爭吵，而是用資料和結果去證明對方為什麼是錯的，錯在**。

同時，在我們需要在知識層面上持續的輸出，提公升整個團隊的產品認知——這也是產品經理為什麼要持續學習的原因，要對他人進行降維打擊，就必須保證自己的思考和認知能夠持續性的引領團隊。

對結果進行分析有助於整個團隊能夠更加的以結果為導向，在大部分的創業公司，大家都是狂奔的狀態，不分晝夜的提需求、趕進度、爭分奪秒，但是勤奮、忙碌與成功之間並不一定是成正比的，否則創業就成了太簡單的事情。

冷靜下來從結果的角度進行分析，有助於我們反思自己所做的事情中哪些有重要的、積極的、有價值的？哪些是不必要的、消極的、價值較低的？自己如何將時間與精力聚焦在核心的，有價值的事情上？

從而在以後的產品迭代中，盡可能的做出最正確的決策。

我們常犯的錯誤之一就是：誤把假設當結果——認為事情的發展就應該符合我們的構想和預期。但是結果會告訴我們：你的假設只是你的假設，你的構想也只是你的構想。對結果進行跟蹤、反饋和反思，是逼迫團隊更加務實。