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未來商務
責任編輯:傅珮晴