Figma 成功之後，我們還應該相信「最小可行性產品」理論嗎？

Figma 成為最小可行性產品反例

從推出 Beta 產品到現在，Figma 以黑馬之姿創下 90% 毛利率、超過 150% 淨收入留存率（NDR）、全年持續性收入預計 4 億美元，在 SaaS 產業當中算是亮眼模範生，並只花了 7 年就被 Adobe 高價併購。

消息甫出，部分分析者將該公司的異軍突起，歸因於對產品打磨的耐心——從 2011 年該創辦人拿到第一筆創業資金開始，到了 2015 才出現第一個 Beta 測試版本，當時甚至連產品都沒有；2013 年，當創辦人 Dylan Field 在爭取投資時，甚至連明確的產品功能、商業模式都尚未清楚。換言之，Figma 在尚未推出產品，仍缺乏對於市場需求進行驗證的情況下，便埋頭做了 4 年。

先把產品打磨好，還是快速修正好？

事實上，若是細究，不難發現 Figma 是非常違反「最小可行性產品」，也就是 MVP 理論（Minimum Viable Product）的案例。

MVP 的精神，就是只保留對使用者來說最關鍵的功能，並且儘可能將驗證產品可行性的成本降到最低，同時又能夠測試原先對於市場的關鍵假設。如美國知名購鞋網站 Zappos 的創辦人，一開始為了驗證「大家會願意線上購買鞋子而無須試穿」的假設，僅架設了簡單的網站，並將實體店面的鞋子照片上傳展示，等到客戶下單再去實體店面購買並寄出，如此便能省下架設電子商務系統的成本。後來該公司以 12 億美元被 Amazon 收購。

當談到 MVP 時，許多人常會將原型（prototype）與最小可行性產品（Minimum Viable Product）搞混，前者是一種將抽象想法賦予形體的方法，能夠讓與工程或是設計團隊的溝通向前推進；但最小可行性產品的關鍵，並不是為求效率，急於推出難用又功能不完善的產品，而是減少不必要的功能，因為那既會拖慢開發進度，也會造成混淆，對專注在驗證消費者「是否會為了這個關鍵功能付費」沒有幫助。

有些人可能會聲稱，對於將「一套好用的團隊同步協作工具」視為核心功能的 Figma 來說，快速推出能符合上述需求的產品有其難度。不過實務上來說，驗證關鍵假說的方式，並不只限於將開發難度高的產品做出來。

當初 Dropbox 成立時，考量到所需的資金與技術很高，為了避免數年後被市場拒絕的風險，先是製作了 3 分鐘的功能說明影片，結果反應踴躍，排隊試用 Beta 版本的用戶清單，一夜之間就從 5,000 人上升到 75,000 人，成功驗證商業需求。

Figma 成功背後的眾多理由

誠然，Figma 在產品易用性方面當之無愧——它替整個需要來回溝通的開發團隊提供一站式解決方案，因此吸納了許多工程師、PM，甚至有 2/3 使用者不是設計師；但除此之外，它的定價策略也是使用戶迅速飆升的一大要素：使用軟體基本上免費，只限制每帳戶的專案數量與編輯者數量，但已經可以滿足絕大部分用戶的輕量需求，並提供持續增長的驅動力。

根據調查，一般打造出 MVP 的週期約莫是 3-6 個月，而 Figma 至少花上了 4-8 倍的時間。身處競爭激烈的 SaaS 產業來說，此舉確實能夠避免被抄襲的風險，但根據產業護城河門檻差異，一味效仿並非萬用解方——除了需額外負擔開發團隊的高昂人力成本，也犧牲掉了快速迭代的機會，萬一造出產品與使用者需求並不符合，資金將無法回收，對現金流短缺的新創來說恐是重傷。

在何時推出產品是大哉問，而維護護城河門檻與快速修正乍看之下背道而馳，但如同 Zappos 與 Dropbox 案例所顯示的，仍存在著能夠兼容兩者的選項需被調和，而非直接偏廢。

更多報導
刷卡、貸款、洗錢防制全靠科技助力！中信金的數位轉型心法：瞄準痛點
國泰金控轉型祕訣不私藏！從組織變革開始，如何實踐金融生態圈願景？
喝水、記帳變遊戲！《記帳城市》團隊如何靠用戶「玩心」改變2800萬人的生活？