Running Lean
著者:アッシュ・マウリャ
-
ロードマップ
-
メタ原則
- 手順1:プランAを文書化する
- 最初の手順
- ビジョン(仮説)を書き出す
- 1人以上の人間と共有する
- リーンキャンバス
- ビジネスモデル
- 9つの部品に分解
- 課題
- 顧客セグメント
- 独自の価値提案
- ソリューション
- チャネル
- 収益の流れ
- コスト構造
- 主要指標
- 圧倒的な優位性
- リスクの高いものから体系的にテスト
- 手順2:プランで最もリスクの高い部分を見つける
- 手順3:プランを体系的にテストする
- フィードバックループ
- イテレーションのメタパターン
Running Leanの実例
- いかにして私は本書を反復したか
- 課題を理解
- ソリューションの決定
- 予告用ランディングページ
- チャネルテスト
- 潜在的見込み客
- 定性的に検証する
- 実用最小限の製品
- 小さなバッチを反復
- 課金は最初の検証
- 定量的に検証する
- 正しい行動を適切な時期に
- 顧客との継続的なフィードバックループを構築
プランAを文書化する
-
リーンキャンバスの作成
-
見込み客を考える
- 顧客とユーザーを区別する
- 顧客セグメントを細かく分ける
- 最初はすべてを1枚のキャンバスにまとめる
- 顧客セグメントごとにリーンキャンバスを書く
リーンキャンバスをスケッチする
- 一気にスケッチする
- 空欄があってもよい
- 簡潔に書き表す
- 今わかる範囲で考える
- 顧客主導型を使う
課題と顧客セグメント
- 上位1~3位の課題を列挙する
- 既存の代替品を列挙する
- ユーザーを特定する
- アーリーアダプターに狙いを定める
UVP(独自の価値提案)
- UVPの作り方
- 変わったものにする
- アーリーアダプターをターゲットにする
- 成功ストーリーに注目
- 言葉をよく選んで使う
- 誰が・何尾・なぜに答える
- 優れたUVPを調べる
ソリューション
チャネル
- 無料と有料
- インバウンド
- プル型メッセージ
- ブログ
- SEO
- Ebook
- 小冊子
- オンラインセミナー
- アウトバウンド
- 直販と自動化
- 直接と間接
収益の流れとコスト構造
- 収益の流れ
- 価格は製品の一部
- 価格が顧客を決定する
- 課金は最初の検証
主要指標
プランで最もリスクの高い部分を見つける
- ビジネスモデルの優先順位
- リスクとは
- ビジネスモデルの比較
- 顧客の不満レベル
- 近づきやすさ
- 価格と粗利益
- 市場規模
- 技術的実現可能性
- 外部の意見を求める
- ビジネスモデルを誰かと共有する
- スライドを10枚にするのをやめる
- 20%を準備に、80%を対話に使う
- 具体的な質問をする
- 「アドバイザーパラドックス」に気をつける
- 先見性のあるアドバイザーを採用する
- 実験の準備
- 課題チームと解決チームを作る
- 効率的な実験
- 速度・学習・集中を大化する
- 反復可能な仮説
- 定性的検証と定量的検証
- 結果を具体的な行動に結びつける
- 分かりやすいダッシュボードをつくる
- 学習を早めにしょっちゅう伝える
- イテレーションのメタパターンをリスクに適用する
- ステージ
- 課題を理解する
- ソリューションを決定する
- 定性的に検証する
- 定量的に検証する
- リスク
プランを体系的にテストする
- 顧客インタビューの準備
- アンケート調査もフォーカスグループも不要
- でも、人と話をするのは難しい
- 学習を中心に考える
- 行動を観察する
- 台本にあわせて会話する
- 網を広く投げる
- 直接面会してインタビューする
- 知り合いから始める
- 誰かと一緒に行く
- 中立的な場所を選ぶ
- 十分な時間をもらう
- 謝礼や贈り物をしない
- インタビューを録音しない
- インタビュー後すぐに文書化する
- 30~60人にインタビューする
- 見込み客を探す
- 近しい人から始める
- 紹介をお願いする
- 地元で探す
- 予告ページでメールアドレスを登録してもらう
- 何らかの形でお返しをする
- 電話・メール・LinkedInを使って依頼する
- 課題インタビュー
- 学習すべきこと
- 課題のテスト
- 反復可能な仮説
- 課題インタビューの実施
- 歓迎
- 顧客情報の収集
- ストーリーの伝達
- 課題の優先順位
- 顧客の世界観の探求
- まとめ
- 結果の文書化
- 課題インタビューの終了条件
- アーリーアダプターとなる顧客が特定できた
- 「絶対に必要」な課題が見つかった
- 現在の顧客の解決方法がわかった
- ソリューションインタビュー
- 学習すべきこと
- ソリューションのテスト
- デモは実現可能でなければならない
- デモは本物に見えなければならない
- デモは高速に反復する必要がある
- デモはムダを最小化する
- デモは本物に見えるデータを使わなければならない
- 価格のテスト
- 価格のことは顧客に聞かず、ただ伝えるだけ
- 登録の障壁を下げずに上げる
- ソリューションインタビューのAIDA
- テスト可能な仮説
- ソリューションインタビューの実施
- 歓迎
- 顧客情報の収集
- ストーリーの伝達
- デモ
- 価格の検証
- まとめ
- 結果の文書化
- 課題インタビューの終了条件
- アーリーアダプターの顧客が特定できた
- 「絶対に必要」な課題がわかった
- 課題を解決するのに必要な最小限の機能が定義できた
- 顧客が支払ってくれる価格がわかった
- (概算で)うまくいきそうなビジネスが構築できた
- バージョン1.0をリリースする
- 製品開発は学習の邪魔
- MVPの縮小化
- 白紙から始める
- 最上位の課題から着手する
- 「あればうれしい」や「必要ない」は削除する
- 顧客の機能要求を検討する
- 初日から課金する
- 学習に集中する
- 継続的デプロイを始める
- アクティベーションの流れを定義する
- 道筋
- 注意
- 学習を犠牲にしない
- UVPを届ける
- うまくいかなかったときのことを考える
- マーケティング用のサイトを構築する
- ランディングページの分解
- 独自の価値提案
- ビジュアルの支援
- 明確な誘導
- 詳しく知るための誘導
- 計測の準備
- 行動につながる指標が必要
- 指標には人が必要
- 単純なファンネルレポートでは十分ではない
- 問題点
- 不正確なコンバージョン率
- トラフィックの変動
- 進捗の計測が困難
- 結局はファンネルを分割する
- コホートによろしく
- コホートとは?
- 利点
- トラフィックの変動に対応
- 進捗の計測が可能
- ファンネルの分割
- MVPインタビュー
- 学習すべきこと
- ソリューションインタビューの実施
- 歓迎
- ランディングページの提示
- 価格ページの提示
- 登録とアクティベーション
- まとめ
- 結果の文書化
- 顧客ライフサイクルの検証
- フィードバックを楽にする
- 試用期間中に問題を解決する
- ローンチの条件
- アーリーアダプターの行動
- UVPを明確に理解している
- 本サービスに登録する意志がある
- 価格モデルを受け入れている
- アクティベーションの流れを通り抜けている
- 好意的な推薦の声を提供している
- ローンチ
- 機能の押し売りはやめよう
- 製品/市場フィットの計測
- 人が欲しがるものを作る
- 反復プロセス
- コンバージョンダッシュボードの週次レビュー
- 目標とバックログの優先順位をつける
- 大胆な仮説を作る
- 機能追加/削除する
- 価値指標を監視する
- ショーン・エリスのテストをする
- 初期のトランクションの終了条件
- ユーザーの40%が定着した
- ショーン・エリスのテストを通過した
- 成長エンジンの特定
- 結論
- そして拡大へ
- あらゆるプロセスは人を増やすまではうまくいく
- 「キャズムを超える」ために
作成:まなたけ(@manatake_o)