実験の力を活用する
想定をテストする方法として、顧客へのインタビューがどのように役立つ手段になるかについて説明しました。 実際、顧客のインタビューは実験の一種です。 このユニットでは、顧客へのインタビューから得られた分析情報を拡大するのに役立つ、他のいくつかの種類の実験について説明します。
実験の複雑さの範囲は、単にメール アドレスの提供をユーザーに求めることから、彼らが実用最小限の製品 (MVP) を操作するときに彼らを観察したり、製品の購入または事前購入を彼らに依頼したりすることまでさまざまです。
スタートアップ企業の創業者は、実験を使用して、ユーザーに情報を提供したり、結果を測定したりすることで、特定の仮説をテストできます。 通常、出力は、ユーザー操作の形式になります。
各実験には、少なくとも次の要素が含まれている必要があります。
- 仮説: 主要な想定の 1 つを表す簡潔で反証可能な記述。
- アクション: 仮説をテストするために実行する手順。
- データ:実験で測定または観察する内容。
- 成功基準: 仮説を検証するために必要な最小限の応答。
一般に、複数の実験を実行して、重要な仮説それぞれをテストすることをお勧めします。 ほとんどの場合、最も低コストで最も手早くできる実験から始めて、不完全であっても何らかの初期データを生成します。 これらの初期実験の結果が有望な場合、より複雑な実験に進むことができます。 複雑な実験は、完了するのにより多くの時間と労力を要する可能性がありますが、仮説の強度に関する信頼を高めることができます。
どの実験でも最後に、学んだ内容と、その情報に基づいて行える決定を評価します。
一般的に使用される実験の例を次に示します。これらは、単純で忠実度の低いものから始め、より複雑で忠実度の高い実験に進みます。
実験の種類: オンライン広告
説明: 提案された価値命題に基づいて、オンライン広告 (検索ベースの広告、ディスプレイ広告、またはソーシャル メディア広告) を作成します。 理想的な顧客ペルソナと一致する顧客に焦点を当てます。
目的:対象顧客が Web サイトへのアクセスなどの行動要請に応答するかどうかをテストします。
長所: この実験の種類では、広告を立ち上げる前に分析を正しく設定した場合、簡単に追跡できるクリックスルー率とコンバージョン率が生成されます。
短所: この実験の種類では、比較的弱い関心だけが実証されます。 ユーザーにリンクを選んでもらっても、製品を使ったり購入したりするほどの関心に繋がらない場合があります。
実用的なヒント: 検索用語広告は、既に問題を認識し、解決策を探しているユーザーの関心をテストするのに役立ちます。 ディスプレイ広告とソーシャル メディア広告は、この認識ポイントにまだ到達していないユーザーにより適しています。
実験の種類: ランディング ページ
説明:製品と価値提案について説明し、行動要請に応答するよう顧客に求める基本的な Web サイト (通常は 1 ページ) を作成します。 この行動要請は、メール アドレスの提供 (関心が弱い証拠)、オンライン フォームの完成 (より強い証拠)、または製品の事前購入 (さらに強い) を求める依頼の場合があります。
目的:対象顧客が行動要請に応答するかどうかをテストします。
長所: この実験の種類は、設定と実行が低コストです。
短所: ページが専門的に見えるように、最適なドメインと十分な設計の入力が必要です。
実用的なヒント: すべての訪問者がページ全体をスクロールするわけではないため、行動喚起がフォールドの上にあることを確認します。 オンライン広告、電子メール キャンペーン、ソーシャル メディア、関連するオンライン フォームでの投稿などの方法を使用して、サイトへのトラフィックを促進することができます。 顧客へのインタビューを引用して、顧客の問題点を強調します。 製品の状態を常に率直に伝えるようにしてください。
実験の種類: クリックできるプロトタイプ
説明:Figma、InVision、Microsoft Visio などのツールを使用して、製品内の主な画面の実際的なモックアップを作成します。
目的： 最終的な製品に似た操作を行っているユーザーを観察し、後でフィードバックを収集します。
長所: この実験の種類では、顧客が引き付けられる機能を見つけ出す最適な方法になる可能性があります。 ユーザーがプロトタイプに関与する時間の長さは、関心度を示す良い指標になる場合があります。
短所: この実験の種類では、個々のフィードバックの取得には、設計の専門知識と時間の投資が必要です。 ユーザーがプロトタイプへの関与にかなりの時間を充てる必要があります。
実用的なヒント: クリック可能なプロトタイプを直接提供するのが最も適切です。 最初にユーザーにコンテキストを提供し、最後にフィードバックを求めます。
実験の種類: コンシェルジェ
説明: 結果を顧客に手動で提供します。 ソフトウェア製品が最終的に自動化する手順を顧客に一通り経験させます。 たとえば、結果が、顧客の入力に基づいて提供されるレポートである場合は、単純なフォームを使用して入力を取得できます。 次に、レポートを手動で作成し、それを相手に送信します。
目的: 顧客に結果を提供することで、その結果が有益であると見なされるかどうかをテストできます。 多くの場合、この想定は、結果達成のため実行されるプロセスに関係する何よりも、テストで重要です。
長所： 多くの場合、この実験の種類は、製品をビルドしなくても結果を提供できるため、迅速かつ安価に行うことができます。 これにより、結果を受け取った後に顧客からのフィードバックを収集し、その価値を導き出すことができます。 また、この実験は、顧客が結果に十分な価値を認める限り、売り込みの機会になる可能性もあります。 顧客にプロセスを一通り経験させることは、それをテストし、実際に製品の構築を開始するときに、学んだすべてのことを確実に取り込むための効果的な方法です。
短所:この実験の種類は十分にスケールされないため、結果を提供できる顧客の数が限られます。 プロセスの複雑さによっては、応答を予期できるタイミングが顧客にわかるように、見込みを設定することが必要な場合があります。
実用的なヒント: 多くの場合、少なくとも、顧客がサインアップのプロセスを開始し、必要な入力を提供するためにアクセスできるランディング ページを用意することをお勧めします。 成果が有益であるとわかった場合に顧客が書面によるフィードバックと推薦状を残すことが簡単であるようにしてください。
実験の種類: Wizard of Oz
説明: Wizard of Oz 実験は、コンシェルジェ実験によく似ています。 重要な違いは、この場合、顧客は、プロセスが "背後で" 手動によって完了していることに気付かないということです。
目的: Wizard of Oz 実験を使用すると、認知される結果の価値と、それを提供するプロセスの両方をテストできます。
長所: 顧客から見れば、彼らは製品を購入して使用しているので、この実験の種類では、コンシェルジェ方法よりも堅牢な価格テストが提供されますます。
短所： この実験の種類は通常、プロセスが手動であるため、多数の顧客にスケーリングされません。 この実験は、顧客に対して 1 つの出力 (レポートや何らかのアクション動作など) を作成する製品に適していますが、重要な顧客操作を必要とする製品には適しません。
実用的なヒント: 背後にあるプロセスが手動で行われていることに顧客は気付かないので、彼らに結果をすばやく提供する準備をしておきます。 一般に、Wizard of Oz を使用して採算が取れるように価格を設定することをお勧めします。 そうすれば、望む限り継続して、価値を手動で提供することができます。 プロセスを自動化すると、利益率を向上できるだけです。
実験の種類: 模擬販売
説明: 模擬販売の実験では、プランと価格情報と共に製品の位置付けを行います。 また、実際に支払いを受け取ることなく、顧客の購入への関心をテストします。 顧客が価格オプションを選択したときに、製品がまだ購入できないことを彼らに伝え、可能になったときに通知するために彼らの詳細の提供を求めることができます。
目的: 価格オプションを選択すると購入の意図が示されるので、模擬販売は顧客が製品の価値を認識するかどうかをテストする場合に最適です。 また、さまざまな価格ポイントやプランのテストにも役立ちます。
長所: ランディング ページにスクリーンショットのモックアップや他の情報を配置することで、製品を構築する前に、この実験の種類を使用できます。 これは、強い関心を示す見込み顧客のメール リストを作成するための有益な方法になり得ます。
短所: 購入する意図は、製品が本物であるときの実際の購入と必ずしも同じとは限りません。
実用的なヒント: 支払いの受け取りも顧客に誤解を招く情報の提供もしないようにしてください。 さまざまなトラフィック ソースを追跡して、購買顧客をサイトに導く可能性が最も高いものを確定します。
実験の種類: 実用最小限の製品 (MVP)
説明: 機能する基本的なソフトウェア製品であり、コアの想定をテストするための最小限の機能セット (通常は 1 つの機能) を提供します。
目的: MVP を通じて顧客に十分な価値を提供して、特定の顧客の仕事に対処し、問題点を解決し、顧客のニーズと経験について理解できるようにします。
長所: MVP 実験によって、ユーザーは無料の試用ユーザーから有償のユーザーに転換する可能性があります。 1 つの機能に対する支払いは、顧客の関心を示す強力なシグナルです。
短所: 一部のスタートアップ企業では、実際に価値を提供する MVP を作成するために多大な労力が必要です。 一部の業界 (医療やサイバーセキュリティなど) では、MVP の故障や、規制要件への非準拠という許容できないリスクが発生する可能性があります。
実用的なヒント: MVP は、製品で実行する必要がある主要な仕事を最適に表す 1 つの機能にとどめます。 限られた機能セットが重要な問題を解決する可能性が高いユーザーを引き付けることに重点を置きます。 ユーザーがフィードバックを簡単に提供できるようにします。 フィードバックが肯定的な場合、顧客の推薦状を提供するように要請します。 通常、顧客へのインタビュー、その後に続くクリック可能なプロトタイプ、コンシェルジェ、Wizard of Oz などの忠実度の低い実験から学んだことに基づいて、MVP を作成することをお勧めします。
MVP を製品の "バージョン 1.0" と考えることは簡単ですが、この考えによって、創業者が必要以上に多くの機能を構築する事態を招く恐れがあります。 多くの製品では、MVP は、顧客と共に想定をテストする目的でのみ使い捨てできるツールとして好ましく見なされています。
多くの場合、ローコードまたはノーコードのツールを使用して MVP を迅速かつ低コストで構築して、1 つの機能だけでも価値を提供することができます。 このような場合、実験が完了した後、MVP を破棄できます。 その後、ラフな MVP を製品の基礎として使用するのではなく、学んだことに基づいて製品の構築を開始できます。
タスク: 実験を計画する
スタートアップ企業にとって意味のある実験の種類を少なくとも 1 つ選択します。 実験を完了するための手順を示します。 テストする予定の仮説を忘れずに検討し、簡潔で反証可能な記述として表現します。 実験で測定または観察のために計画していることと、仮説を検証するために必要な最小限の応答を明確にします。