為什麼新創需要新的會計#

新創一開始只是一張紙上的模型：估計顧客數、花費、收入與利潤。理想與現實差距極大。

新創的任務是：

1. 根據實證來精確評估現在的真實狀態，並接受真相可能很殘酷；
2. 設計實驗，學習如何把現實數字逐步拉向商業計畫中的理想數字。

最危險的狀態是「活不死也活不好」——有一些顧客、有一點成長、有一點正面結果，讓創業者誤以為自己在進展，實際上卻無法建立可持續的事業。

傳統會計無法評估這種創新工作——新創所處的不確定太大，傳統預測與目標無法準確衡量其績效。因此萊斯提出創新會計（innovation accounting）——一套取代傳統會計、專為新創設計的衡量系統。

一個例子：看似都在進步，其實停滯#

萊斯拜訪某家新創：資金充裕、顧客成長、產品是企業軟體領域的佼佼者。

• 問：「你們的產品有越來越好嗎？」「有！」
• 問：「你怎麼知道？」「我們是工程師出身，幾個月前做了改變，顧客似乎很滿意，這個月營收上升。所以一定走對方向。」

滿滿信心、卻沒有任何可操作的證據能回答「那個變動是否真的造成了結果」。創新會計存在的目的，就是要杜絕這種模糊的判斷。

一個能跨產業的會計框架#

創新會計先把孤注假設量化：

• 成熟製造商：成長來自顧客終身價值、獲客成本、既有客戶回購率的乘積。
• 市集型企業（如 eBay）：成長來自網路效應——買家與賣家雙邊都在找彼此，留存與新參與者驅動成長。

雖然成長動能不同，兩者都可用同一套創新會計框架評估。

創新會計的三個學習里程碑#

里程碑 1：建立基準（baseline）#

• 推出 MVP，蒐集真實數據：轉換率、留存率、每位顧客終身價值等。
• 若風險最大的假設（例如：有沒有人要用）已明顯失敗，可先測那個。
• 有時可用單獨的 MVP（或甚至「假門測試」——只列出未存在的功能，看人們願不願意點選）只測單一假設。

里程碑 2：調校引擎（tuning the engine）#

• 每個產品／行銷改動都應以「改善某個成長驅動因子」為目標。
• 比如：改善註冊流程 → 假設能提升新顧客啟用率。
• 若改動後啟用率沒有提升，設計就是失敗。
• 原則：好的設計能改變顧客行為；沒改變行為就是沒效。

兩家新創的差別：

• A 公司：有明確基準數字、有「這改會提升哪個指標」的假設、有實驗驗證。
• B 公司：坐著辯論要加什麼功能，同時上線多個變動，其中一個指標上升就慶祝。 哪家真的在學？

里程碑 3：轉向或堅持#

• 如果數字有系統地朝理想移動，繼續做。
• 如果數字不動，就是該轉向的徵兆——當前策略的一或多個假設是錯的。

轉向的正向信號是：轉向後的新實驗，比轉向前的實驗更有生產力。

IMVU 如何用創新會計揭穿自己#

IMVU 早期 MVP 缺陷很多，銷售慘淡。團隊自然假設：「品質低 → 銷售低」，所以持續投入提升品質。

每月董事會前一晚，團隊都會用傳統分析方法準備——計算轉換率、顧客數、營收——以證明自己「有進步」。

但幾次會議後，他們恐慌地發現：

「產品品質確實改善，但顧客行為沒變。我們只能說產品變得『好一點點』，但商業指標沒動。」

每天 5 美元的壯舉#

為了縮短回饋迴路，IMVU 做了一件看似微不足道的事：

• 每天只花 5 美元的 Google AdWords 預算，約換 100 次點擊。
• 行銷部會覺得這數字毫無意義，但對於學習卻價值連城——每天都能拿到新顧客的行為成績單。
• 每次改版產品，隔天就有結果。

七個月裡，他們做了幾千次改版、招了無數焦點團體、重做了好幾次可用性測試。但——

世代（Cohort）分析揭露真相#

傳統累計指標（總註冊、總營收、總活躍用戶）畫出漂亮的「曲棍球棒」曲線，看起來非常健康。但世代分析把顧客依首次互動時間分組，觀察每一世代的轉換漏斗：

• 「五次以上聊天」從 1% 漲到近 20%——確認產品改善有效。
• 但付費率死守在 1%。

辛苦改了 7 個月，付費轉換率幾乎沒動——意味著他們撞到了根本性的策略錯誤，而非執行問題。

從數據走向轉向#

當 IMVU 仍在 1% 打轉，萊斯回頭直接訪談顧客——此時問題變了：「為什麼這些產品改善對顧客行為毫無影響？」

真相逐漸明朗：IMVU 努力讓顧客更容易把現有朋友拉進 IMVU；但顧客根本不想用 IMVU 聯絡舊友——他們想認識新朋友。於是再多便利性改善也毫無意義。

