この 7 ステップのフレームワークで実験への取り組み方を変える

公開: 2023-01-10

製品チームにとって実験は不可欠です。 しかし、やり方が間違っていれば、まったくやらない方がよいでしょう。 実験を価値があり、予測可能で、持続可能にするためには、ビジネスの成長と顧客の問題に合わせてテストを調整するシステムが必要です。

重要ポイント

  • 実験は、チームが成長の考え方で取り組み、直感を更新し、顧客が必要とするものに近づくのに役立つため、非常に価値があります。
  • 問題は、多くのチームがその場しのぎの方法で実験を行ったり、実験の目標を誤って設定したりしていることです。これは、持続可能な学習と成功の欠如につながります。
  • 実験が学習を生み出さない場合、組織は意思決定ツールとしての実験への信頼を失い、それを社内プロセスに取り入れません
  • この問題を回避するには、組織は実験フレームワークを実装する必要があります。
  • このフレームワークは、実験が適切なビジネス成長レバーに沿って適切に調整され、顧客の問題に焦点を合わせていることを確認するのに役立ちます。

実験フレームワークが必要な理由

実験を行うことで、チームは、製品とそのユーザーに関する知識が変化する可能性があることを理解した上で、成長の考え方で作業することができます。 彼らは科学的な方法を適用して、スケーリング製品で自然に発生する認識と現実のギャップを埋め、顧客が実際に必要としているものに合わせることができます。

チームがアドホックな方法で実験すると、実験プログラムは失敗し、組織は内部の意思決定プロセスから実験を切り離します。 フレームワークは、実験がユーザー、ひいてはビジネスに利益をもたらすようにすることで、このような状況を回避します。

ビジネスに意味のある影響を与える意思決定を行うには、実験が重要です。 直感だけでも素晴らしい結果が得られるかもしれませんが、意思決定プロセスは持続可能でも信頼できるものでもありません。

実験は、成長マインドセットを開発するのに役立ちます

実験が仕事の不可欠な部分である場合、固定された考え方 (製品について自分が信じていることを決して更新しない) から離れ、成長する考え方で作業するのに役立ちます。 仮定に頼るのではなく、継続的に学び、知識を更新します。 そうすることで、ビジネスと顧客にとって最善の決定を下すことができます。

実験は、本能を更新し、より良い決定を下すのに役立ちます

実験しないと、直感に基づいて決定を下すか、単に部屋の中で最も大きな声が正しいと思うものに基づいて決定します. 定期的な実験により、データからの学習に基づいて決定を下すことができます。

長い間、直感的な決定を下すことに成功するかもしれませんが、企業の成長に伴い、直感を企業全体に拡大することは困難です。 また、直感がいつ時代遅れになり、間違っているかを知ることもできません。

組織が成長し、変化するにつれて、直観 (製品、顧客、および最善の行動経路について信じていること) は常に期限切れになります。 実験から学ぶと、得たデータに基づいて直感を磨き、更新することができます。

実験は、顧客との距離を縮めるのに役立ちます

実験を行うことで、認識と現実のギャップ (ユーザーが望んでいるものと実際に望んでいるものとの間のギャップ) を最小限に抑えることができます。 製品の初期段階にあり、Product/Market Fit を見つけようとしているときは、顧客との距離が近いことになります。 あなたは彼らと話し、彼らの感情とニーズを認識しています。

しかし、スケーリングを開始すると、認識と現実のギャップが拡大します。 意向の低い顧客や隣接するユーザーと戦わなければなりません。 顧客が多すぎるため、製品開発の初期段階のように顧客と話すことはできません。 実験は、直感が間違っている領域を見つけるのに役立ちます。これにより、スケールするにつれて認識のギャップを減らすことができます。

実験プログラムが失敗する理由

継続的なプロセスではなく、一度限りの戦術として実験を使用すると、実験プログラムは失敗することがよくあります。 人々はまた、実験が学習ではなく勝利をもたらすことを期待しているため、実験の目標を誤っています。

実験はアドホックです

チームは、実験を、特定の分野で誰かの直感を検証するための孤立した方法と見なすことがよくあります。 その場しのぎの実験は良い結果をもたらすかもしれないし、もたらさないかもしれませんが、それらの結果は予測可能ではなく、持続可能な運用方法ではありません。

テストの目標が正しくありません

人々が実験でリフトが得られると期待する場合、実験の目標は間違っています。 実験で勝つのは気分がいいですが、負けるほうが価値があります。 損失は​​、製品またはユーザーについて誤った信念を持っていた場所を示しているため、今後その信念を修正できます。

