必要最小限の打ち手は、アウトカム測定から

こんにちは、ファッションシェアリング「Laxus」でPdM/マーケをしている古財（@REO135671）といいます！

約3週間ぶりの更新になりました。Noteを再開して1か月になりますが、この間に公開した2つの記事とも多くの方に読んでいただけて嬉しいです。
引き続きPdM関連のことを発信していくので、この記事を読んで「役に立った！」という方はぜひスキをお願いします（笑）

その施策、アウトカム測定できてますか？

3週間ぶりの更新は、スキが多かった「イベントレポ」の第2弾を書こうと思います。
といっても、少し前のイベントになりますがすごく学びになったので共有させてください。詳しい動画は以下に載せておきます。

作って終わりのデリバー思考

プロダクト改善をやり始めて間もないころ、完全にデリバー思考でした。機能を作るのが楽しくて、課題らしきものを見つけては作るを繰り返していました。その当時の会社も、「即リリース！」みたいな流れがあったので、ROIや優先度を全く考慮せずに開発チームへ案件を渡していました。

今思うとこれは完全に間違いでした。スタートアップって少ないリソースの中で何に取り組むかがすごく重要です。ここで取り組むことは不確実性の高いもので、そのためにはユーザーを学習する必要があります。

リーンスタートアップでいわれる「仮説構築→計測→学習」の学習ですね。ユーザーを学習するために計測をして、定量だったり定性のデータを集めるのですが、それをほぼしてなかったです。結果、施策がうまく行ってるのか行ってないのか分からず、ただの自己満で終わってました。

ただ数字を集めればいい、数値計測思考へ

その後、このまま計測なしで施策を走らせるのは危険なので、KPIを設定してモニタリングする方法に変えていきました。
でも当時のKPIは施策のアウトカムに則ったものではなかったです。

例えば予約導線を改善する場合、「使われるかどうか」を確認する指標（日別のタップ数や改善点経由のCV数）しか取ってませんでした。
これだと、使われたけどアウトカムにつながっているか判断できません。

KPIは大事といわれるから、とりあえずとっておこう。
その施策が良かったか〇✕つけたいから、とりあえず計測しよう。

ユーザーを理解するとは程遠いKPIの運用をしてました。見るKPIを間違って、誤った〇✕の判断をしてました。
そして✕だったときに、次の打ち手がギャンブルになってました。

そもそもリリースした時に、ユーザーから学習することを決めてない（＝KPIが間違ってたり、設計されてない）ので、✕のときに何が原因か分からず、推測で決めてしまって、効果が出ない見当違いな改善を続けてしまう、負のスパイラルに陥ってました。

この状況を何とかして、ユーザーの理解につながる効果測定を行う必要があり、参考となるものを探していました。そして、前述のpmconf2022にたどりつきました。

ポジティブもネガティブも予想するから、次の打ち手がクリアになる

この動画の中で一番学びになったのは、タイトルにもあるように、ネガティブなことも仮説を立てて、数値を追うというものです。

プロダクト企画フェーズでは、課題に対するアウトカムが言語化できているので、効果があるといえるポジティブな数値は追っていると思います。

重要なのはもし効果がなかった場合、その要因を特定できるようにネガティブの数値も仮説を持って追わないといけないということです。
ポジティブ・ネガティブ両方の数値を見て、どちらも問題ない場合に初めて施策はうまくいったと自信をもって言うことができます。

必要最小限で目指すアウトカムに到達する

ネガティブな数値を取りにいくには、プロダクト企画の段階でユーザーから学ぶことを明確にしておかないといけません。ユーザーから学ぶことの多くは、企画時点でクリティカルな要素だと思います。

つまり、アウトカムが達成できているかポジティブな数値を見ると同時に、クリティカルな要素も解決しているかネガティブな数値を見ることが大事だと分かりました。
※ここでいうクリティカルは、「使ってくれるか」みたいな根本的な部分ではなく、UI設計時の仮説などを指します

差分をみることでアウトカムに近づく最小限の打ち手を見つける方法は、気づけなかったので実践しようと思います！