轉向之後（放棄 IM add-on、建立獨立的新網絡），每次實驗開始產出更正面的結果，最終 IMVU 爬升到月營收百萬級。

這個模式會反覆出現：量化結果不佳 → 坦承失敗 → 設立質化研究的空間 → 產生新假設 → 新實驗 → 轉向或堅持的決策。

最佳化 vs 學習#

工程師、設計師、行銷人都擅長最佳化：

• 行銷：A/B 測試與多變量測試，比較兩組類似顧客的反應；
• 工程師：讓程式跑更快；
• 設計師：讓介面更易用。

在傳統、組織運作良好的公司，只要計畫執行得當，結果必然帶來好效果。

但新創不能複製這套模式：如果你在優化錯的產品，結果不會改善。

新創必須以高標準衡量進展——必須證明圍繞產品能建立可持續事業。沒有清晰的預測，產品與策略決策就會更困難、更耗時。

「團隊不夠努力」的陷阱#

萊斯多次受邀幫忙那些覺得自家工程師「不夠認真」的新創。事實通常是：

• 真正的問題不是工程師、不是工作倫理；
• 真正的問題是整套決策流程。

傳統模式的反應是：

1. 工程師越來越努力；
2. 結果不出來，主管假設是「規格不夠詳盡」；
3. 把規格寫得更細；
4. 規劃變慢，批量（batch）變大，回饋更慢；
5. CFO 加入，最終替換團隊。

真正的答案其實是：公司在執行錯誤的計畫——只是沒人有工具看穿這一點。學習里程碑能阻斷這種惡性循環。

警告：虛榮指標（Vanity Metrics）#

早期 IMVU 給董事會看的另一張圖表——總註冊、累計登入、啟用、活躍人數——全部都是曲棍球棒。看起來新創正在大幅進步。

虛榮指標（vanity metrics） 只表面上顯示一切安好。總量上升時，人們會誤以為「是我做的改變讓總量上升」；數字一跌，就怪別人。各部門發展出各自的術語、文化，變成防備彼此的藩籬。

同樣的累計漂亮曲線，一旦換成世代分析，真相就露出——「IMVU 的確接到新顧客，但各世代的付費轉換率完全停滯。」

可操作指標 vs 虛榮指標：Grockit 案例#

Grockit 由 Farbood 「Farb」Nivi 創辦。他曾在 Princeton Review、Kaplan 擔任 GMAT／LSAT／SAT 名師，每天上課 6–9 小時；甚至得過 Princeton Review 的「教師楷模獎」。

Grockit 的起點#

Farb 發現傳統單向講課太被動。他整合：

• 教師帶領的課堂；
• 獨立作業；
• 同儕小組學習——學生互教、互學，效果比名師還好。

MVP 很陽春：用 WebEx 線上教課。沒有新軟體，但「新型態的教學」消息很快傳開，月營收達到 1–1.5 萬美元，並成功募得頂級創投投資。

紀律嚴謹卻停滯不前#

Grockit 使用 Pivotal Labs 搭配的敏捷開發（Extreme Programming）方法，紀律一流：

• 每月一個 sprint；
• Farb 以「使用者故事（user story）」代替技術規格；
• 每個 sprint 結束都會推出新功能，並做顧客訪談。
• 累計指標（總顧客、總答題數、回訪率）都在上升。

但 Farb 越來越懷疑：這些進步到底是不是真的由產品開發造成？

關鍵一問#

萊斯問團隊：「你怎麼知道這些優先序是對的？」回答：「那不是我們的事，Farb 決定。」

但 Farb 自己也不確定——他 100% 相信願景，但開始質疑團隊是否真的能實現願景。

敏捷開發從開發者觀點看很有效率——工程師能全心投入「做出功能」。但若要求他們停下來驗證，短期生產力會下降。（類似精實生產的老問題：設備利用率 vs 整廠產能。）

Grockit 的瓶頸：用了錯誤的指標——累計顧客數、累計答題數。每個 sprint 盯的指標還都不同（這月看使用量、下月看註冊數）。沒有基準、無法歸因，優先序判斷變得極困難。

若要回答「功能 X 是否影響了顧客行為？」需要龐大的事後分析、且結論要等好幾週；這時團隊早已推進下一個 sprint。

Grockit 的轉型：世代分析 + 多變量測試#

萊斯建議兩個改變：

• 從累計指標改為世代指標；
• 每個新功能當成真正的多變量測試（A/B test） 上線——兩個版本同時推給不同顧客群，比較行為差異。

這項技術源自直效行銷——例如 Lands’ End 或 Crate & Barrel 把兩種型錄各寄給一半顧客，看銷售差別。Lean Startup 把這技術帶進產品開發。

驚人的結果#

