創業怎麼獲得初期用戶?從LINE在台灣從0到1的秘密談起 (上)
創業怎麼獲得初期用戶?從LINE在台灣從0到1的秘密談起 (上)

一個第一次創業的網站服務團隊找我,諮詢創業相關問題與經驗。簡報完idea,詢問題目怎麼改善,或功能介面有無建議,就會問到資金短缺的問題怎麼處理:

為了獲取初期用戶?我想下FB廣告或辦抽獎活動之類的,需要一筆錢,應該需要投資,或可否幫我介紹投資人?

這題目,本身隱含了很多因果假設。但創業要成功,追本溯源,最根本的事可歸納到:

  1. 產品是否證實滿足了鎖定的核心用戶需求;

  2. 是否找到了能以指數成長的要件,例如每一個月用戶可成長一倍,或者留言增加100則用戶停留時間會加長10秒,又或是發現了投資一塊錢做行銷,可拿到兩塊錢營收的關鍵成長秘訣;

  3. 若達到1與2,的確需要考慮儘速投資加速增長。但若沒達到前述,花錢買用戶的需要是不大的,這是 Startup Pyramid的成長理論,先找到PMF,然後進行大規模成長。

創業初期1.png
圖/ 陶韻智

通常,解釋完這個矽谷常用的理論,(熟悉台灣的)創業者就會問:

那當初LINE在台灣是怎麼取得初期用戶的?

因為筆者工作經驗的關係,從LINE在台灣落地的第一天加入,做到他去紐約證交所上市,見證了他的起飛,成長,茁壯,近乎獨佔的過程,這個問題被問過很多次,也零星地談過無數次。再次被問,就我的觀點,其實他真的還是一個簡單的事情,就是LINE在台灣很快地突破了Startup Pyramid裡面的PMF階段,也善用了Scale中該做的事,敘述如下:

第一步:找到產品適合市場需求 PMF

得先理解,當初LINE做出來這個產品,初期主要是針對日本市場,並非台灣市場。2011年6月推出的時候,也並不是個生下來就大紅特紅的產品,表現也只能用一般來形容。

為了讓讀者更理解當時的時代背景,LINE並非Naver公司在日本的團隊推出的第一個App產品。在那之前,因應智慧型手機世代的來臨,公司應該已經推出了超過十個App,但在日本市場大受歡迎的產品一個都沒有。可想而知,多失敗一個也是正常而已,對吧。

再拉回到LINE推出後的時間:正常來說,產品落地後,該做什麼?花錢買用戶嗎?當然不是。

產品落地後,最重要的就是一直觀察早期用戶的使用行為,並快速迭代 — 為什麼他們不會使用得更久,更黏?為什麼他們不會推薦給更多的朋友?為什麼關西的人不使用?什麼feature做下去,可以讓整個成長爆發?

觀察,推論,假設,實驗,推翻或證實假設,繼續觀察,如此快速循環這個流程是這個階段團隊最重要的事。

然後,團隊就發現了一個假設,發揮漫畫文化,把貼圖放進通訊軟體應該會不錯,可以輔助“溝通”的需求,而且這是亞洲能接受的方式。在這樣的假設下,他們可能就會想,要能很簡單地送出,因此圖按了就送出去;而且一看就要能懂,圖也設計地比以前MSN的圖還要大張,也設計地情緒表達準確,不需要多描述,也不會有誤解的狀態,諸如此類云云…

然後,十月推出這個饅頭人,兔兔,熊大貼圖功能後,用戶成長就大爆發了,每日成長數完全不跟先前在同一個水平,年底直接衝破一千萬下載,而後來的歷史大家就比較熟悉了。

我們來推敲一下,當時團隊是否真知道這會是爆發的起點?我估計,或多或少有一些信心,但就跟其他推出的功能一樣,只有落地跟用戶互動了才知道輸贏。

這個過程,就是創業團隊尋求PMF的一個過程。以結果看,我們很容易看到成功的feature,卻沒看到LINE成長前進行的許多功能優化或許並沒有產生想像的成長結果,甚至是先前推出的其他更多App成長也都不如預期。

尋找PMF要有做實驗的精神,但又要快,悠閒不得,這挑戰了創業團隊的能力。

再拉回來主題,這談的是日本市場情況,那與台灣的成長又有何干係?

