【失敗者聯盟】No.2 Devver ---工程師創業小心別陷入盲點

歡迎來到 League of Losers 失敗者聯盟,在這裡我們將定期分享國內外最有趣、最具啟發性的 Startup 失敗故事,跌倒並不可恥,失敗可以重來,期待這個專欄能為有興趣創業的朋友帶來不一樣的觀點。

本期的故事值得所有有志創業的工程師們作為借鏡,純技術型的創辦人在創業時會遇到什麼樣的困難跟限制?來看看 Devver 的失敗案例吧!


Devver 創立於 2008 年,主要提供開發者雲端測試的服務,他們開發出了一套獨家的技術,讓開發者可以把測試工作分佈在多台遠端伺服器上處理,這比在本地單一機器處理快上許多。測試工作常常耗掉開發者許多的時間,透過這個方式開發者可以把測試時間降低到只剩原本的3分之1,大大地提昇了開發者的工作效率。

經過評估,這項服務的市場估值高達數十億美金,聽起來很棒對吧?Devver 原本只支援 Ruby 這個語言,後來還打算推出 Python、PHP、Java 的版本,不過這個願望從來沒有實現,因為他們只撐了兩年他們就正式宣佈關閉服務。Devver 在成立當年就拿到了50 萬美金的 A 輪資金,在 Ruby 開發者社群中也算小有名氣,但一直到倒閉為止,再也沒有從資本市場上拿到錢...這中間到底發生了什麼事?且讓我們看下去......

二、 失敗原因探討


就在 Devver 於官方部落格宣佈關閉服務後,兩位創辦人 Ben Brinckerhoff 和 Dan Mayer 共同寫了一篇文章回顧了這趟驚奇的兩年創業之旅,這篇文章中他們深刻地反省了過去所犯下的錯誤,筆者整理如下:

(1) 團隊只有技術型創辦人


相信讀者應該不難猜到,這麼宅的創業 idea 是工程師想到的,事實上 Devver 的原型正是兩位工程師創辦人做 project 時無意間的產物,而且團隊也只有他們兩個創辦人了。在矽谷有個很普遍的說法:「你可以教 Hacker 做生意,但你很難教商人 Hacking 」,這句話或許是對的(很多技術型創辦人同時也是偉大商人),不過他們認為團隊中「只有」技術型創辦人,並不是最有效率的配置方式。理由是「即便 Hacker 可以學怎麼做生意,但並非所有 Hacker 都對這件事很有熱忱」。

工程師或許可以學 Business Model、Pitch、社交、行銷、客服等做生意的技巧,但他們最擅長的還是 coding ,即便是一間技術性的 startup ,仍然有許多非技術性的重要工作需要完成,若能把這些工作交由專業的商業人才處理,可以省下很多寶貴的時間,讓工程師專注在擅長的事情上。

(2) 遠距離管理團隊


Devver 的團隊一直保持著遠距離作業,這當然有相對應的好處,譬如更能吸引到優秀的人才、增加工程師的生產力等等,不過行政上的管理就變得非常棘手了,Devver 的團隊成員分佈在三個州,每個州管理薪資、失業和保險的法規都不同,這對於小型 Startup 來說簡直就是噩夢,這也迫使創辦人花了很多時間處理行政上的瑣事,無法將100%的心力投注在產品上。

(3) 他們以為產品很有市場,但其實很小眾


第三點是關鍵中的關鍵,當兩位創辦人開發出 Devver 的原型後,許多潛在顧客都對他們的產品都很有興趣,他們以為自己找到了 MVP (minimum viable product, 最小可生存產品) ,然後他們就開始「埋頭苦幹」全力開發產品,這段期間幾乎沒有跟潛在顧客接觸,等到他們把產品做出來之後,才發現自己根本沒搞清楚市場大小跟技術上會遇到的問題,如果他們這段期間有好好的接觸使用者的話,他們應該會早點發現:

  • 雖然有些工程師覺得等待測試的時間很煩人,但大部分的人都不覺得有必要縮短測試的時間。反倒是很多人希望有一個更簡單、無加速功能的雲端測試服務。

  • 他們花了太多時間在鑽研「縮短測試時間」的技術上。當然這點很重要,但在推出產品之後,他們才發現針對不同的 Rails application「調整伺服器設定」才是最麻煩的地方,這件事情沒做好,使用者會很難使用他們的產品。但因為他們一開始沒有先想到這點,所以在早期產品開發時做了程式工程上的錯誤決定,導致調整伺服器設定這件事情變得異常的棘手。
  • 如果當時有一位非技術性的創辦人,或許就可以由他來負責與消費者溝通,早點釐清市場潛力和開發方向,當他們已經投注大量資源和心力推出產品後才發現這些問題時,一切都已經太遲了。

三、 結論


最後 Ben Brinckerhoff 在文章底下回覆了一位讀者的留言,筆者認為很適合作為 Devver 創業經驗的總結:

Customer development is an ongoing process. Once you've identified an MVP (which is an iterative process itself), the next step is to keep iterating as you add or improve features. Measure how the product is performing along key metrics, talk to customers, merge customer feedback with your vision, build and improve features, and then do it all over again!

「與客戶溝通是一個不容間斷的過程。一旦你決定了你的 MVP ,就必須在開發期間保持與客戶的聯繫。這三件事---運用關鍵指標測量產品表現、收集客戶反饋、根據反饋改良產品,必須一直重複地做下去!」

Devver 的失敗可說是「產品凌駕使用者」的經典案例,這個故事告訴我們,創業家必須保持與使用者溝通的習慣,絕對不要做好產品才發現解決了錯誤的問題,或發現 idea 缺乏足夠的商業價值。很多工程師熱衷於解決技術上的挑戰,卻忘了使用者實際的使用狀況,這在創業場上是兵家大忌,時時刻刻傾聽使用者的心聲,才是致勝的不二法門!

如果有任何問題或想法,或是想分享其他的精采案例,歡迎在下方留言!

Photo Credit:  Lisa Williams