最簡可行產品

最簡可行產品(英語:minimum viable product, MVP),是新產品開發中的名詞,是指有部份機能,恰好可以讓設計者表達其核心設計概念的產品。設計者可以進行驗證式學習英語validated learning,根據使用者的回饋,進一步了解使用情形,並且繼續開發此產品 [1]。由最簡可行產品來搜集相關想法常常會比開發有更多機能的產品要便宜。開發更多機能產品的的費用較高,也會有產品失敗的風險(例如產品基本假設有誤的情形)。最簡可行產品一詞是由法蘭克·羅賓生(Frank Robinson)創建[2],因史蒂夫·布蘭克埃里克·萊斯的使用而流行[3][4][5][6]

利用最簡可行產品,也可以提早進行市場分析

說明

編輯

最簡可行產品是一個只有重要核心功能,可以提供給客戶的產品,沒有其他多餘的功能。開發者一般會將最簡可行產品提供給部份的可能客戶,例如比較容易寬容錯誤、比較願意回饋意見、可以從早期原型或是行銷資訊中找到產品願景的早期採用者英語early adopter。此一策略避免製作一個客戶不想要的產品,希望可以在相同的花費下,儘量的發掘客戶的資訊。「最簡可行產品就是一個用來在最小付出下,對客戶進行最大量驗證式學習的產品版本。」[1]。定義中的最小及最大不是公式上的,在實務上需要判斷什麼方式的最簡可行產品才是合理的。

最簡可行產品可以是直接製造及販售商品給顧客的流程及策略中的一部份[7]。最簡可行產品是概念產生、原形、演示、資料收集、分析及學習的迭代過程中的核心工具。一般會希望減少迭代過程中花的時間,迭代會進行到已達到理想的產品市場契合英語Product/market fit,或者確認產品不可行為止。

史蒂夫·布蘭克將最簡可行產品視為最簡功能集(minimum feature set)[8]

目的

編輯
  • 可以在使用最小資源的情形下確認和產品相關的假設。
  • 加速學習。
  • 減少開發設計時間的浪費。
  • 儘早讓早期客戶拿到產品。
  • 作為其他產品的基礎。
  • 建立可以產出需要產品的能力。

測試

編輯

最簡可行產品測試的結果是要確認此產品是否應進行開發。測試的目的是要確認原始問題或是目標是否有達成,使產品開發可以繼續進行。

著名的評論

編輯
  • 史蒂夫·布蘭克:「要販售願景及提供最簡可行產品給有遠見的人,不是給所有的人。」[8]

技術

編輯

最簡可行產品可以是原型、完整的產品或是產品的一部份(例如一項特徵)。

產品

編輯

網路應用程式的標準MVP策略是建立一個模仿產品的網站,並且購買線上廣告讓此網站有流量。模仿網站可以包括營銷目標網頁,其中可提供更多訊息或是可以購買的連結。可購買的連結不用連結到真正的購買系統,不過需記錄每個點擊,並評估用戶的興趣。

功能

編輯

網頁應用程式中連結到新功能的連結可以放在已有網頁的顯著位置。功能本身可能尚未完全實現,點選連結後出現模仿網頁或是行銷網頁,並說明此功能尚未完成的道歉訊息。系統會記錄此一連結的點擊,並評估客戶端對此功能需要的程度。這也稱為「早些部署,晚點編程」(deploy first, code later)的方式。

差異

編輯

釋放最簡可行產品以及評估其影響都是測試市場的策略,用來在產品產生後快速篩選產品理念。像網絡應用程序開發常用的快速應用程式開發工具也促進這一類產品的產生。

最簡可行產品和測試之前先投注時間及金錢以布署產品的傳統市場測試策略不同。最簡可行產品希望在花費金錢及時間開發產品時,先確認市場的確需要此一產品。最簡可行產品也和開放源代碼提到的儘早發布,經常發布新版本英語release early, release often不同,後者強調傾聽使用者的需求、讓使用者定義產品的功能及未來。最簡可行產品一開始就有產品的理念,在整個產品生命週期中都會維持此一理念,不過會根據未來潛在客戶對產品直接及間接的回饋來調整產品理念[9]

最簡可行產品是布蘭克出的「客戶開發」方法論中的一部份,主要專注於持續性的產品開發迭代過程,根據客戶的回饋來精進產品。另外,展示還不存在的產品及機能也可以用網路為基礎的假設檢定來進行,例如A/B測試

商業模式圖

編輯

商業模式圖可用來標示新創公司的主要成份及活動。可以用商業模式圖中的一些元素來設計最簡可行產品:[10]

參考資料

編輯
  1. ^ 1.0 1.1 Ries, Eric. Minimum Viable Product: a guide. August 3, 2009 [2016-06-14]. (原始內容存檔於2019-02-17). 
  2. ^ SyncDev methodology. SyncDev. [May 16, 2016]. (原始內容存檔於2019-02-18). 
  3. ^ W. S. Junk, "The Dynamic Balance Between Cost, Schedule, Features, and Quality in Software Development Projects頁面存檔備份,存於網際網路檔案館)", Computer Science Dept., University of Idaho, SEPM-001, April 2000.
  4. ^ Eric Ries, March 23, 2009, Venture Hacks interview: "What is the minimum viable product?"頁面存檔備份,存於網際網路檔案館), Lessons Learned
  5. ^ Perfection By Subtraction – The Minimum Feature Set. [2016-06-14]. (原始內容存檔於2021-03-07). 
  6. ^ Holiday, Ryan The single worst marketing decision you can make頁面存檔備份,存於網際網路檔案館The Next Web. 1 April 2015
  7. ^ Radoff, Jon. Minimum Viable Product rant. Jon Radoff's Internet Wonderland. May 4, 2010 [19 August 2014]. (原始內容存檔於2014-03-23). 
  8. ^ 8.0 8.1 Blank, Steve. Perfection By Subtraction – The Minimum Feature Set. March 4, 2010 [2016-06-14]. (原始內容存檔於2021-03-07). 
  9. ^ Ries, Eric. Lessons Learned: Minimum Viable Product: A Guide, Lessons Learned. August 3, 2009 [January 28, 2013]. (原始內容存檔於2013-01-29). 
  10. ^ Kromer, Tristan. The Four Parts of a Minimal Viable Product. April 15, 2014 [2016-06-15]. (原始內容存檔於2015-07-22). 

相關條目

編輯

外部連結

編輯