欄どうしのつながりを読む
顧客の課題、価値提案、解決策がつながっているかを先に見ます。顧客に会う経路、収益、費用、指標、模倣されにくい点も置きますが、初期には未確定の欄があって構いません。推測を事実と同じ書き方にしないようにします。
検証する順序を付ける
各仮説を「外れたときの影響」と「根拠の弱さ」で比較します。顧客が課題を感じていないなら、課金方式の細部を先に検証しても意味が薄くなります。反対に、課題が明らかでも顧客への接触経路がない場合は、集客の実験を優先します。
更新理由を残す
面談を経て対象顧客を変えたら、旧版を消すのではなく、何を根拠に変えたかを記録します。作成日、仮説の状態、参照した調査をセットにすると、参加者が増えても議論を最初から繰り返さずに済みます。
開発着手の前に確認する
解決策の欄に並んだ機能を、そのまま見積もり依頼にしないでください。今回検証する仮説に必要な機能だけを抜き出し、それ以外は保留にします。キャンバスと開発バックログを結び付けるのが、最後の作業です。
参考資料と編集について
- Lean Canvas（LEANSTACK） ↗
- Why Lean Canvas vs Business Model Canvas?（Ash Maurya, Medium） ↗
- What is the Right Fill Order for a Lean Canvas?（Ash Maurya, Medium） ↗
新規事業.com の関連ナレッジ ↗をもとに、Otsumuが検証・実装・運用の観点から再編集しました。制度・仕様・サービスの現況は、各提供元の最新情報をご確認ください。
編集：Otsumu株式会社 ／ 編集日