デカい仮説検証のコツ

目次

TL;DR

現時点では、可能な限り多様な視点で Pros / Cons 洗って良さそうな方を選ぶしかない

前提

• 正解のない問題なので、「Xを判断する」「Xを明らかにする」という事が目的になる
• 目先のKPIより長期的な効果を優先する（方がなんだかんだ早い）
• 新しい体験を検証するのであれば、ハンドルを握らなくても車が走るという「思想」ではなく、ハンドルを握らなくても車が走るという「体験」を検証するべき。

デカい仮説検証、とは

検証するのに全体的に大きなコストが掛かるもの

例えば…

• 10倍良いユーザー体験を実施するため、バリューチェーンを厚くするべきか否かの検証
• 既存のユースケースを全く別の方法で解決する手段に置き換えるようなもの
• ファネルで1枚挟まって離脱率増えるかもしれないが完了率は伸びそうなもの

リスクの把握

主には以下の２つ。それぞれがサンクコスト化することも踏まえ、リスクを把握する必要がある。

• 実装コスト

  • 対象の検証を行うのに必要な実装工数

• 獲得コスト

  • 検証対象を集めるのにかかる費用と時間

リターンの把握

サービス毎の全ステークホルダーに関する Pros / Cons を 可能な限り多くのシナリオで洗い出す。 例えば 実装者/担当者/決裁者/新規が、新規案件/既存案件/完全外注/パッケージ のケースでは、プロダクトを何だと捉えてどうして関心を持つのかを洗い出して比較する。

リスク/リターンの評価

「どれ程何についてリスクを取ると、どんなリターンがどれくらいの可能性で獲得できるのか」を選択肢毎に明確化し、選ぶ。

SMB向けのマーケットプレイス事業を売却後、エンプラ向けのSaaSをやってます。元エンジニア：Ruby / Go / Nuxt / ReactNative