3 Jari-Matti Latvala ja Miikka Anttila, FIN FIN, Ford World Rally Team Ford Fiesta RS WRC3 Jari-Matti Latvala ja Miikka Anttila, FIN FIN, Ford World Rally Team Ford Fiesta RS WRC / smerikal

Life’s too short to build something nobody wants.

(誰も欲しがらないものを作るほど人生は長くない)

『Running Lean』

構成

  1. Running Leanとは
  2. プロセス
  3. プランAを文書化する
  4. プランで最もリスクの高い部分をみつける
  5. プランを体系的にテストする
  6. 参考リンク
  7. 参考文献

Running Leanとは

顧客に何が欲しいかを聞くことはできない。

If I had asked people what they wanted,then would have said faster horse.

(顧客に欲しい物を聞いていたら、彼らは「もっと速い馬が欲しい」と答えていただろう。)

Henry Ford

適切な状況にいれば、顧客は自分の課題をはっきりと説明できる。

It is not the customer’s job to know what they want.

(欲しいものを知るというのは顧客の仕事ではない。)

Steve Jobs

顧客が本当に欲しい物を作るための方法論。

  • 顧客開発
  • リーンスタートアップ
  • ブートストラッピング

そして、具体的なプロセス。

Running Lean is a systematic process for iterating from Plan A to a plan that works, before running out of resources.

(Running Leanとは、リソースを使い切る前にプランAからうまくいくプランへと反復的に移行する体系的なプロセスです。)

『Running Lean』

Running Leanの方法論

runnig-lean-011 by Katuyuki Kakigi, on Flickr

  • プランAを文書化する
    • 顧客を考える
    • リーンキャンパスを作る
  • プランで最もリスクの高い部分を見つける
    • リスクの優先順位ををつける
    • ビジネスモデルインタビュー
  • プランを体系的にテストする
    • 課題を理解する
    • ソリューションを決定する
    • 定性的に検証する
    • 定量的に検証する

プロセス

runnig-lean-005 by Katuyuki Kakigi, on Flickr

プランAを文書化する

Running Leanを使えば最初のビジョンを体系的にテストして改善していくことが可能。最初の手順はビジョンを書き出して、少なくとも一人の人間と共有すること。

あなたの「製品」は製品では「ない」。 あなたの仕事は、最高のソリューションを構築するだけでなく、ビジネスモデルの全体像を把握して、各要素をうまくまとめること。 そして、ビジョンを実現するビジネスモデルの仮説を捕まえるためにリーンキャンパスを使う。 リーンキャンパスとは、ビジネスモデルを9つの部品に分解し、リスクの高いものから体系的にテストするもの。

リーンキャンパスの特徴

  • 高速性
  • 簡潔性
  • 携帯性

プランで最もリスクの高い部分をみつける

スタートアップの3つのステージ

runnig-lean-001 by Katuyuki Kakigi, on Flickr

  • 第1ステージ:課題/解決フィット(Problem/Solution Fit)

  • 第2ステージ:製品/市場フィット(Product/Market Fit)

  • 第3ステージ:拡大(Scale)

製品/市場フィットの前にピボット、それから最適化

runnig-lean-002 by Katuyuki Kakigi, on Flickr

最初の目標は、軌道修正(またはピボット)。次の目標は、効率化(または拡大)。 最も学習できるのは、期待する成果の見込みが50%の時です。つまり、何が期待できるかよくわからない時。

資金調達について

runnig-lean-003 by Katuyuki Kakigi, on Flickr

資金調達に適した時期は製品/市場フィット後。最初の目標は、ビジネスモデルを顧客とテスト・検証できるように、必要十分な滑走路を構築すること。

1
ブートストラッピング+リーンスタートアップ=低燃費スタートアップ

プランを体系的にテストする

検証による学習のループが実験

lean-startup-003 by Katuyuki Kakigi, on Flickr

イテレーションのメタパターン

runnig-lean-004 by Katuyuki Kakigi, on Flickr

プランAを文書化する

顧客を考える

いきなりソリューションを構築したり早い段階から顧客セグメントやビジネスモデルを選択することによる「選択バイアス」を回避するため最初から複数のモデルを同時にテストする。 まずは製品の見込み客のブレインストーミングから始める。

