動手開發前如何驗證應用程式點子

要驗證應用程式點子，就是要確認某一群特定的人是否有這個問題、是否已經在設法解決，以及他們是否願意為你的解決方案付出一些實際的東西，例如時間、電子郵件或金錢。先從對話開始，再進入著陸頁或候補名單；把預購或再次回來的使用者視為最有力的證據。每往前一步，成本都會增加一點，得到的資訊也會多一點。

驗證並不能證明點子一定會成功，它只是降低你花了好幾個月卻做出沒人要的東西的機率。

你真正要測試的是什麼

「這是個好點子嗎？」這個問題太模糊，無法測試。請把它拆成你能回答的問題：

最後一項常被忽略。一個真實存在、但你無法接觸到客戶的問題，依然是一門艱難的生意。

步驟一：寫下你最大的風險假設

在任何研究之前，先把點子寫成一句話：「[誰] 在 [問題] 上很掙扎，並且會因為 [原因] 而使用 [解決方案]。」 接著列出要讓它成立必須為真的事項，然後圈出你最不確定的那一項。那就是你要先測試的東西。

以寵物美容師的排程應用程式為例，最大的風險假設可能不是「美容師需要排程」，這點顯然成立，而是「美容師對目前的工具已經不滿到願意換掉」。

步驟二：問題訪談

訪談是成本最低、資訊密度最高的方法，但也最容易做壞。目標是了解對方目前的行為，而不是推銷。

找誰聊

找符合你那一句話描述的人。朋友與家人適合拿來練習，但他們會客氣而不誠實。請到真正的潛在客戶已經聚集的地方去找：行業團體、Reddit 社群、地方商會，或你在 LinkedIn 上的人脈。

問什麼

問過去的事，而不是假設性的未來：

• 「跟我說說你上一次遇到[這個問題]的情況。」
• 「你當時怎麼處理？用了哪些工具？」
• 「那件事哪裡讓你覺得煩？」
• 「你有沒有花錢解決過？為什麼有或沒有？」
• 「每次發生這種情況，還有誰會牽涉進來？」

要避免什麼

• 「你會不會用一個能……的應用程式？」 幾乎每個人都會為了禮貌而說會。
• 太早展示你的解決方案。 一旦他們看到了，就會對它做出反應，而不是告訴你他們的問題。
• 把讚美當成證據。 「這個點子很棒」不是證據。「等你做好了我可以試用嗎？」有一點點價值。「這是我的信用卡」則價值很高。

做筆記，訪談結束後寫下你學到的三件事。當幾個人用相似的話描述同樣的痛點時，把這些用語記下來，它們之後會成為你著陸頁的標題。

步驟三：先看看市場上已經有什麼

搜尋的是問題，而不是你的解決方案。查看現有產品、它們的定價頁面，以及公開的評價。競爭通常是好跡象，因為這代表人們願意付錢解決這個問題。你要找的是一個缺口：現有工具服務得不好的族群、無人涵蓋的價格區間，或仍然用試算表處理的工作流程。

如果完全沒有任何相關產品，就要查清楚原因。有時這是機會；但更常見的情況是，這個問題的痛苦程度還不足以讓人付費。

步驟四：用著陸頁做冒煙測試

冒煙測試是一個像產品已經存在般描述它的頁面，並帶有一個清楚的行動：加入候補名單、申請存取權，或預購。接著把目標受眾導向這個頁面，並衡量有多少人採取了行動。

頁面需要具備：

1. 一個用受訪者自己的話點出問題的標題。
2. 三到四項具體好處，也就是使用者會因此有什麼改變。
3. 一個行動呼籲。
4. 誠實說明產品仍在開發中，讓人不會覺得被騙。

接著把流量導向你的受眾聚集的地方。針對窄受眾的小額廣告測試可能有效；在社群中發文也可以，但要遵守社群規則。如何建置能提高轉換率的著陸頁介紹了結構與文案。

解讀結果

沒有放諸四海皆準的「好」轉換率，所以請跟自己比較：同時測試兩個標題或兩群受眾，看哪一個表現較好。最有用的產出不是百分比，而是註冊者的名單。寄信給他們，並邀請他們通話。

步驟五：建立候補名單，並真正利用它

候補名單會在上市前收集感興趣的人的電子郵件。它有兩個用途：提供你可以訪談的對象，也在上市當天提供一群受眾。

它的弱點是註冊幾乎不需要任何成本。讓名單做更多的事：

• 註冊時問一個問題，例如「你目前用什麼來處理這件事？」
• 親自回覆早期的註冊者，並邀請他們撥出 15 分鐘。
• 每隔幾週寄一封簡短的更新，避免名單變得冷淡。

如何建置候補名單頁面涵蓋了建置方式，包括電子郵件的儲存位置。

步驟六：預售或收取訂金

最強的早期訊號是金錢。提供折扣的早期存取、創始會員價，或可退款的訂金，看看誰會付款。使用你的金流供應商提供的付款連結即可；你不需要已經完成的產品。

請坦白說明：告訴對方你預計何時交付，並且有人要求退款就退款。沒有人買的預售本身也是一項結果，它可能代表價格不對、受眾不對，或痛點並不像訪談中聽起來那麼強烈。

步驟七：禮賓式與綠野仙蹤測試

有時候最快的「產品」就是你本人。

• 禮賓式測試： 用手工交付成果。如果應用程式要每週產生報表，就自己在試算表中做好並用電子郵件寄出。在把它自動化之前，你就能確切知道使用者重視什麼。
• 綠野仙蹤測試： 使用者看到的是簡單的介面，但幕後由你手動完成工作。使用者體驗到的是產品；而你能學到的是他們會不會再回來。

這兩種方法都很難規模化，而這正是重點。你只應該把已證明值得做的事情自動化。

步驟八：建置小型 MVP，並觀察行為

最小可行產品（MVP）是能完成核心任務的最小版本。使用 AI 應用程式建置工具，一個具備資料庫和登入功能的可運作 MVP 可能只需要幾天而不是幾個月，因此把它納入驗證過程是合理的，請參閱什麼是 MVP。

關鍵指標不是註冊數，而是回訪使用。人們會在你沒有提醒的情況下，第二次、第三次回來嗎？他們會邀請同事嗎？當它壞掉時他們會抱怨嗎？這些都是應用程式對他們有意義的跡象。

比較各種驗證方法

何時停止、調整或繼續

在開始之前就設定好門檻，例如：「訪談十位，三人表示會付費，一筆預售」。然後誠實面對結果：

• 繼續：如果人們持續描述同樣的痛點，而且有人願意投入金錢或時間。
• 調整：如果痛點是真實的，但對象與你假設的不同，或價格與你假設的不同。這很常見，也很有價值。
• 停止：如果沒有人嘗試解決這個問題、沒有人願意付費，而且你也接觸不到有這個問題的人。

及早停止是一個好的結果。它讓你有空去測試下一個點子。

用 Mythex 進行驗證

Mythex 很適合這個流程的後期步驟。你可以用文字描述一個包含候補名單表單的著陸頁，並在同一天讓它上線到公開網址，註冊資料會儲存到資料庫中；當訊號良好時，再把同一個專案延伸成一個小型 MVP。入門是免費的，文件中的候補名單教學會說明步驟。如果你正在權衡預算，建置應用程式要花多少錢比較了各種選項。

常見問題