実験が成長レバーに沿っていない、または顧客の問題を中心に構成されていない

実験は、ビジネスが焦点を当てている成長レバーに合わせないと問題を引き起こします。それは、組織にとって役に立たないことを意味するからです。 同様に、顧客の問題を中心に実験を組み立てるのではなく、ビジネスの成果のみに焦点を当てると、問題が生じます。 ビジネス上の問題だけを考えていると、偏った方法でデータを解釈し、ユーザーにとって有益ではないソリューションを開発することになります。

実験プログラムが失敗するとどうなりますか?

実験プログラムが失敗したり、誤って実装されたりすると、組織は実験に対する自信を失い、直感に頼りすぎます。 彼らは、可能な限り最高の顧客体験を開発するための道として彼らを信頼するのをやめます. そうなると、彼らは意思決定プロセスの一部として実験を採用しないため、実験がもたらすすべての価値を失います。

失敗した実験の例をいくつか見てみましょう。 ビジネス上のレバーと顧客の問題に合わせて実験を調整するように促すフレームワークを使用せずに実験すると、次のようになります。

無料から有料への変換率

組織は収益化に重点を置いており、その製品を収益化する必要があります。 彼らは、無料から有料へのコンバージョン率を改善することをチームに課しています。

同社は、「価格設定からチェックアウトへのコンバージョン率が低いため、価格設定ページを最適化しましょう」と述べています。 チームは、ページのコンバージョン率を改善するために、さまざまな色とレイアウトをテストすることにしました。

ただし、価格設定ページを最適化するための実験は、顧客の問題を中心としたものではありません。 チームが顧客と話をしたことがあれば、価格設定ページの UX がアップグレードを妨げているのではないことに気付いたかもしれません。 むしろ、彼らはまだ購入する準備ができていないか、購入すべき理由を理解していない可能性があります。

この場合、価格設定ページだけを最適化しても結果は得られません。 チームが代わりに顧客の問題に実験の焦点を当てているとしましょう。 顧客が価格設定ページを見る前にその価値に触れられるように、プレミアム製品の試用版を実行しようとするかもしれません。

ビジネス上の問題から実験を開始する場合 (「コンバージョン率を高める必要がある」) と、顧客の問題から実験を開始する場合 (「彼らはまだ購入を検討する準備ができていません」)。

オンボーディングアンケート

組織は獲得に重点を置いているため、製品チームはオンボーディング アンケートの 2 ページ目から 3 ページ目へのドロップオフ率を最小限に抑えたいと考えています。 ビジネス上の問題だけを考えている場合は、3 ページを削除するだけかもしれません。 彼らは、オンボーディングが短いほど、ドロップオフ率が低くなると想定しています。

たとえば、3 ページ目を削除すると効果があり、オンボーディングのコンバージョン率が向上するとします。 より多くの人がアンケートに回答します。 チームは、製品の残りの部分に適用する学習を取り除きます。できるだけ多くのステップを削除して、すべてのカスタマー ジャーニーを簡素化する必要があります。

しかし、彼らは問題の顧客側について考えていなかったので、この学習は間違っている可能性があります。 彼らは、人々が 3 ページ目で離脱する理由を調査していませんでした。 問題はページの長さではなく、彼らが求めていた情報の種類だったのかもしれません。

おそらく 3 ページ目には、電話番号や給与などの個人情報に関する質問が含まれていたのではないでしょうか。 ページを削除する代わりに、それらの回答をオプションにするか、ユーザーが後で回答を編集できるようにして、より多くの人がオンボーディングのその部分を通過できるようにすることもできたはずです.

7 ステップの実験フレームワーク

次の手順に従って、実験を持続可能にします。 ビジネス戦略と顧客の問題に合わせて実験を調整するのに役立ちます。

7 ステップの実験フレームワーク
この単純なフレームワークを使用してバックログ リストを作成し、各バブルを Airtable または Sheets の列にします。

1. 成長レバーを定義する

実験が有意義であるためには、それがビジネスにとって重要である必要があります。 組織が注力している成長レバー (獲得、保持、または収益化) に合わせて、実験の領域を選択します。