見込み客を考える

  • 顧客とユーザーを区別する。
  • 顧客セグメントを細かくわける。
  • 最初はすべてを一枚のキャンパスにまとめる。

リーンキャンパスを作る

リーンキャンパスをスケッチする

lean-canvas-001 by Katuyuki Kakigi, on Flickr

  • 一気にスケッチする。
  • 空欄があっても構わない。
  • 簡潔に書く。
  • 今わかる範囲で考える。
  • 顧客主導型を使う。

課題と顧客セグメント

lean-canvas-002 by Katuyuki Kakigi, on Flickr

  • 上位1〜3位の課題を挙げる
  • 既存の代替品を列挙する
  • ユーザーを特定する
  • アーリーアダプターに狙いを定める

UVP(独自の価値提案)

lean-canvas-003 by Katuyuki Kakigi, on Flickr

Unique Value Proposition: Why you are different and worth buying getting attention.

(UVP(独自の価値提案):あなたが他とは違っていて、対価を支払う注目する価値がある理由)

『Running Lean』

UVPの作り方

  • 変わったものにする。ただし、その違いが重要なものに限る。
  • アーリーアダプターをターゲットにする。
  • 成功ストーリーに注目する。
    効果的なUVPを作る公式

    即効性のある明快な見出し = 顧客が望む結果 + 明確な起源 + それが達成されなかった場合の代替案

  • 言葉をよく選んで使う。
  • 誰が・何を・なぜに答える。
  • 優れたUVPを調べてみる。
  • ハイコンセプトピッチを作る。
    ハイコンセプトピットをUVPと混同してはいけない。
    ハイコンセプトピットはランディングページで使うものではない。

ソリューション

lean-canvas-004 by Katuyuki Kakigi, on Flickr

  • 課題とソリューションの結合はできるだけ遅らせる。

チャネル

lean-canvas-005 by Katuyuki Kakigi, on Flickr

  • 無料と有料
  • インバウンドとアウトバウンド
    • インバウンドチャネル(プル型メッセージ)
      • ブログ
      • SEO
      • Ebook
      • 小冊子
      • オンラインセミナー
    • アウトバウンドチャネル(プッシュ型メッセージ)
      • SEM
      • 印刷広告やTV CM
      • 展示会
      • 営業電話
  • 直販と自動化
  • 直接と間接
  • 紹介の前に定着

収益とコスト構造

lean-canvas-006 by Katuyuki Kakigi, on Flickr

収益の流れ

  • 価格は製品の一部
  • 価格が顧客を決定する
  • 課金は最初の検証

コスト構造

  • 30〜50人にインタビューしてかかるコストは?
  • MVPを構築してローンチするのにかかるコストは?
  • 固定費と変動費の両面から見たバーンレート(資本金の消費率)は?

主要指標

lean-canvas-007 by Katuyuki Kakigi, on Flickr

海賊指標(AARRR)

aarrr-001 by Katuyuki Kakigi, on Flickr

  • 獲得
  • 活性化(アクティベーション)
  • 定着
  • 収益
  • 紹介

圧倒的な優位性

lean-canvas-008 by Katuyuki Kakigi, on Flickr

  • 内部情報
  • 正当な「専門家」の支持
  • ドリームチーム
  • その人の信頼性
  • 巨大なネットワーク効果
  • コミュニティ
  • 既存顧客
  • SEOランキング

最後に

大切なのは、リーンキャンパスを書き終えたあとに、最低でも誰か1人と共有すること。

プランで最もリスクの高い部分を見つける

リスクの優先順位をつける

可能性のあるビジネスモデルが複数できたら、次は優先順位をつける。
リスクの優先順位を間違えるのは最もムダなこと。

スタートアップのリスク

runnig-lean-009 by Katuyuki Kakigi, on Flickr

  • 製品リスク(P:Product risk)
    正しい製品を作る
  • 顧客リスク(C:Customer risk)
    顧客への経路を作る
  • 市場リスク(M:Market risk)
    実現可能なビジネスを作る

ビジネスモデルインタビュー

