通過這個復盤框架，可以有效的幫我們梳理清楚當時需求提出的背景、依據、執行的大致過程，以及是哪個環節的問題導致了失敗的結果，從而使我們不斷的反觀自我，從失敗的經驗中快速總結與提升。

前段時間讀孫陶然的書，其中提到的一個觀點我挺贊同的：

人的學習途徑有三種：一是向書本學習，二是向先進學習，三是向復盤學習，而向復盤學習也是最為重要的。

所以我逼迫自己養成了一個習慣：階段性的對過往的產品需求進行復盤。

不復盤不要緊，一復盤嚇一跳，在我對近四個月的產品需求進行系統性的復盤后，我發現自己所做的需求中有38%屬于失敗需求（對數據產生了負面的影響），有31%的需求屬于中性需求（對數據并未構成明顯影響），而另外31%的需求屬于正向需求（對數據有積極影響）。

這其中有我的原因，也有公司的原因（部分失敗需求是被迫提上線的），但歸根到底是我的原因。當然這不是今天我要說的重點，今天的重點是和小伙伴們分享一下這次復盤時我所用到的思考框架，希望對大家有所幫助。

通過這個復盤框架，可以有效的幫我們梳理清楚當時需求提出的背景、依據、執行的大致過程，以及是哪個環節的問題導致了失敗的結果，從而使我們不斷的反觀自我，從失敗的經驗中快速總結與提升（要知道這些可都是血淋淋的代價）。

一、需求提出方是誰？

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

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

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

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

在這次復盤的過程中，我發現一個失敗的需求：社群功能。

這個需求當初就是由推廣團隊提出并且堅持要做的，需求討論的時候，我和推廣團隊之間還發生了巨大的分歧，但是誰也沒能說明誰，最后只有妥協以MVP的方式去進行嘗試。結果耗了一個月的開發資源去做，上線后轉化率和付費率都是極低的。

以至于這件事情過后，我立了一個規矩：所有的需求都必須有明確的需求依據，缺乏明確依據的需求一概拒收。

二、需求的依據是什么？

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

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

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

在我對需求進行復盤的過程中，我發現失敗的需求大多有個特點：有著極強的個人主觀經驗判斷，而缺乏嚴謹的數據分析和用戶調研。大多時候是由什么內部的“決策層頭腦風暴”之后提出的，嚴重缺乏數據的依據和用戶的反饋。這是非常值得我以后警惕的。

三、需求的目的是什么？

• 提升產品核心數據？
• 優化產品核心體驗？
• 測試新的用戶需求？
• 修復重大產品問題？

復盤需求的目的其實是對我自己的一種反思，我發現自己存在這樣的習慣：緊跟著版本節奏，快速的推進產品的迭代，然而迭代之后具體的數據追蹤和結果跟進工作卻做的比較少。

事后我反思：發現自己做一個需求的時候，目的是比較模糊的，所以導致數據追蹤和結果根據方面并沒有思考太多。

對于需求目的進行復盤也就是幫助我們梳理清楚以下幾個問題：需求的目的是否清晰？結果是否達到了我們的目的？

從而也幫助我們檢討自己，是否在后續產品設計中，加入了很多與產品目標無關的需求。

四、需求的類型是什么（KANO模型）？

• 基本需求？
• 期望需求？
• 興奮需求？

在做產品時間長了之后，我越來越發現：明確產品的發展階段很重要！清晰自己這個階段什么能做、什么不能做很重要！

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

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

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

五、需求的影響范圍？

• 個別用戶；
• 新手用戶；
• 輕度用戶；
• 重度用戶；
• 全部用戶。

復盤需求的影響范圍有助于我們在以后提出需求的時候，更加謹慎、思考的更加全面，影響范圍較大的時候，我們更多應當采用AB測試的方式，或者先上馬甲包，等數據穩定后再做判斷。

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

六、評估的過程是怎么樣的？

• 是否經過了充分討論？
• 當時的團隊整體意見是一致的嗎？
• 是否對風險進行了充分的預判？
• 當時團隊的決策是正確的還是錯的？
• 為什么團隊會做出錯誤的決策？

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

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

• 一是團隊決策的時候責任是分散的，所以會一定程度上為了追求團隊和諧而導致中庸意見占據上風；
• 二是因為很多問題需要的不是集思廣益，而是極其深度的思考，由于團隊將責任分散了，所以在思考的深度上不一定比一個人強。

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

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

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

七、是否遵循了MVP原則？

MVP原則被我單獨提出來復盤，是根據我們公司情況來的——在我們公司，產品的設計和交互被提到了前所未有的高度，是人是鬼都想跟我在產品細節上較真一番。

但是做產品的人都知道，在產品發展的初期，交互和設計對產品本身的影響是比很小的。從“用戶體驗要素”的層面講，設計和交互都屬于產品表現層的東西，影響也是有限的。

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

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

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

八、實際的結果如何？

• 正向影響：產品數據得到提升、用戶體驗提升……
• 負向影響：產品數據下滑、用戶體驗變差……
• 中性影響：短期數據并未有明顯變化、但長遠可能提升……
• 其他

這次我復盤的實際結果上面也講到了：過往四個月的需求中，38%屬于失敗需求（對數據產生了負面的影響），有31%的需求屬于中性需求（對數據并未構成明顯影響），而另外31%的需求屬于正向需求（對數據有積極影響）。這其中有我的原因，也有團隊的原因，但歸根到底還是我的原因。

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

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

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

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

九、從這次失敗需求中得出的經驗與教訓？

這一條其實是給我們自己寫的，我越來越發現：工作中出現的絕大多數問題，都是由于我們的不夠強大導致的，這種強大包含了能力、心態、認知等等方面。

每當我的能力提升一個臺階，我都會發現以前困擾著自己的那些問題，煩惱都會消散一部分。

而如何做到持續的提升？

又回到了文章開頭的那三句話：向書本學習、向先進學習、向復盤學習！

希望這個復盤框架對小伙伴們有幫助！

#專欄作家#

旺仔九號，人人都是產品經理專欄作家。心理學碩士，一名奮斗中的產品汪，致力于將心理學與互聯網進行深度整合。

本文原創發布于人人都是產品經理。未經許可，禁止轉載。

題圖來自Unsplash，基于CC0協議