• 很多工程師與設計師自豪的功能，實際上對顧客行為零影響。
• Grockit 和其他導入這個方法的公司都觀察到相同現象。
• 雖然每個變動必須獨立記錄比對、流程看似更慢，但長期反而省下大量時間——因為不再做沒人在乎的事。

多變量測試也精進了團隊對「顧客究竟要什麼」的理解。Grockit 原本堅信「學生想要更多社交互動」，但實驗顯示社交功能對行為毫無影響——這迫使他們重新思考、最終改做「遊戲化自學模式」，效果大幅提升。

Kanban：讓驗證式學習變成流程規則#

Grockit 採用精實生產的 kanban（看板）——限制每個階段能同時進行的工作量。使用者故事分為：

┌──────────┬──────────┬──────────┬──────────┐
│ backlog  │ 進行中    │ 已完成    │ 已驗證    │
│ (待辦)    │          │           │          │
└──────────┴──────────┴──────────┴──────────┘

規則：

• 每個階段最多裝 3 個故事。
• 故事在「已驗證」階段前不能被移除——未經驗證式學習的功能算沒完工。
• 若驗證顯示這個點子是壞的，該功能就被移除。

初期的陣痛#

各階段很快塞滿、新工作無法進入，團隊習慣以「完成的故事數」衡量生產力，感到停滯不前。但想恢復流動，就必須去驗證已完成但未驗證的故事——得做訪談、看多變量測試結果等非純工程的工作。

短期陣痛，長期獲得大幅正面效應：

• 工程師發現若在流程一開始就同步驗證，整體效率更高。
• 不再有「做出來卻沒人測試」的功能。
• 沒被工程師理解的使用者故事，也會提早被質疑：沒有清晰假設，故事怎麼可能被驗證？

核心轉變：用「驗證式學習」衡量生產力，而非「做了多少功能」。

Grockit 的假設測試範例#

Grockit 當年認為「懶人註冊（lazy registration）」是業界最佳實踐：先讓顧客體驗再註冊。他們投入大量工作維護三種使用者類別（未註冊來客、已註冊但試用中、付費用戶）。

萊斯建議做個簡單 A/B 測試：一半顧客走懶人註冊、一半強制先註冊。結果兩組的註冊、啟用、留存完全一樣。那麼多工作——純粹浪費。

更寶貴的收穫：顧客選不選 Grockit 其實不取決於產品試用機會。關注點應轉向 positioning 與行銷。這類實驗持續進行，Grockit 目前服務近百萬學生、持續擴展到 GMAT/SAT/ACT/GRE 以及國中小英數家教。

三個 A：可操作、可存取、可稽核#

萊斯提煉出評估指標好壞的三個準則：

1. Actionable（可操作）#

可操作的指標能清楚展示因果；否則就是虛榮指標。

虛榮指標例子：「網站這個月 40,000 次造訪——新紀錄！」

• 要怎樣獲得更多？看情況。
• 從哪來？某個特活躍的爬蟲？還是一個人？行銷？PR？
• 什麼叫「造訪」？首頁載入？還是包含多媒體元素？

人天生就擅長從可明確歸因的行為中學習——只要框架正確，人就會學得好。

2. Accessible（可存取）#

太多報表連員工都看不懂。建議：

• 記住「KPI = 人」：報表描述的是人類行為，不是抽象統計。
• 用具體量詞表達——例如「10,000 個使用者每人一次對話、再也不回來」vs「一人狂聊 10,000 次」，意義完全不同。
• 世代報表更能把複雜動作翻譯成真實人的行為。
• 廣泛可及：Grockit 每天自動寄 email 給全體員工，內容是所有多變量測試與孤注假設的最新結果。IMVU 在公司內部網頁公開所有實驗結果，任何員工都能登入查閱。當團隊有產品爭議時，這張一頁式摘要就是裁決依據。

3. Auditable（可稽核）#

當心愛的專案被資料否決時，人類天然會想攻擊訊息的來源——質疑資料本身。因此報表必須能被有系統地核實：

• 先決條件：報表的每一個數字都能被追溯到原始資料，而非層層中介。
• 關鍵動作：經理人要能直接到現場、訪談真實顧客——檢驗資料是否反映真實。這也是讓創業者真正理解「顧客為什麼這樣做」的途徑。
• 經驗：若因資料技術問題導致團隊懷疑某項假設的真假，士氣、信任、紀律會同步下滑。

好萊塢神話 vs 真實創業#

電影裡的創業故事總是：靈感從天而降 → 團隊組隊 → 實驗室埋頭苦幹 → 高潮售出產品 → 片尾片刻站上巔峰。

但在這片段之前，真正的 95% 都是無聊的硬活——用創新會計衡量的苦工：

• 排列產品優先序；
• 決定聽哪些顧客、不聽哪些；
• 用實驗測試大願景的勇氣；
• 持續蒐集回饋；
• 最耗時、最困難、最可能變成浪費的決定——什麼時候該轉向、什麼時候該堅持。

下一章，這個問題會被正面拆解。