初期の学習は反復的かつ定性的なので、仮説の検証には時間がかかる。また、顧客セグメントが広すぎたり狭すぎたり、場合によっては間違った顧客セグメントをターゲットにしていることもある。 なのでまずリスクに優先順位をつけて、他のビジネスモデルの可能性を顧客以外の誰か(アドバイザーなど)と一緒にブレインストーミングする。「正しい」アドバイザーとは、「プラン全体」のリスクを特定してくれたり、モデルの改良やダメ出しを手伝ってくれるような人。「アドバイザー」に厳密な定義はない。

ビジネスモデルの比較

  1. 顧客の不満レベル(課題)
  2. 近づきやすさ(チャネル)
  3. 価格と粗利益(収益の流れとコスト構造)
  4. 市場規模(顧客セグメント)
  5. 技術的実現可能性(ソリューション)

外部の意見を求める

  • スライドを10枚以上にするのはやめる。
  • 20%を準備に、80%を対話に使う。
  • 具体的な質問をする。

実験の準備

課題チームと解決チームを作る

  • 小規模ではなく最小のチームで開始する。
  • 絶対に必要な3つの要素:開発・デザイン・マーケティング。
    • 開発
    • デザイン
    • マーケティング
  • 課題/解決チームの外部委託は慎重に。

効果的な実験

  • 速度・学習・集中を最大化する。
    • 速度と集中
    • 学習と集中
    • 速度と学習
  • 主要指標と目標を特定する。
  • 学習は必要な最も小さいことをやる。
  • 反証可能な仮説
    反証可能な仮説を作る公式

    反証可能な仮説 = 具体的で反復可能な行動 → 期待する計測可能な成果

  • 定性的検証と定量的検証
  • 結果を具体的な行動に結びつける
  • わかりやすいダッシュボードを作る
  • 学習を早めにしょっちゅう伝える

イテレーションのメタパターンをリスクに適用する

Your business model is not a dartboard

(ビジネスモデルはダーツのボードではありません)

『Running Lean』

  • ステージ1:課題を理解する
  • ステージ2:ソリューションを決定する
  • ステージ3:定性的に検証する
  • ステージ4:定量的に検証する

製品リスク:正しい製品を作る

runnig-lean-006 by Katuyuki Kakigi, on Flickr

  1. 解決に値する課題かどうか確認する。
  2. 最小限のソリューション(MVP)を決定する。
  3. MVPを構築して、小規模に検証する(UVPデモ)。
  4. 大規模に検証する。

顧客リスク:顧客への経路を作る

runnig-lean-007 by Katuyuki Kakigi, on Flickr

  1. 不満を持っている人を特定する。
  2. 製品を今すぐにほしいと思うアーリーアダプターに範囲を狭める。
  3. アウトバウンドチャネルから開始しても構わない。
  4. ただし、少しずつ拡大可能なインバウンドチャネルも構築/開発する。早ければ早いほどよい。

市場リスク:実現可能なビジネスを作る

runnig-lean-008 by Katuyuki Kakigi, on Flickr

  1. 既存の代替品から競合他社を特定し、ソリューションの価格を設定する。
  2. 顧客の声を聞いて、価格をテストする(口約束)。
  3. 顧客の行動を見て、価格をテストする。
  4. ビジネスモデルがうまくいくように、コスト構造を最適化する。

プランを体系的にテストする

課題を理解する

顧客インタビューの準備

  • ビッチーではなく学習を中心に考える。
  • 顧客に何が欲しいのかを聞いてはいけない。行動を観察する。
  • 台本に合わせて会話をする。
  • 網を広く投げる。
  • 直接面会してインタビューする。
  • 知り合いから始める。
  • 誰かと一緒に行く。
  • 中立的な場所を選ぶ。
  • 十分な時間をもらう。
  • 謝礼や贈り物をしないようにする。
  • インタビューを録音しないようにする。
  • インタビュー後すぐに文書化する。
  • 30〜60人にインタビューする。
  • インタビューのスケジュール調整を委託する。

見込み客を見つける

  • 近しい人から始める。
  • 紹介をお願いする。
  • 地元で探す。
  • 予告ページで探す。
  • 予告ページでメールアドレスを登録してもらう。
  • 何らかの形でお返しをする。
  • 電話・メール・LinkedInを使って依頼する。

