●はじめに複数のオプションを用意する
ただ1つのソリューションを、他のソリューションとは無関係に検証することは困難だ。金融情報会社が、トレーダーを対象としたオンライン・コミュニティの構築を考えているとしよう。対象となるユーザーたちが協力し合ってコミュニティに貢献しようとする気になるには、どんな動機が必要だろうか。それは「社会的地位」かもしれないし、「課題の共有」かもしれない。「利他主義」も考えられる。
これらの動機のどれか1つをサポートするソリューションを立ち上げれば、採用度合いを容易に測定できるが、その根底にある「なぜ」を特定することは非常に難しい。他方、これらの動機すべてをサポートするソリューションを立ち上げれば、協力の真の動機（おそらくは複数）をより複眼的に理解できる。たとえばオプションAという提供価値が最もユーザーに理解され、オプションBのインタラクションの仕組みが離脱を促し、オプションCの収益モデルで高いコンバージョン率が見られる、ということがわかれば、最適なソリューションを特定しやすい。複数のオプションに基づくアプローチを採用すれば多くのシグナルが得られるため、より豊かで深い解釈が可能になる。
●実験する順番を、慎重に検討する
ユーザーがこちらの失敗を許容するのは、ソリューションの信頼性が損なわれていない限りにおいてである（そして当然ながら、失敗のなかには信頼性にダメージを与えるものと、そうでないものがある）。トレーダーのプラットフォームづくりを手掛ける前述の金融情報会社が、「社会的地位」という動機をサポートするソリューションを構築しているとしよう。この動機に応えうるソリューションは、影響度スコア、投票ボタン、アイデアを再提案できる機能など多数存在する。
このなかで影響度スコアは、最初に提供するソリューションとしては不向きといえる。社会的地位がコミュニティでの協働を促進する動機にならないことが後に判明した場合、ユーザーの影響度スコアを無効にすることはきわめて困難だからだ（最も多く影響度スコアを稼ぐ上級ユーザーの場合は特に）。A/Bテストはソリューションをいつでも変更・廃止できるかのように扱うが、実際には、たとえ「常にベータ段階」にある企業に対してであっても、ユーザーがけっして許さない変更がいくつかあるものだ。ユーザー体験を完全に阻害しないように、潜在的なソリューションをどの順番で試すのか思慮深く計画的に判断する必要がある。
