需求的重要性續集

這裏是IT修真院產品分享課，今天要分享的是

【需求的重要性續集】

1、需求提出方是誰？

• 產品？
• 運營？
• 推廣？
• 技術？
• 老闆？

不少時候需求的提出方可能並非咱們本身，是由他人提出的。記錄需求的提出方是誰有助於咱們從新梳理當時的決策過程，若是提出的是失敗需求，就算不是咱們本身。

那麼也應當思考：爲何本身沒有阻攔此次需求，反而是讓失敗的需求順利的上了線？當時若是提出了質疑，爲何咱們沒有繼續說服別人？若是是咱們本身提出的，就更應當反思了，當時在作出決策的時候是哪一個方面的緣由使咱們產生了誤判？這種誤判是本身的思惟習慣仍是思惟漏洞？

這些都是值得咱們深入反思的。

全部的需求都必須有明確的需求依據，缺少明確依據的需求一律拒收。

2、需求的依據是什麼？

• 數據分析的結果？
• 用戶調研的結果？
• 競品分析的結果？
• 我的的經驗判斷？

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

用戶調研每每也須要耗費必定的時間和精力，須要蒐集必定量的用戶數據後通過分析才能得出一些初步的結論。而競品分析相對不是很靠譜，在不少人理解起來就是競爭對手作撒，咱們跟着作就行了。而我的經驗是最簡單的，也是最不靠譜的，全憑我的的感受和判斷，也就是純粹的我的YY。

失敗的需求大多有個特色：有着極強的我的主觀經驗判斷，而缺少嚴謹的數據分析和用戶調研。大多時候是由什麼內部的「決策層頭腦風暴」以後提出的，嚴重缺少數據的依據和用戶的反饋。

3、需求的類型是什麼（KANO模型）？

• 基本需求？

• 指望需求？

• 興奮需求？

明確產品的發展階段很重要！清晰本身這個階段什麼能作、什麼不能作很重要！

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

可是若是把這個創意放在KANO模型中思考一番後，咱們發現產品當前還處於需求驗證階段，最核心的任務是驗證需求的真僞，而本身想出來的不少創意每每只是一種興奮需求——有了更好，沒有也影響不大。

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

4、需求的影響範圍？

• 個別用戶
• 新手用戶
• 輕度用戶
• 重度用戶
• 所有用戶

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

好比：當時我在正式包上直接上線了一個「付費功能」後，致使新用戶的註冊轉化率受到不小影響，進而影響到了產品在App Store的排名，這些都是被我事前低估的，好在我預先準備了備選方案，在出現問題後第一時間更換爲了備選方案。

5、評估的過程是怎麼樣的？

• 是否通過了充分討論？
• 當時的團隊總體意見是一致的嗎？
• 是否對風險進行了充分的預判？
• 當時團隊的決策是正確的仍是錯的？
• 爲何團隊會作出錯誤的決策？

作產品時間長了以後，我觀察出來一個現象：團隊的決策不少時候不必定比我的決策更明智，團隊的決策反而會提高失敗的機率。

背後的緣由大概有兩個方面：

一、團隊決策的時候責任是分散的，因此會必定程度上爲了追求團隊和諧而致使中庸意見佔據上風；

二、由於不少問題須要的不是集思廣益，而是極其深度的思考，因爲團隊將責任分散了，因此在思考的深度上不必定比一我的強。

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

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

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

6、是否遵循了MVP原則？

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

可是由於設計和交互是千人千面的，人人都能說上幾句的，因此才被那些「不懂行的人」給予了太多的關注。覆盤和檢討咱們是否遵循了MVP原則，有利於團隊將整個注意力和重點，放在覈心需求的驗證上，而非千人千面的設計和交互上。

這其實也是對團隊成員在知識層面進行不斷降維打擊的作法——不少人都認爲本身特懂產品，擁有最好的想法。這個時候咱們要作的不是和對方爭吵，而是用數據和結果去證實對方爲何是錯的，錯在哪裏。

同時，在咱們須要在知識層面上持續的輸出，提高整個團隊的產品認知——這也是產品經理爲何要持續學習的緣由，要對他人進行降維打擊，就必須保證本身的思考和認知可以持續性的引領團隊。

7、實際的結果如何？

• 正向影響：產品數據獲得提高、用戶體驗提高……
• 負向影響：產品數據下滑、用戶體驗變差……
• 中性影響：短時間數據並未有明顯變化、但長遠可能提高……
• 其餘

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

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

從而在之後的產品迭代中，儘量的作出最正確的決策。

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

【更多內容，歡迎加入交流羣565763832與你們一塊兒討論交流】

【這裏是技能樹·IT修真院：IT修真院官網，初學者轉行到互聯網的彙集地】