課題インタビュー

学習すべきこと

  • 製品リスク:何を解決するのか?(課題)
  • 市場リスク:競合は誰なのか?(既存の代替品)
  • 顧客リスク:誰が困っているのか?(顧客セグメント)

課題インタビューの実施

  1. 歓迎
  2. 顧客情報の収集
  3. ストーリーの伝達
  4. 課題の優先順位
  5. 顧客の世界観の探求
  6. まとめ
  7. 結果の文書化

課題インタビューの終了条件

  • アーリーアダプターとなる顧客が特定できた。
  • 「絶対に必要」な課題が見つかった。
  • 現在の顧客の解決方法がわかった。

ソリューションを決定する

学習すべきこと

  • 顧客リスク:誰が困っているのか?(アーリーアダプター)
  • 製品リスク:課題をどのように解決するのか?(ソリューション)
  • 市場リスク:どのような価格モデルにするのか?(収益の流れ)

デモを構築する

  • デモは実現可能でなければならない。
  • デモは本物に見えなければならない。
  • デモは高速に反復する必要がある。
  • デモはムダを最小化にする。
  • デモは本物に見えるデータを使わなければならない。

ソリューションインタビュー

価格のテスト

  • 価格のことは顧客に聞かず、ただ伝えるだけ。
  • 登録の障壁を下げずに上げる。
  • ソリューションインタビューのAIDA
  • ピットどこが違うのか
  • テスト可能な仮説

ソリューションインタビューの実施

  1. 歓迎
  2. 顧客情報の収集
  3. ストーリーの伝達
  4. デモ
  5. 価格の検証
  6. まとめ
  7. 結果の文書化

ソリューションインタビューの終了条件

  • アーリーアダプターの顧客情報が特定できた。
  • 「絶対に必要」な課題がわかった。
  • 課題を解決するのに必要な最小限の機能が定義できた。
  • 顧客が支払ってくれる価格がわかった。
  • (概算で)うまくいきそうなビジネスが構築できた。

MVPを構築する

バージョン1.0をリリース

  • 製品開発は学習の邪魔
  • MVPの縮小化
  • 継続的デプロイを始める

アクティベーションの流れを定義する

  • 登録の障害は下げても学習の犠牲にしてはいけません。
  • 手順を減らしても学習を犠牲にしてはいけません。
  • UVPを届けましょう。
  • うまくいかなかったときのことを考えておきましょう。

マーケティング用のサイトを構築する

  • マーケティング用のサイトの解剖
    • 概要ページ
    • サービス利用規約とプライバシーポリシーページ
    • 製品ツアーページ(動画やスクリーンショット)
  • ランディングページの分解
    • 独自の価値提案
    • ビジュアルの支援
    • 明確な誘導
    • もっと詳しく知るための情報
    • 社会的証明

定性的に検証する

ダッシュボードを構築する

計測の準備

  • 行動につながる指標が必要
  • 指標は人が重要
  • 単純なファンネルレポートは十分ではない
  • コホートによろしく

コンバージョンダッシュボードの作り方

データの収集方法
  • 指標とイベントを一致させる。
  • 生のイベントを監視する。
  • すべてのログをとる。
コンバージョンダッシュボードの可視化方法
  • ファンネルを掘り下げる。
  • 数字の理由を調べる。
定着の追跡方法
  • アクティブユーザーの定義する。
  • コンバージョンダッシュボードの定着を可視化する。
  • 詳細なビューを提供する。

MVPインタビュー

学習すべきこと

  • 製品リスク:製品の魅力は何か?(独自の価値提案)
  • 顧客リスク:十分な顧客はいるか?(チャネル)
  • 市場リスク:価格は適正化?(収益の流れ)

テスト可能な仮説

MVPインタビューの実施

  1. 歓迎
  2. ランディングページの提示
  3. 価格ページの提示
  4. 登録とアクティベーション
  5. まとめ
  6. 結果の文書化

UVPを実現する

顧客ライフサイクルを検証する

フィードバックを楽にする

The fastest way to learn from customers is to talk to them.

(顧客から学習する近道は、顧客に話しかけることです)

