ウェイトリスト公開 Step1：ローンチLP（Amplitude）

ローンチランディングページ

このスキルは、プロダクトローンチ向けのランディングページをデザイン・構築するためのものです。優れたランディングページは2つのことを行います：価値を素早く伝え、訪問者を可能な限り早く「感動の瞬間」へ導くこと。他のすべては二の次です。

2つの設計上の問い

コピーやコードを1行でも書く前に、以下の問いに答えてください：

1. 「訪問者にどうすれば最も早く『感動の瞬間』を体験させられるか？」 最高のランディングページは、訪問者にプロダクトについて読ませるのではなく、使わせます。開発者ツールであれば、埋め込み型プレイグラウンド。SaaSであれば、ライブデモ。AIプロダクトであれば、そのページ上で推論を実行するウィジェット。「ここに着地した」から「おお、これはすごい」までの摩擦が少なければ少ないほど、コンバージョンは上がります。

2. 「どうすればこのページを、それ自体が注目に値するほどよくデザインされたものにできるか？」 人々がスクリーンショットを撮ってソーシャルメディアで共有するようなランディングページは、ローンチの波及効果を初期プッシュ以上に広げます。これは過剰なデザインを意味するのではなく、思慮深く、洗練され、特徴的であることを意味します。

ページ構成

ヒーローセクション

ほとんどの訪問者にとって、ここだけが重要です。60～80%の訪問者はヒーローセクションを超えてスクロールしません。

構成要素：

• 見出し — メッセージングブリーフからの主要な価値提案。1文で、具体的で、ベネフィットに焦点を当てます。「これは何ができるのか？」ではなく「これで何ができるのか？」に答えるべきです。
• サブ見出し — 見出しを補足する1～2文。対象者、仕組み、または主要な証明点など、特異性を加えます。
• プライマリーCTA — 1つの明確なアクション。「無料で試す」「始める」「動作を見る」。2つのCTAが注目を競い合ってはいけません。
• ビジュアル — プロダクトのスクリーンショット、デモ動画、またはインタラクティブなウィジェット。ストックフォトは絶対に使わない。見出しで約束したことを実際に行っているプロダクトそのものを表示します。

補足セクション（スクロール深度）

スペースに見合うセクションのみを含めます。各セクションは、特定の異論に対処するか、二次的な価値提案を拡張する必要があります。

一般的なセクション（今回のローンチに適したものを選んでください）：

• 仕組み — 3ステップまたはビジュアルによるウォークスルー。「複雑すぎないか？」という異論を軽減します。
• 主要機能/能力 — 3～4枚のカードまたはカラム。それぞれが具体的な例やスクリーンショットを伴う二次的な価値提案です。
• 社会的証明 — 顧客のロゴ、引用、使用統計、ベンチマーク結果。「これは信頼できるのか？」という異論を軽減します。
• 比較 — 既知の代替品がある市場に参入する場合、明確な比較を示します。正直に—恣意的な比較は信頼を損ないます。
• 料金 — 料金が競争上の優位性であれば、早期に表面化させます。複雑またはエンタープライズ向けの場合は、別の料金ページにリンクします。
• 技術詳細 — 開発者および技術者向け。コードサンプル、APIリファレンス、アーキテクチャ図。
• FAQ — 他の場所に収まらない異論に対応。短く—最大4～6問。

フッターCTA

最後までスクロールした訪問者向けに、下部でプライマリーCTAを繰り返します。彼らは最もエンゲージメントの高いオーディエンスです—コンバージョンを容易にしましょう。

デベロッパーファーストのパターン

技術製品や開発者ツールでは、以下のパターンが一貫して高いコンバージョンを生みます：

摩擦を容赦なく減らす

開発者がツールを評価する際の2大摩擦点はコストとアクセスです。両方をランディングページで対処します：

• クレジットカード不要の無料枠またはトライアル
• インスタントアクセス—個人ユーザーに対する「デモをリクエスト」ゲートは不要
• ページ上で明確かつ透明性のある料金表示

サインアップ前に試させる

最も効果的な開発者向けランディングページは、アカウント作成なしでプロダクトを体験させます。例：

• 埋め込み型コードプレイグラウンドまたはREPL
• ページから叩けるAPIエンドポイント
• 実際の出力を伴うインタラクティブデモ
• 「ここにデータ/コードを貼り付けて結果を見る」ウィジェット