獲得に焦点を当てていて、ホームページのドロップオフが高いことに気付いたとしましょう。 実験を組み立てるために、次のように言えます。

  • acquisition 獲得を2. 顧客の問題を定義する

    先に進む前に、実験で対処しようとしている問題を顧客の観点から定義する必要があります。

    製品が解決する顧客の問題を特定することで、Product/Market Fit を見つけました。 しかし、多くの組織が製品の配布とスケーリングに移行するとき、焦点をビジネス上の問題に切り替えます。 効果的であるためには、継続的に進化し、製品と市場の適合性について学ぶ必要があります.

    実験結果に基づいて顧客の問題を繰り返します。 問題が何であるかを述べて、最初の顧客の問題を定義することから始めます。

    ホームページの例では、次のようになります。

    • confused お客様は、私たちの価値提案について混乱しています。

    仮説を立てる

    次に、問題が存在する理由の解釈を定義します。 顧客の問題と同様に、さらに学習するにつれて仮説を繰り返します。 顧客の問題と仮説の最初のバージョンは、実験の出発点となります。

    ホームページの例の潜在的な仮説は次のとおりです。

    • poor messaging メッセージtoo many action buttons ページにアクション ボタンが多すぎますtoo vague 私たちのコピーはあまりにも曖昧4. KPI を使用して可能な解決策を考え出す

      お客様の問題を解決できる可能性のあるすべてのソリューションを考え出します。 各ソリューションがどの主要業績評価指標 (KPI) に対応しているかを示して、各ソリューションの成功を測定する方法を作成します。

      製品メトリクス ガイドをダウンロードして、獲得、維持、収益化に関する影響力のある製品 KPI のリストとそれらの測定方法を確認してください。

      ホームページの例のソリューション + KPI は次のようになります。

      • 解決策:KPI:5. 解決策に優先順位を付ける

        ソリューションを実装するためのコスト、ビジネスへの影響、および影響があるという自信の 3 つの要素を考慮して、最初にテストする必要があるソリューションを決定します。

        影響が小さくコストが高いソリューションを除外するには、次の順序でソリューションに優先順位を付けます。

        1. 低コスト、高い効果、高い信頼性
        2. 低コスト、大きな影響、低い信頼性
        3. 低コスト、低影響、高い信頼性

        次に、コストの高いソリューションに進むことができますが、その影響も大きい場合に限ります。

        企業によって、これらの要素に異なる重みを付ける場合があります。 たとえば、大規模な予算を持つ十分に確立された組織は、リソースがほとんどないスタートアップよりも、高コストのソリューションをテストすることに慎重ではありません. ただし、常に 3 つの要素 (コスト、影響、および影響の信頼度) を考慮する必要があります。

        実験のもう 1 つの利点は、信頼性評価を行う能力を磨くのに役立つことです。 実験した後、ソリューションが期待どおりの効果をもたらしたかどうかを確認し、結果から学びます。

        6. 実験ステートメントを作成してテストを実行する

        手順 1 から 5 で収集した情報を収集して、実験を構成するステートメントを作成します。

        ホームページの例では、そのステートメントは次のようになります。

        • growth lever customer hypothesis solution KPI 獲得を加速することが私たちの優先事項であり、トラフィックが最も多いランディング ページであるホームページは、パフォーマンスが低下しています [成長レバー]。これは、仮説] のために顧客顧客ソリューションKPI 影響を与え、上昇させ、テストしようとしている指標のベースラインを定義します。

          7. 結果から学び、反復する

          テストの結果に基づいて、ステップ 2 に戻り、顧客の問題と仮説を更新してから、このループを実行し続けます。 ビジネスの優先順位 (成長レバー) が変化したとき、たとえば買収が改善されたときに反復を停止し、収益化に集中したい。 新しいレバーに合わせて実験をセットアップします。

          反復をやめるべきもう 1 つの理由は、収益の減少が見られる場合です。 これは、これ以上のソリューションを考え出すことができないか、顧客の問題を効果的に解決するための適切なインフラストラクチャまたは十分なリソースがないことが原因である可能性があります。

          より良い意思決定をより迅速に行う

          ターゲットを絞った実験をユーザーに提供し、製品変更の影響を測定するには、適切な製品実験プラットフォームが必要です。 Amplitude Experiment は、製品、エンジニアリング、およびデータ チーム間のコラボレーションを可能にし、ユーザー行動分析を使用して製品変更の影響を計画、提供、追跡、および分析できるように構築されました。 開始するには、デモをリクエストしてください。

          この投稿を気に入っていただけた場合は、 LinkedInで私をフォローして、製品主導の成長の詳細をご覧ください。 製品の実験についてさらに詳しく知りたい場合は、 Reforgeに関する私の実験とテストのコースをご覧ください

          商品指標 CTA