『Running Lean』

  • 気にかけていることが伝わる。
  • 問い合わせが多すぎるという問題はない。
  • テクニカルサポートは継続的な学習のフィードバックループ。
  • テクニカルサポートは顧客開発。
  • テクニカルサポートはマーケティング。
  • 投票ツールによるフィードバックは使わない。

試用期間中に問題を解決する

獲得とアクティベーション
  • 優先事項:学習できるだけのトラフィックを稼ぐ。
    • ファンネルを掘り下げる。
    • ユーザーに連絡する。
    • 予期しないエラーをキャッチして通知する。
定着
  • 優先事項:試用期間中にユーザーに戻ってきてもらって、製品を使ってもらう
    • 丁寧なリマインダーを送信する。
    • インタビュー相手に協力を求める。
収益
  • 優先事項:お金をはらってもらう
    • 決済システムを実装する。
    • 支払った顧客に電話する。
      • この製品をどのようにして知りましたか?(あなたが知らない場合)
      • この製品をなぜ購入しようと思いましたか?
      • 何か改善できる点はありますか?
    • 「売り損ねた」見込み客に話を聞きましょう。
紹介
  • 優先事項:推薦の声をもらう
    • 推薦の声をお願いする。

ローンチの準備はできましたか?

  • 結果を頻繁にレビューする。
  • 最も重要な課題から着手する。
  • 可能な限り小さなことをやる。
  • 確実に改善する。
  • コンバージョンダッシュボードを監視する。

ローンチ条件

  • 独自の価値提案(UVP)を明確に理解している。
  • 本サービスに登録するつもりがある。
  • 価格モデルを受け入れている。
  • アクティベーションの流れをうまく通り抜けている。
  • 好意的な推薦の声を提供してくれる。

3・2・1・・・・ローンチ!

学習に「ちょうど十分」なトラフィックを獲得するのが目的。

定量的に検証する

機能を制限する

機能は押し付けずに引っ張ってもらう

  • 追加機能は独自の価値提案(UVP)を薄める。
    シンプルな製品ならシンプルに理解できる。
  • すぐにMVPに見切りをつけてはいけない。
  • 機能には隠れたコストがある。
  • 顧客は本当に欲しい物をわかっていない。

80/20ルールを実施する

機能の流れを制御する

かんばんボード(見える化ボード)を使う。 コンバージョンダッシュボードを指標の追跡に使うように、かんばんボードは機能の追跡に使う。どちらもマクロ的視点に焦点を当てている。

  1. バックログ
  2. 既存機能の改善(例:登録の流れの改良)
  3. 顧客の機能要求
  4. 自分たちの機能要求(例:あとでやることにした「あればうれしい」機能)
  5. MMF(市場価値最小限の機能:Minimum Marketable Feature)単位
  6. MMFは小さな作業項目(タスク)で構成されている。
  7. タスクのバッチとなる小さな機能・バグ修正・作業項目についてはタスクボードで管理する。
  8. 作業中
    かんばんの大切な原則は、作業中の機能数を制限すること。
  9. 完了
  10. 検証による学習

機能要求を処理する

  1. 作業の必要性や優先順位を確認する。
  2. それが小さな機能やバグ修正なのか、より大きなMMFなのかを判断する。
  3. 小さな作業項目かつ緊急ならすぐ対応する。
  4. そうでなければタスクボードのバックログに追加する。
  5. MMFならばカンバンボードのバックログに追加する。

機能ライフサイクル

かんばんボードで機能を追跡する
  • 目標
  • 仕掛品の上限
  • バッファレーン
  • 機能はいつでも中止可能
  • 継続的デプロイ
  • 2段階検証
各手順の説明
  • 課題を理解する
    1. バックログ
    2. 顧客からの要望
    3. 内部からの要望
  • ソリューションを決定する
    1. モックアップ
    2. デモ
    3. コード
  • 定性的に検証する
    1. 部分的展開
    2. 定性的検証
  • 定量的に検証する
    1. 全面展開
    2. 定量的検証

進捗を計測する

製品/市場フィットとは

