建立 App 之前點樣驗證 App idea

要驗證 App idea，就要搵出一個特定群體是否有呢個問題、有冇正在嘗試解決，以及願唔願意為你嘅方案付出一啲實際嘅嘢，例如時間、電郵或者金錢。先由對話開始，再進入落地頁或者等候名單，並將預售或者會回頭使用嘅用戶視為最有力嘅證明。每一步都會多花一點成本，但都會令你多知一點。

驗證唔等於證明 idea 一定會成功，佢只係降低你花咗幾個月去做一樣冇人想要嘅嘢嘅機會。

你真正要測試嘅係咩

「呢個係咪好 idea？」太籠統，冇辦法測試。將佢拆做幾條可以回答嘅問題：

最後一條好常被忽略。一個真實嘅問題，如果你接觸唔到啲客戶，都仍然係一門難做嘅生意。

第一步：寫低你最大嘅假設風險

開始任何研究之前，先將 idea 寫成一句話：「【邊類人】面對【咩問題】好苦惱，並會因為【原因】而使用【你嘅方案】。」 然後列出要令佢成立必須成立嘅條件，圈出你最冇把握嗰一項。嗰一項就係你最先要測試嘅。

例如，一個俾寵物美容師用嘅預約 App，最大嘅風險未必係「美容師需唔需要排程」（佢哋當然需要），而係「美容師對現有工具嘅不滿，足以令佢哋轉換」。

第二步：問題訪談

訪談係最便宜、訊號最強嘅方法，但亦最容易做錯。目標係了解對方現時嘅行為，而唔係推銷。

搵邊啲人傾

符合你一句話描述嘅人。朋友同家人可以用來練習，但佢哋會對你客氣，而唔會誠實。搵真正嘅潛在客戶，就去佢哋已經聚集嘅地方：行業群組、Reddit 子版、本地商會，或者你自己喺 LinkedIn 嘅人脈。

問咩

問過去嘅事，唔好問假設性嘅未來：

• 「講吓你上次處理【問題】嘅經歷。」
• 「你當時點樣處理？用咗咩工具？」
• 「嗰件事邊度最煩？」
• 「你有冇為咗解決佢而付過錢？點解有或者點解冇？」
• 「每次發生呢類情況，仲有邊個會牽涉其中？」

避免咩

• 「你會唔會用一個可以……嘅 App？」 幾乎每個人都會為咗有禮貌而答「會」。
• 太早展示你嘅方案。 佢哋一見到，就會回應你嘅方案，而唔係講自己嘅問題。
• 計算讚美。 「呢個 idea 好好」唔係證據。「等你做好嗰陣我可唔可以試？」有少少用。「俾我張信用卡」就好有用。

記低筆記，之後寫低你從中學到嘅三樣嘢。當幾個人用類似嘅字眼描述同一個痛點，就要記低嗰啲字眼，佢哋會成為你落地頁嘅標題。

第三步：睇吓已經有咩嘢

搜尋嘅係問題，而唔係你嘅方案。留意現有嘅產品、佢哋嘅定價頁，以及公開評價。競爭通常係好嘅訊號，表示人哋會付錢去解決呢個問題。你要搵嘅係一個缺口：某個群組被現有工具服務得唔好、某個價位冇人覆蓋，或者某個工作流程仲係用試算表做。

如果完全冇嘢存在，就要搵出原因。有時係一個機會；但好多時係因為呢個問題痛苦程度唔夠，唔足以令人付錢。

第四步：用落地頁做 smoke test

Smoke test 係一個好似產品已經存在咁描述產品嘅頁面，並且有一個清晰嘅行動：加入等候名單、要求使用權，或者預購。然後你將目標受眾引去呢個頁面，量度有幾多人做出呢個行動。

頁面需要有：

1. 一個用你訪談對象嘅話講出問題嘅標題。
2. 三至四個具體好處，即係用戶會有咩改變。
3. 一個行動呼籲。
4. 一段誠實嘅說明，表示產品仲喺開發中，免得人哋覺得被騙。