実際のコードを見せる

開発者は統合が実際にどのように見えるかを知りたがっています。以下を含めます：

• インストールコマンド（npm install、pip installなど）
• 最小限の動作例（何か役に立つことをする5～10行）
• すべてのコードブロックにコピーボタン

機能ではなく能力でリードする

「毎秒10,000ドキュメントを処理」は「分散処理エンジン」よりも説得力があります。開発者は何を構築でき、どの規模でできるかを気にします。

SEO統合

ローンチランディングページはSEOの機会です。初期のローンチは、長期的にページのランキングに貢献するバックリンク（プレス、ソーシャル、ブログ記事から）を生成します。最初からこれを見据えて構築します。

検索向けの命名

これが新しい製品や機能の場合、名前を選ぶ際に検索ボリュームを考慮します。名前は、ターゲットオーディエンスが実際に検索するものと一致する必要があります。「Speech to Text API」は「Audio Transcription Service」よりも多くの検索トラフィックを得るかもしれません—あるいはその逆も。キーワードリサーチを使って決定します。

オンページSEOの基本

• タイトルタグ — プライマリーキーワードを含めます。60文字未満に保ちます。
• メタディスクリプション — キーワードを含む説得力のある要約。150～160文字。
• H1 — タイトルタグと一致または非常に近いものにします。
• 内部リンク — ドキュメント、ブログ、その他のページからこのランディングページにリンクします。このページから関連するドキュメントやチュートリアルにリンクします。
• ページ速度 — 高速なページはランキングが高く、コンバージョンも高い。画像を最適化し、JavaScriptを最小限にし、CDNを使用します。

長期的なランキングのためのコンテンツ

ヒーロー以下に追加するセクション（仕組み、機能、FAQ）は、インデックス可能なコンテンツとして二重の役割を果たします。人間のために書きましょう。ただし、オーディエンスが検索するときに使う言語を使用します。

コンバージョン最適化

1つのプライマリーCTA

すべてのページには、訪問者に取ってもらいたい1つの主要なアクションがあります。他のすべては二次的です。「サインアップ」「デモを予約」「ウェイトリストに参加」「ドキュメントを読む」を同等の視覚的ウェイトで求めているなら、訪問者に選択を強いていることになります—そして多くの人は去ることを選びます。

フォーム項目を減らす

サインアップフォームに追加するフィールドごとにコンバージョンが減少します。開始に必要な最小限の情報だけを求めます。追加情報は後で収集できます。

速度が重要

ページの読み込み時間はコンバージョン率に直接影響します。読み込み時間1秒ごとに、約7%のコンバージョンが失われます。ランディングページでは特に：フォールド以下のコンテンツは遅延読み込み、ヒーロー画像を最適化、サードパーティスクリプトを最小限に。

モバイルファースト

ローンチトラフィックの40～60%はモバイルから（スマートフォンでソーシャルメディアのリンクをクリックする人々）発生することがよくあります。ヒーローセクションはスマートフォンの画面で機能する必要があります。モバイルでCTAボタンをテストしてください—簡単にタップできますか？

ローンチ固有のパターン

ローンチ用のランディングページには、常設の製品ページにはない制約があります—時間的制約があり、短期間のトラフィックの波をコンバージョンする必要があり、製品について初めて耳にするオーディエンスにアピールすることがよくあります。

緊急性と希少性

短期間にサインアップを集中させたいTier 1のローンチ向け：

• ローンチ価格または早期アクセス期間 — 「最初の1,000ユーザーは無料」または「ローンチウィークは50%オフ」は、ブックマークではなく今すぐ行動する具体的な理由を与えます。期限または残り枠を目立つように表示します。
• カウントダウンタイマー — 控えめに使用し、期限が本物の場合のみ（ベータが閉じる、料金が変わる、アクセスが制限される）。偽の緊急性は信頼を損ないます。
• リアルタイムの社会的証明 — 「本日1,247人の開発者がサインアップしました」またはライブカウンター。これは勢いを示し、「これを試しているのは私だけ？」というためらいを減らします。

これらをすべて積み重ねないでください。本物の緊急性メカニズムを1つ選び、目立つようにします。

ウェイトリストフロー