Product/Market fit means being in a good market with a product that can satisfy that market.
(製品/市場フィットとは、市場を満足できる製品がある状態のことだ。)
You can always feel when product/market fit isn’t happening. The customers aren’t quite getting value out of the product,word of mouth isn’t spreading, usage isn’t growing that fast,press reviews are kind of “blah,” the sales cycle takes too long, and lots of deals never close.
(製品/市場フィットがないとすぐわかる。製品の価値が顧客に伝わらない。口コミが広がらない。利用が加速しない。メディアの評判は「最低」。販売サイクルに時間がかかる。商談がまとまらない。)
And you can always feel product/market fit when it’s happening.The customers are buying the product just as fast as you can make it – or usage is growing just as fast as you can add more servers. Money from customers is piling up in your company checking account.You’re hiring sales and customer support staff as fast as you can.Reporters are calling because they’ve heard about your hot new thing and they want to talk to you about it.
(製品/市場フィットがあるとすぐわかる。製品を作ると顧客が買いに来る。サービスを追加すると利用が拡大する。銀行口座にお金がたまる。営業や顧客サポートのスタッフが雇える。記者から新製品のことを聞きたいと電話がかかってくる。)

Marc Andreessen,“The Pmarca Guide to Startups”

初期のトラクションを達成する

ショーン/エリスのテスト

40%以上のユーザーが「非常に残念」と答えたのであれば、この「絶対に必要」な製品は今後も継続的に顧客を獲得できる。

1
2
3
4
5
【製品名】が使えなくなった時にどう思いますか?
  1.非常に残念
  2.少し残念
  3.残念ではない(役に立たなかった)
  4.すでに【製品名】をつかっていない

アンケート調査は、学習より検証に効果的。

「適切な」マクロ指標に集中する

アクティベーションの済んだユーザーが毎日40%以上いれば、初期のトラクションがあるといえる。

人が欲しがるものを作ったか

  1. コンバージョンダッシュボードを毎週レビューする。
  2. 目標とバックログの優先順位をつける。
  3. 大胆な仮説を作る。
  4. 機能を追加/削除する。
  5. 価値指標を監視する。
  6. ショーン・エリスのテストを実施する。
初期トラクションの終了条件
  • ユーザーの40%が定着した。
  • ショーン・エリスのテストを通過した。

製品/市場フィットにおける市場

初期のトラクションを実証する前に、ビジネスの拡大に集中するのはムダ

成長エンジンの特定
  • 粘着型:高い定着率
    解約率とは、製品を使わなくなって一定期間がたった顧客の割合。
    「顧客獲得率>解約率」であれば、ビジネスが成長していると言える。
  • ウィルス型:高い紹介率
    ウィルス係数とは、顧客1人あたりの紹介数を計測したもの
    「ウィルス係数>1」(顧客が最低1人以上紹介している)であれば、ビジネスが成長していると言える。
  • 支出型:高い利益率
    「顧客生涯価値(LTV:Life Time Value) > 顧客獲得コスト(COCA:Cost of Customer Acquisition)」を続けているのであれば、ビジネスが成長していると言える。

  • 成長エンジンを選択するガイドライン

    1. 価値指標の検証から着手する。
    2. 顧客の製品に対する態度を理解する。
    3. 調整するエンジンを選択する。

まとめ

ネットワーク効果のある製品のデザインパターン
  • 注目は換金可能な資産。
  • 定着は王様。
  • 成長エンジンはウィルス型。
マルチサイド(マーケットプレイス)製品のデザインパターン
  • 両サイドのキャンバスを作る。
  • アーリーアダプターのマーケットプレイスで価値を検証する。
  • 仲介処理は自動化しない。
  • 両サイドに適切な成長エンジンを選びましょう。

拡大する

runnig-lean-010 by Katuyuki Kakigi, on Flickr

Every process works well until you add people.
The key is to build a continuous learning culture of experimenters versus specialist, where it’s everyone’s job to be accountable toward creating and capturing customer value.

(あらゆるプロセスは、人を増やすまではうまくいくのです。
したがって、各自が専門家になるのではなく、実験を通じた継続的な学習の文化を作ることが大切になります。つまり、顧客価値の創造や理解は、みんなの責任ということです。)

『Running Lean』

参考リンク

外部から資金調達をしない「ブートストラッピング」という起業スタイル

参考文献