其實這就是最有趣的事。

回顧當時世代背景,LINE在2011年十月的時候,從日本爆發,接下來香港用戶大爆發,每天好多萬下載,同步台灣爆發,每天也好多萬下載。在當時,我的前老闆,也就是我後來LINE的老闆,寫email來問我為什麼LINE那麼多人用,我回問,什麼是LINE,讓我查一查先。

真正的情況是,我們不是那個早期用戶族群,但有一堆人,他們跟日本,跟香港密切往來,同步日本流行文化,就這麼地網路效應外溢到了台灣,且產品打中了使用習性要害,直接在台灣就是PMF,直接就擴散了。

這群最早用戶有多少,我們很難調查清楚,但可以知道的事情是,在2011年底,台灣的LINE下載數就突破了一百萬。這數字,我們還是得回到當年的背景去看比較清晰 - 就我所知,當時在台灣超過一百萬下載的App,區指可數,且當時LINE並沒有花錢買行銷買用戶。因此,能在短短地兩個月內從0到一百萬下載,說明了這個產品在台灣的病毒擴散係數是高的,而且證實產品產生了網路效應,更說明了這產品不需要修改,在台灣就是符合PMF定義的產品。

再用另一個角度來看一下,怎麼樣的速度可能可以在大約兩個月內達到百萬下載,我們假設一個數學公式來推敲:

初期用戶100人,每四天增加一倍(下載)用戶數50天後就(大約)會有 100*2¹³~= 819,200。

用這假設公式來看,驚人的成長速度不是來自初期用戶那一百人,而是那個指數型的每四天一倍的產品力。

關注在這個產品力的提升就是創業者要努力的。改善產品都是為了讓核心用戶滿意。花力氣就是要找到這能讓成長能以指數成長曲線飆升的關鍵因素。

如此,就算初期用戶只有幾十幾百幾千,透過倍數的成長,不消半年,數量都是很驚人的。

根據這個理論與經驗,在產品初期,行銷經費多寡並非是重要的決勝因素,找到PMF的快速迭代執行力是關鍵。從LINE在台灣的成長歷程正可以看得出來。

第二步:快速擴張Scale

前面第一步用LINE在台灣的例子說明了找到真正適合市場產品的快速迭代過程的重要性。

套用Startup Pyramid的理論,找到了PMF後,下一步就更重要了,就是快速擴張,高速奔馳,衝向hyper growth。

我們看到的互聯網各大戰役,大概都在這個階段浮上檯面,大家也樂於做吃瓜觀眾,在旁邊圍觀喝采。

以LINE在台灣的例子來說,絕大部分的人都不是在2011年就下載LINE,也就是說大家都不是那個早期用戶群。大部分的人開始使用LINE大概是在2012年2月桂綸鎂電視廣告大幅宣傳後。

拉回當年,我們來談幾個事實:

  1. 在此之前,沒有任何App公司花大錢打電視廣告;

  2. 如果不打廣告,LINE的成長速率仍然很快。

如果是你操盤,打不打幾千萬元台幣的電視廣告?

花錢很容易,做決定很困難。但有思考框架就會簡單一些:

互聯網的戰役,通常得考慮競爭。考慮競爭激烈就變成紅海,而要避開競爭的方法就是跑得比任何人都快,早早地把護城河建好,就不用競爭了!

當時,台灣最多人使用的Messenger,我估計是 MSN跟WhatsApp,但當時因為沒有積極經營,前者衰退,後者成長速率並非火箭速度。觀察到這個,這就是LINE可把握的機會。

考慮產品的確受台灣人喜愛,成長速率相當驚人,但使用有效的scale工具,有機會大幅壓縮成長所需要的時間,就能越早擺脫競爭,等到競爭者想追的時候,LINE所建立的網路效應以及成長倍數必然是競爭者望塵莫及的。

若這樣想,你會不會採用即便看似昂貴的成長工具?而這正是當初花數千萬元台幣,作為台灣第一個App下廣告背後的戰略因素。

廣告打完後當年年底,LINE的用戶數相較於年初成長了九倍,穩穩地奠定了LINE在台灣的用戶基礎,且拋開了可能的與WhatsApp的糾纏,也就避開了競爭。

結論

