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案例所顯示的，仍存在著能夠兼容兩者的選項需被調和，而非直接偏廢。
延伸閱讀：
鎖定商務旅客打造「五感體驗」，星宇航空憑什麼自詡航空界愛馬仕？
「我們不只是漢餅店！」百年老店郭元益拚創新轉型，跳脫喜餅框架
本文授權轉載自：FC未來商務
責任編輯：傅珮晴
