アプリのアイデアを作る前に検証する方法

アプリのアイデアを検証するには、特定の人々がその問題を抱えているか、すでに解決しようとしているか、そして時間、メールアドレス、お金といった本物の何かを差し出して、あなたの解決策を得ようとするかどうかを確かめます。まずは会話から始め、ランディングページやウェイティングリストに進みます。先行販売や、再び使ってくれるユーザーを、最も強い証拠として扱ってください。ステップが進むほど少しずつ費用はかかりますが、得られる情報も増えます。

検証によって、アイデアが成功することが証明されるわけではありません。誰も求めていないものに何か月もかけてしまう可能性を下げるのです。

実際に試していること

「これは良いアイデアだろうか？」という問いは、曖昧すぎて検証できません。答えられる問いに分解しましょう。

最後の問いは見落とされがちです。本物の問題でも、顧客に連絡できないなら、やはり難しいビジネスです。

ステップ1：最もリスクの高い前提を書き出す

調査を始める前に、アイデアを1文で書きます。「[誰か]は[問題]に悩んでおり、[理由]から[解決策]を使うだろう。」 次に、それが機能するために何が真でなければならないかを挙げ、最も確信のない項目に印を付けます。それが最初に検証すべきものです。

ドッググルーマー向けの予約アプリの場合、最もリスクの高い前提は「グルーマーには予約管理が必要だ」ではないかもしれません。それは明らかにそうです。むしろ「グルーマーは今のツールに十分不満を感じていて、乗り換えるだろう」こそが前提です。

ステップ2：課題のインタビュー

インタビューは最も安く、最も情報の質が高い方法ですが、やり方を誤りやすいのも事実です。目的は、相手の現在の行動を知ることであり、売り込むことではありません。

誰に話を聞くか

先ほどの1文の説明に当てはまる人です。家族や友人は練習には良いですが、正直ではなく親切な答えになりがちです。実際の見込み客を、すでにいる場所で見つけましょう。業界団体、サブレディット、地域の事業者団体、LinkedInでの自分の人脈などです。

何を尋ねるか

仮定の未来ではなく、過去について尋ねます。

• 「最後に[問題]に対処したときのことを教えてください。」
• 「そのとき、どうしましたか？どんなツールを使いましたか？」
• 「そのどこが面倒でしたか？」
• 「それを直すために、何かにお金を払ったことはありますか？なぜ、または、なぜ払わなかったのですか？」
• 「それが起きるとき、ほかに誰が関わりますか？」

避けること

• 「もし…なアプリがあったら使いますか？」 ほとんどの人は、礼儀として「はい」と答えます。
• 解決策を早く見せすぎること。 一度見せると、相手は自分の問題について語るのではなく、それに反応するようになります。
• 褒め言葉を数えること。 「それは素晴らしいアイデアですね」は証拠ではありません。「完成したら試させてもらえますか？」は少しだけ証拠になります。「ここにカード番号があります」は大きな証拠です。

メモを取り、インタビューの後に学んだ3つのことを書き出します。複数の人が似た言葉で同じ痛みを説明したら、その言葉を書き留めてください。それがランディングページの見出しになります。

ステップ3：既存のものを確認する

自分の解決策ではなく、問題を検索します。既存の製品、料金ページ、公開されているレビューを見ましょう。競合がいることは、通常は良い兆候です。その問題を解決するために人がお金を払っている証拠だからです。探すべきものは、既存のツールがうまく対応できていない層、どの価格帯にも入っていない隙間、まだスプレッドシートで行われている作業の流れです。

何も存在しない場合は、その理由を確かめてください。チャンスの場合もあれば、問題がお金を払うほど痛みを伴っていないという意味の場合も多いものです。

ステップ4：ランディングページでスモークテスト

スモークテストとは、製品がすでにあるかのように説明し、明確な行動、たとえばウェイティングリストへの登録、アクセス依頼、事前注文を求めるページです。そのページに狙った人を誘導し、何人がその行動を取ったかを測定します。

ページに必要なもの：

1. インタビューの相手の言葉で問題を示す見出し。
2. 3〜4つの具体的な利点。利用者にとって何が変わるのか。
3. 行動を促す1つのボタン。
4. 製品が開発中であることの正直な注記。誰にも騙されたと感じさせないためです。

