アプリを発表し、ランディングページを作り、メールアドレスを集める。面白いものがもうすぐ登場すると伝える。
その間に、別の誰かが同じ機会に気づき、コーディングエージェントを開いて開発を始める。
「もうすぐ準備ができます」とメールを送る頃には、見込み客は別の製品を使っているかもしれない。
エージェントで開発する時代のウェイトリストに、私が疑問を感じるのはここだ。アイデアから使えるものを公開するまでの時間は変わった。公開戦略の助言も追いついているかは、あまり確信がない。
今日役立つものを渡せるなら、なぜ後で戻ってきてもらうのか。
従来の方法には理由があった
製品開発に何か月もかかった頃、ウェイトリストは初期の関心を受け止める手段だった。訴求を試し、ベータユーザーを募り、ソフトウェアが形になる間に利用者候補を集められた。
Linear と Superhuman はよく知られた例だ。Linear はリストから初期ユーザーを選び、小さな集団ごとに製品を改善した。Superhuman は個別の導入支援に力を注いだ。どちらも顧客から意図的に学ぶための方法だった。
ただし、これらは現在のコーディングエージェント以前に生まれた戦略だ。従来の方法の由来は説明できても、その利点と負担が今も釣り合うとは証明できない。
動く実験版を届ける費用が下がれば、関心表明だけを集める理由は弱くなる。
メールアドレスから分かるのは、フォームに入力する程度には約束が魅力的だったということだ。アプリを使う人なら、その約束がどこで破綻するかを教えてくれる。
競争相手にも時間を与えている
公開ウェイトリストは、顧客を獲得する前に機会を告知することにもなる。
特に、中心的な機能を比較的簡単に再現できる製品では重要だ。発表は問題を説明し、デモは解決策を示し、登録者数は需要を知らせる。
競争相手はロードマップ全体を再現する必要はない。顧客の問題を十分に解決し、先に役立てばいい。
これは競争上のリスクであって、確立した法則ではない。ウェイトリストが日常的に新興企業の市場喪失を招くと示す研究は見つからなかった。先に公開しても勝利が保証されるわけではない。
それでも、「欲しい」と「使える」の間を意図的に長くすることには、検討の余地がある。
顧客の問題は今起きている。公開日程は作り手の都合だ。
最近の事例から何が分かるか
Lovable 自身の振り返りには、2024 年の二度の不成功な公開、リストからの段階的な受け入れ、頻繁に行き詰まる AI が描かれている。同社は最終的な躍進を製品改善、ブランド変更、発信の改善によるものとしている。リストは以前からあったが、それだけでは足りなかった。
Manus は、アクセスを制限する公開方式が終わったという断言を難しくする。2025 年 3 月に招待制テストを始め、その後、年間経常収益 1 億ドルを報告した。これは限定公開の後に商業的成功があったことを示す。しかし制限が成功の原因だったか、もっと早く開放した方がよかったかは分からない。
どちらの方向にも同じ基準を適用すべきだ。成功企業がリストを使っていても、有効だった証明にはならない。失敗企業が使っていても、それが原因とは限らない。
製品へ招くことには違いがある
アイデアへの関心を集めることと、すでに使われている製品へのアクセスを管理することには、大切な違いがある。
Instinct は招待モデルの例だ。公開ホームページには友人を招待するリンクがある。それだけでアクセス制限の理由は分からないが、既存ユーザーが別の人を体験へ招くという、異なるやり取りを示している。
招待の先に動く製品があるなら、私にはその方が信頼できる。
合理的な制約はある。毎週支援できる新規顧客が少ないかもしれない。エージェントの実行費用が高いかもしれない。人数を増やす前に不具合を観察する必要もある。
招待でも希少性を演出できる。仕組み自体では判断できない。制限の理由が重要だ。
最も強い反論：顧客探しには今も手間がかかる
開発が速くなっても、顧客への届け方が自動的にできるわけではない。
最近の創業者の体験談が分かりやすい。Hado SEO の創業者は、80 件のメールアドレスを集め、公開週にそのうち 5 人を有料顧客に転換したと報告した。公開前にはコミュニティで見込み客を助け、提案を磨いていた。独立した検証のない自己申告だが、登録者総数だけでなく有料転換を述べている。
短い準備期間を設ける正当な理由にはなる。顧客がどこに集まり、問題をどう説明し、自分がそこに届くかを学べる。
ただ、疑問は残る。同じ人たちに小さくても動く製品を渡したら、もっと学べないだろうか。
開発が速くなるほど、この選択肢は現実的になる。
待たせる理由を明確にする
未公開のアプリを欲しく見せることが主目的のウェイトリストには懐疑的だ。
有用なリストは具体的なものに対応すべきだ。対応可能な人数、顧客との実験、外部への依存、解決中の製品上の制約。待つ理由と、利用できるようになる条件が必要だ。
「期待を高めるため」では、理由としてずっと弱い。
メールフォームを置く前に、代わりに何を届けられるか考えてみる。ひとつの作業手順。ひとつの便利な機能。範囲は狭くても何かをきちんとこなす版。
そうすれば、使われるか、戻ってくるか、改善に関心を持ってもらえるかを測れる。
期待を盛り上げ終える前に、誰かがあなたのアイデアの実用版を公開できるとしたら、いったい何を待っているのだろうか。