然後去受眾聚集嘅地方帶來流量。針對窄受眾嘅小額廣告測試可以行得通；喺社群發帖都可以，但要跟足佢哋嘅規則。點樣建立一個高轉換嘅落地頁會講結構同文案。

點樣讀結果

冇一個通用嘅「好」轉換率，所以要同自己比較：跑兩個標題或者兩組受眾，睇邊個表現較好。最有用嘅輸出唔係百分比，而係報名者嘅名單。電郵佢哋，並問吓可唔可以傾十五分鐘。

第五步：建立等候名單，並且善用佢

等候名單係喺推出之前收集有興趣人士電郵嘅名單。佢有兩個用途：為你提供可以訪問嘅人，同埋喺推出當日提供一班觀眾。

它嘅弱點係報名幾乎免費。所以要令名單做多啲嘢：

• 報名時問一條問題，例如「你而家用咩嘢處理呢件事？」
• 親自回覆早期報名者，並邀請佢哋傾十五分鐘。
• 每隔幾個星期寄一封簡短更新，令名單唔會變得冷淡。

點樣建立等候名單頁面會講建立方法，包括電郵儲存喺邊度。

第六步：預售或者收取訂金

早期最強嘅訊號係金錢。提供折扣早鳥使用權、創始會員價，或者可退還嘅訂金，睇吓邊個肯付款。你可以用付款供應商提供嘅付款連結，唔需要一個完成咗嘅產品。

要坦白：講清楚你預計幾時交付，並退款俾任何要求退款嘅人。冇人買嘅預售都係一個結果，可能代表價錢唔啱、受眾唔啱，或者痛點冇訪談時講得咁尖銳。

第七步：Concierge 同 Wizard-of-Oz 測試

有時候最快嘅「產品」就係你自己。

• **Concierge 測試：**由你親手交付結果。例如 App 會生成每週報告，你就自己喺試算表做好再電郵俾用戶。你可以喺自動化之前，先清楚知道用戶最睇重咩。
• **Wizard-of-Oz 測試：**用戶見到一個簡單嘅介面，但背後嘅工作由你手動完成。用戶體驗到嘅係產品，而你就可以知道佢哋會唔會再返嚟。

兩者都難以規模化，而呢正係重點。只有證明值得做嘅嘢，你先至需要自動化。

第八步：建立一個細嘅 MVP，並觀察行為

MVP（最小可行產品）係能夠完成核心工作嘅最細版本。用 AI App 建置工具，一個有資料庫同登入功能嘅可用 MVP 可能只需要幾日，而唔係幾個月，所以將佢納入驗證過程而家係合理嘅做法，見什麼是 MVP。

最關鍵嘅指標唔係報名數字，而係回頭使用。用戶有冇第二次、第三次自己返嚟，唔使你推促？佢哋會唔會邀請同事？佢壞咗嘅時候會唔會投訴？呢啲都係 App 對佢哋重要嘅跡象。

比較驗證方法

幾時停、改定繼續

開始之前先定好門檻，例如「十次訪談，三個人話會付錢，一張預售單」。然後誠實面對：

• 繼續：如果人哋不斷描述同一個痛點，而且有人肯付出金錢或者時間。
• 改變：如果痛點真實，但對象唔同，或者價錢同你所假設嘅唔同。呢啲好常見，亦好有用。
• 停止：如果冇人嘗試解決呢個問題，冇人願意付錢，而且你接觸唔到有呢個問題嘅人。

及早停止都係一個好結果，可以令你去測試下一個 idea。

用 Mythex 驗證

Mythex 適合呢個過程嘅後期步驟。你可以描述一個附有等候名單表格嘅落地頁，當日就喺公開網址上線，報名資料會儲存喺資料庫；訊號良好時，再將同一個專案變成一個細嘅 MVP。開始使用免費，而文件入面嘅等候名單教學會列出步驟。如果你正在考慮預算，建立 App 要幾多錢會比較各種選擇。

常見問題