老闆有個願景，很大的故事線，只要靠產品經理規劃成完整的藍圖，之後就可以變成一個獨立賣錢的產品…甚至為此產品成立一間新公司！故事講起來口沫橫飛，聽起來世界就是這麼美好，但，實際上真有這麼簡單嗎？身為專（流）業（言）產（終）品（結）經（者）理，就是要你驗證老闆是不是要你造一隻飛天豬。
MVP (Minimum Viable Product)，簡單來說，就是找出最核心需求，並定義最小可行產品的範疇。MVP 的目的在於驗證產品的可行、測試市場水溫，也是設定投入成本的停損點。時常想像中的長遠目標並不是需求端期待的，這時MVP做的夠徹底，轉進不會是難事。往往在上位者不會真的知道現實面的痛點，會需要佐證來客觀提出改變的方向，並非所有 MVP 都是好的產品，而且更多的情況是胎死腹中，失敗經驗遠比成功多。不過一旦發覺 MVP 得到的評價不錯（從使用者的使用頻率或是回饋），找出產品利基點，是可以進一步更深入理解需求並從中得到更高的期待。
MVP 的執行流程很重要，至少過程會幫助很大，因為產品不能太複雜，但又要能夠解決最主要的問題，所以最開始會從「定義問題」(define painpoint) 出發，針對問題，進一步「了解訴求」(desired outcome)，了解訴求後再設計「如何用最少的資源嘗試解決問題」，並「實作解法」(potential output)，最後還要再來驗證 output = outcome （有點像是心理學提到的效度驗證），是的話還要確認是否有其後續開發的價值。
提到 MVP ，無論時程或工程師的資源有限，如此限制下產品一定會有所犧牲，其中有兩個概念之間的權衡會相對重要：可用性 (Functionality) 和易用性 (Usability)，簡單來說，可用性是指你的產品功能是否具備原本預期的功能，易用性是指使用者有沒有覺得產品方便使用（Ref: Does your web to be more funtional or usable）。我認為在 MVP 階段，可用性的重要性會高於易用性，要先讓能夠解決使用者痛點的核心功能出來，進行產品驗證，才會知道有沒有下一個階段的開發，所以說在可用性階段，通常不太會要求介面要多好看或是多酷炫，功能明確簡單，操作流程清楚即可。
但要小心一點的是，絕 對 不 能 太 難 用！如果 MVP 太著重可用性，忽視了基本的易用性，例如介面上的 input 和 output 不符合期待，或是頁面跳轉出現邏輯衝突、抑或是沒有錯誤訊息的提示等。對使用者來說的「易用性」太低，進而造成使用者對於核心功能期待落空，最後導致「易用性」太低造成對「可用性」的評價過低，這是軟體產品開發最不樂見的結果。
建立 MVP 思維真的很重要，我說了三次。
很多時候，第一步「定義問題」中的問題，根本是假議題，甚至不存在（笑）