回到文章一開頭所問的,創業怎麼獲得初期用戶?透過朋友,透過核心社群,找到初期幾十幾百個用戶一般來說真不是創業者的問題。真正的努力應花在快速迭代打磨產品體驗,觀察並作出出用戶愛上產品的關鍵。至於怎麼確認抓到關鍵,達成PMF?就看你關鍵指摽是否呈現了指數型的爆發。

若找到了這個PMF,就應儘速擴張,大幅擴張成長,盯著指數型成長指標,不得鬆懈,稍有指標上的未達成,必須立刻找出原因與改善方案,然後循環這個爬階過程。

要能達成這巨幅快速成長,資金必然需要甚多,且得每次都跟上,一波接一波,不得有缺口。這就是談錢與談VC的時候,要這筆錢以及花這筆錢就會是這個階段創業CEO要面對的既痛苦又Happy的problem了。

本文由陶韻智授權轉載自其Medium

《數位時代》長期徵稿,針對時事科技議題,需要您的獨特觀點,歡迎各類專業人士來稿一起交流。投稿請寄edit@bnext.com.tw,文長至少800字,請附上個人100字內簡介,文章若採用將經編輯潤飾,如需改標會與您討論。

(觀點文章呈現多元意見,不代表《數位時代》的立場。)

往下滑看下一篇文章
數位時代 X 國泰金控 從百套系統上雲到 Cloud First:國泰如何把雲端變成AI成長引擎?
數位時代 X 國泰金控 從百套系統上雲到 Cloud First:國泰如何把雲端變成AI成長引擎?

2019年金融監理機關正式將雲端納入委外規範後,揭示金融業上雲時代來臨,國泰金控數數發中心成立雲端策略發展部,負責擬定集團上雲策略,並於2020年正式啟動7年集團雲端轉型計畫;在多數金融機構仍停留在單點遷移或IT現代化的現下,國泰金融集團在 2025 年即完成 100 套系統上雲,更將雲端轉型階段從 Cloud Ready、Cloud Adoption 推向 Cloud First,成為數據與人工智慧應用的關鍵引擎。

國泰金控資訊長|吳建興 James Wu
圖/ 數位時代

「百套系統上雲不僅僅是數字,更是讓國泰從『 IT 進化業務』邁向『 IT 驅動成長』的關鍵轉折。」國泰金控雲端策略發展部協理顏勝豪表示,上雲帶來的效益十分顯著,包括提升資源可用性與營運敏捷度、減輕 IT 維運負擔;同時,雲端業者多具備零碳排或綠能機房機制,亦有助於企業朝向 ESG 永續營運邁進。「金融上雲不是單純的現代化基礎設施或者是升級技術,而是為了換取速度與可靠度,讓集團可以加速創新腳步、彈性調配資源,以及培育所需人才與技能,為未來做最佳準備。」
為讓集團員工、金融同業以及有志上雲的夥伴可以進一步探討雲端轉型的各種可能,國泰金控舉辦雲端轉型成果發表會,會中除有集團子公司分享最新成果,三大公有雲平台業者也從不同技術視角共同探討在合規、資安與 AI 應用的可能。

七年、三階段,國泰金融集團將雲端內化為營運流程與創新引擎

國泰金控科技長|姚旭杰 Marcus Ya
圖/ 數位時代

為什麼國泰可以領先市場完成雲端轉型、數據與 AI 賦能業務?

顏勝豪認為,雲端轉型的起點不是直接遷移系統,而是從四個面向打底:應用系統盤點評估、雲端架構設計、雲端遷移藍圖規劃,以及組織治理框架建立,而這也是 Cloud Ready 階段最重要的事情。
「不同子公司有不同商業模式與節奏,若沒有共同語言與平台底座,上雲很容易各自為政。」顏勝豪表示,為讓所有員工可以齊步前行,國泰以雲端遷移方法論 Cathay 6R(註1)作為共同語言、用平台作為共同底座,讓轉型不只是技術選擇,而是集團行動。
完成單一系統的雲端遷移後,便進入 Cloud Adoption 階段。在這個階段中,要透過大規模遷移建立更成熟的上雲標準作業流程(SOP),透過 FinOps 機制控管與優化雲端營運成本,以及透過自動化與治理模型確認多雲環境與安全與維運穩定性,目標是將雲端內化為組織日常運營的一部分,進而邁向 Cloud First 階段:在合規前提下,新專案與系統升級預設在雲端環境開發,並善用雲原生優勢加速新產品功能開發速度。
「集團雲端策略只有一個核心原則:讓雲成為 AI 時代的成長引擎,而不是單純的基礎設施。」關於國泰的未來雲端布局,顏勝豪如是總結。