製品がまだ一般公開されていない場合、ランディングページはウェイトリストページになります。希少性が本物であるため、ウェイトリストページのコンバージョン率は標準のサインアップページの2～5倍です。

• 単一フィールド：メールのみ。フィールドを追加するごとにウェイトリストサインアップが減少します。
• ポジションフィードバック：「あなたはウェイトリストの#847番です」は、サインアップを具体的に感じさせ、再エンゲージメントのフック（「もうすぐです！」）を与えます。
• 紹介メカニズム（オプション）：「友達と共有してウェイトリストを早めましょう。」実際に履行できる場合のみ追加—壊れた紹介メカニズムは信頼を損ないます。
• 期待値の設定：「週に200ユーザーずつ受け入れています」または「2週間以内にアクセス可能になります。」サインアップ後の沈黙は興味を殺します。

プレローンチ、ローンチ当日、ポストローンチの状態

ローンチランディングページは静的ではありません—3つのフェーズを通じて進化する必要があります：

プレローンチ（1～2週間前）：

• ティーザーコピー：何が来るのか、誰のためか、いつローンチするか
• ウェイトリストまたは「通知する」サインアップ
• 主要な価値提案を超える製品詳細はなし

ローンチ当日：

• フルページ：ヒーロー、デモ、機能、社会的証明、CTA
• 直接アクセス：「今すぐ試す」または「無料で始める」
• ヒーローに埋め込まれたローンチ動画またはデモ
• 緊急性メカニズムがアクティブ（カウントダウン、ローンチ価格）

ポストローンチ（1週間後→恒久）：

• 時間的要素を削除（カウントダウン、「ローンチしたて」の表現）
• ローンチ中に蓄積された社会的証明を追加（ユーザー数、 testimonial、プレスロゴ）
• SEO向けに最適化：これは現在、恒久的な製品ページです
• CTAを現在の状態に更新（「始める」 vs. 「ローンチに参加する」）

構築前に3つの状態すべてを計画します。プレローンチとポストローンチの状態はしばしば忘れられ、期限切れのカウントダウンやローンチから数ヶ月経っても「ローンチしたて！」のコピーが残った古いページにつながります。

ローンチページ vs. 恒久的な製品ページ

Tier 1のローンチでは、専用のローンチページと恒久的な製品ページの両方を構築することを検討します：

• ローンチページ — ローンチの瞬間に最適化。緊急性メカニズム、ローンチ動画、集中CTAを含む。一時的—廃止を計画します。
• 製品ページ — この製品/機能の恒久的なホーム。継続的な発見とSEOに最適化。ローンチウィンドウ（通常1～2週間）が閉じた後、ローンチページを置き換えます。

移行計画：ローンチ前に、ローンチページがいつ、どのように製品ページになるかを決定します。最も簡単なアプローチ：最初に製品ページを構築し、その上に一時的なローンチ固有のヒーローと緊急性セクションを追加し、その後ローンチ後にそれらの要素を削除します。これにより、2つの別々のページを構築する必要がなくなります。

Tier 2以下では、既存の製品ページを更新します。機能ごとに別々のページを作成しないでください—SEOが分断されます。

ページの構築

実際にランディングページを実装する際は、以下に留意します：

• デザインではなくコピーから始める。 メッセージングブリーフに基づいて、最初にすべてのテキストを書きます。コピーが構造を決定します—その逆ではありません。
• 実績のあるレイアウトを使用する。 ヒーロー→社会的証明→機能→仕組み→CTA。順序を変えることはできますが、製品がそれを要求するのでなければ、レイアウトを再発明しないでください。
• スキャナー向けにデザインする。 ほとんどの訪問者は読むのではなくスキャンします。見出し、サブ見出し、ビジュアルは、本文がスキップされてもストーリーを伝える必要があります。
• 5秒ルールをテストする。 誰かにページを5秒間見せ、その製品が何をするか尋ねます。答えられない場合、ヒーローを改良する必要があります。

コンパニオンスキル

• launch-strategy — ページのコピーと構造を駆動するメッセージングブリーフ
• launch-video — ページに掲載するデモ動画とスクリーンショット
• launch-blog-post — ページがリンクするブログ記事（SEOのため、相互リンクも）
• launch-distribution — ページへのトラフィック誘導
• launch-metrics — UTMによるページコンバージョン率とトラフィックソースの追跡