這是我的親身經歷。
故事從一位「經驗豐富」的PM開始。他到職做的第一件事，就是把老闆的功能清單分成Phase 1、Phase 2 ......，美其名叫「MVP」。 當有人問他為什麼要做這個功能，或者這個功能要解決什麼問題時，往往只會說「這是老闆要的」。
PM的邏輯很簡單：相似的競品有這功能，所以我們也要有。結果是花了三個月做登入系統，團隊卻不知道產品要提供什麼核心價值。
為什麼這種情況這麼普遍？
這種「分期付款式」的開發模式在新創圈層出不窮。許多團隊相信他們在做MVP，但連什麼是該提供的基本價值都難以定義。 更麻煩的是，這會影響整個團隊心態，大家開始用「這是MVP版本」來合理化粗糙的產出。
接觸過多個團隊後發現，很多會議討論的「MVP規劃」，實際上只是在排工作優先順序。 我曾經參與過的一個案例，團隊一年燒掉幾百萬，最後只做出一個串接各種API的基礎網站。 最諷刺的是，後來在Github上發現幾乎一模一樣的開源專案。
背後的真實原因
「功能切割」很安全。 進度看起來有在推進，報告可以按時繳交，成本控制也有在做。 但這樣的結果是，市場驗證成本越來越高，因為團隊把大量時間花在被切割出來的功能清單上。
這裡有個關鍵問題：當你的開發流程變成功能分期付款時，團隊失去了快速試錯和學習的能力。每個功能都變成「必須完成的任務」，而不是「需要驗證的假設」。
真正的MVP應該具備什麼？
真正的MVP需要有明確的核心價值假設，所有的開發計畫都圍繞著驗證這個假設來設計。 換句話說，團隊成員應該能隨時回答：「這次的改動要驗證什麼假設？會提供什麼價值給使用者？」
診斷你的MVP是否走偏的三個問題：
- 團隊能清楚說出要驗證的核心價值假設嗎？
- 對目標用戶的描述是具體的，還是想像的？
- 如果這個假設被證明是錯的，團隊有勇氣重新開始嗎？
如果答案是模糊的，那很可能還在做功能分期付款，而不是真正的產品驗證。
值得深思的地方
真正的MVP可能會失敗。
這需要團隊承認錯誤、理解錯誤，並重新開始的勇氣。但這種失敗是有價值的，因為它能快速告訴你什麼方向是錯的。 相反地，功能分期付款式的開發很少會「失敗」，但也很少會成功。它只會讓你在錯誤的道路上走得很穩，直到錢燒完才發現走錯了方向。
這種現象為什麼會持續存在？ 因為它給了所有人一種「我們在做正確的事」的錯覺。 PM有進度可以報告，工程師有明確的任務可以執行，老闆看到產品在「成長」。 但市場不會因為你的功能完不完整就買單。市場只關心你幫我解決了什麼問題。
你在團隊中觀察到類似的模式嗎？或者你有其他避免這種陷阱的方法？歡迎分享你的經驗。