國泰金控 雲端策略發展部 協理|顏勝豪 Otto Yen
圖/ 數位時代

以雲端為 AI 資源引擎、發揮數據燃料價值,實現 AI 賦能業務應用

國泰不僅在2025年完成集團百套系統上雲,也啟動數據上雲計畫並為 GenAI 奠定基礎建設。
例如國泰金控實現數據上雲,打造資料湖倉與 GAIA 生態系統架構為 AI 賦能業務做準備:成立國泰風險聯防中心(CRC)攜手集團洗防人員強化風險控管與金融犯罪因應能力;釋出國泰員工 AI 助手–Agia–Beta
版,提供差勤、福利與權益、技術支援、職務職能與集團其他資訊等五大類別管理辦法等查詢服務;此外,亦推出集團數據共享平台、集團法規知識庫、 AI 評測中心等服務,更好發揮 Cloud First 與 AI 賦能業務應用的價值。
雲端是 AI 時代的關鍵底座、數據則是 AI 的燃料。顏勝豪指出,發展AI需要龐大的 GPU 算力,若自建 GPU 機房,不僅硬體設備昂貴、折舊速度快,光是散熱系統一年就高達兩、三千萬元的成本,若採取雲端資源,可以隨啟隨用,同時,大幅降低試錯成本。「當雲端打好基礎、AI成為能力模組,銀行、人壽、產險與證券的創新不再是單點突破,而是放大集團級綜效。」

國泰以 Cloud First + AI 持續領先市場、形塑未來樣貌

「雲端可以優化算力成本,資料則決定 AI 應用上限。」顏勝豪解釋,在 AI 新世代,AI 模型定調能力「下限」,集團子公司掌握的「獨特資料」則決定應用的「上限」,考量雲端有許多好用 AI 服務,唯有資料上雲才能發揮數據價值、用 AI 賦能集團各子公司業務。
例如國泰世華銀行將採取多公有雲策略,打造雲端智慧生態圈,並以現代化雲原生技術拓展應用場景;同時,運用 AI 與資料分析優化客戶服務體驗,並藉由跨雲整合機制支援多元業務模式,以充分發揮上雲效益。至於國泰產險,不僅在兩年半內完成13套核心系統上雲、優化營運流程,如以 Serverless 架構打造百萬級效果、萬元成本的短網址系統等,讓雲端成為產險驅動長期成長的核心引擎與標準配備。

國泰人壽則是透過雲端與 AI 滿足不同客戶需求,如以 AI Search 精準呈現關鍵字搜尋結果,讓客戶可以精準且快速的查找所需資料、大幅優化官網體驗與滿意度。至於國泰證券則是於2026年初推出「庫存管家」服務,以客戶持股為核心,應用 AI 技術打造個人化推播服務,協助投資人更有效率地掌握庫存狀況,提供更即時、系統化的投資管理體驗。
總的來說,國泰金控在集團的雲端轉型不僅是技術升級,更是思維革新,從百套系統上雲進展到 Cloud First 階段,可以預期在雲地基礎下,國泰將進一步引領 AI 時代變革,持續提升營運韌性與放大創新價值。

註1:Cathay 6R 國泰設計 Cathay 6R 雲端遷移方法論,將系統遷移方式依據上雲模式、系統開發成本分為 Rehost 、Replatform、Refactor、Rewrite、Replace 和 Retain 共6種遷移架構,並能對應到 IaaS、PaaS、SaaS 三種不同上雲模式。

登入數位時代會員

開啟專屬自己的主題內容,

每日推播重點文章

閱讀會員專屬文章

請先登入數位時代會員

看更多獨享內容

請先登入數位時代會員

開啟收藏文章功能,

請先登入數位時代會員

開啟訂閱文章分類功能,

請先登入數位時代會員

我還不是會員, 註冊去!
追蹤我們
2026 大重啟
© 2026 Business Next Media Corp. All Rights Reserved. 本網站內容未經允許,不得轉載。
106 台北市大安區光復南路102號9樓