そのうえで、見込み客がいる場所から人を集めます。対象を絞った小さな有料広告のテストは効果的です。コミュニティへの投稿も、そのルールを守れば有効です。コンバージョンするランディングページの作り方では、構成とコピーを扱っています。

結果の読み方

どの会話率も「良い」とは言えません。比べるべきは自分自身です。2つの見出しや2つの対象層を試し、どちらの成績が良いかを確かめてください。最も役に立つ結果は割合ではなく、登録した人のリストです。その人たちにメールを送り、通話をお願いしましょう。

ステップ5：ウェイティングリストを作り、活用する

ウェイティングリストは、ローンチ前に関心のある人からメールアドレスを集めるものです。役立つ理由は2つあります。インタビューの相手が得られること、そしてローンチの日に読者がいることです。

弱点は、登録がほぼ無料であることです。リストにもっと働いてもらいましょう。

• 登録時に1つ質問をします。例：「今これに何を使っていますか？」
• 初期の登録者に、個別に返信し、15分の時間をお願いします。
• 数週間ごとに短いアップデートを送り、リストが冷めないようにします。

ウェイティングリストページの作り方では、メールの保存先を含めて、作り方を説明しています。

ステップ6：先行販売または手付金を取る

早い段階での最も強いシグナルはお金です。早期アクセスを割引価格や創設会員向けの価格で提供する、または返金可能な手付金を取り、誰が支払うかを見てみましょう。支払いリンクは、決済サービスのものを使えば十分です。完成した製品は必要ありません。

率直に伝えてください。いつ届けられる見込みかを明示し、返金を求める人には返金しましょう。誰も買わない先行販売も、1つの結果です。価格が合っていない、対象者が違う、あるいは痛みがインタビューで聞いたほど鋭くない、ということを示しているかもしれません。

ステップ7：コンシェルジュ型とオズの魔法使い型のテスト

最も速い「製品」は、あなた自身であることもあります。

• コンシェルジュ型テスト： 結果を手作業で届けます。アプリが毎週のレポートを作るなら、あなたがスプレッドシートで作ってメールで送ります。自動化する前に、ユーザーが何を本当に価値あると感じるかを正確に学べます。
• オズの魔法使い型テスト： ユーザーにはシンプルな画面が見えますが、その裏では手作業で作業しています。ユーザーは製品を体験し、あなたは再び戻ってくるかどうかを学びます。

どちらも拡大は遅いですが、それがポイントです。価値があると証明されたものだけを自動化します。

ステップ8：小さなMVPを作り、行動を観察する

最小限の実行可能な製品（MVP）とは、中核となる1つの仕事をする最も小さなバージョンです。AIアプリビルダーを使えば、データベースとログインを備えた動くMVPは、数か月ではなく数日で作れるようになりました。そのため、検証の一部として取り入れるのは現実的です。MVPとは何かをご覧ください。

重要な指標は、登録数ではなく繰り返しの利用です。こちらから促さなくても、2回目、3回目と戻ってくるでしょうか？同僚を招待するでしょうか？壊れたときに不満を言うでしょうか？それらは、そのアプリが相手にとって重要であることの証拠です。

検証方法の比較

いつやめる、変える、続けるか

始める前に、基準値を決めておきましょう。例：「インタビュー10件、そのうち3人が支払うと答える、先行販売が1件」。そのうえで正直に判断してください。

• 続ける： 人々が同じ痛みを繰り返し語り、一部の人がお金や時間を払う場合。
• 変える： 痛みは本物でも、想定していたのとは別の層、または別の価格で存在する場合。これはよくあることで、有益です。
• やめる： 誰もその問題を解決しようとせず、誰も支払わず、その問題を抱える人に連絡できない場合。

早めにやめるのは良い結果です。次のアイデアを検証する自由が得られます。

Mythexでの検証

Mythexは、このプロセスの後半の段階に合っています。ウェイティングリストのフォームを備えたランディングページを、チャットで説明するだけで、その日のうちに公開URLで動かせます。登録はデータベースに保存されます。シグナルが良ければ、同じプロジェクトを小さなMVPに育てられます。始めるのは無料で、ドキュメントのウェイティングリストの手順に流れが載っています。予算を検討しているなら、アプリ作成の費用で選択肢を比較できます。

よくある質問