優先順位付けがすべてである理由
小さなチームが回せる実験は、週に2〜3件ほどでしょう。週に10〜20件に届くのは、実験の速度が非常に速いチームだけで、トラフィックが少なければそれも難しくなります。枠がこれだけ少ないと、平凡なテストの本当のコストはテストそのものではなく、それを回すために見送った、より強いアイデアです。ロードマップがあるのは、各枠を朝会で一番声の大きい人の案ではなく、期待値の最も高いアイデアに使うためです。この順位付きのキューを持つことは、グロースPMの仕事の大きな部分を占めます。
ファネルとアハモーメントからバックログを組み立てる
願望リストから始めないでください。ファネルの漏れている箇所から始めます。訪問、登録、アクティベーション、リテンション、売上と各ステップをたどり、最も大きな離脱を書き出します。その1つひとつが、検証できる仮説です。アクティベーションのアハモーメントに最も近いステップには大きな重みを置いてください。アクティベートしないユーザーが定着することはめったにないからです。名前を付けたアハモーメントは、証明された原因ではなく、検証すべき相関として扱います。アクティベーションのシグナルはリテンションを予測しますが、それを自社の施策がもたらしたことの証明にはなりません。それぞれの漏れが、バックログの1行になります。仮説、それが動かすはずの指標、そしてどれくらい動くかの大まかな見積もりです。
ICEでアイデアにスコアを付ける
Sean Ellisが広めたICEは、各アイデアを3つの軸で1〜10点で採点します。Impact(指標をどれだけ動かせそうか)、Confidence(うまくいくとどれだけ確信しているか)、Ease(どれだけ少ない労力で済むか)です。3つを掛け合わせ、降順に並べ、上から取り組みます。正直な推測を3つするだけなので、速いのです。その速さが落とし穴でもあります。スコアは推定であって事実ではありません。512と480はほぼ同じと読み、判定とは考えないでください。数字はリストに順番を付けますが、判断を代わりにしてくれるわけではありません。
リーチが異なるときはRICEを使う
2つのアイデアが届くユーザー数が大きく異なると、ICEはうまく機能しません。Intercomが考案したRICEは、Reach(リーチ)を加えてEffort(労力)で割ることでこれを解決します。計算式は(Reach × Impact × Confidence)÷ Effortです。すべての訪問者が目にするヒント表示と、設定ページの奥に埋もれた調整を、同じ土俵で採点できます。その代わり、速さを手放し、根拠を用意しなければならないリーチの見積もりを引き受けることになります。同じ注意が当てはまります。でっち上げた4つの数字を掛け合わせると、見せかけの精度が生まれかねません。入力は粗いままにし、学びに応じて見直してください。
| 項目 | ICE | RICE |
|---|---|---|
| 計算式 | Impact × Confidence × Ease | (Reach × Impact × Confidence)÷ Effort |
| 速さ | 速い(1〜10点の推測を3つ) | 遅め(リーチの数字が必要) |
| 向いている用途 | 大きなバックログの素早い仕分け | リーチが大きく異なるアイデア |
| 主な落とし穴 | Easeが本当の労力を隠す | あいまいな入力による見せかけの精度 |
決まったサイクルで見直し、負けたテストを打ち切る
週次か隔週で見直しの場を設け、決まったリズムで結果を読み、勝った案を採用し、残りを終わらせます。予定どおりに打ち切る規律が、キューを動かし続けます。回しっぱなしのテストは、枠を占有し続けます。ほとんどのテストは差が出ずに終わること、そしてトラフィックが少なければ多くのテストが始める前から検出力不足であることを、正直に認めてください。トラフィックが少ないときのテストで解説しているとおり、正しい判断はA/Bテストをせず、リリースして監視することである場合も少なくありません。測定する場合、きれいに結果を読むにはたいていホールドアウトグループが必要です。customer.ioのようなプラットフォームや、セルフホストのエンゲージメント基盤なら、それを確保しておけます。