RUNNING LEAN
RUNNING LEANを読んだので備忘録として残す。
Running Lean ―実践リーンスタートアップ (THE LEAN SERIES)
- 作者: アッシュ・マウリャ,渡辺千賀,エリック・リース,角征典
- 出版社/メーカー: オライリージャパン
- 発売日: 2012/12/21
- メディア: 単行本（ソフトカバー）
- 購入: 3人 クリック: 14回
- この商品を含むブログ (19件) を見る
著者はAsh Maurya。
そもそもこの本はブログに顧客開発やリーンスタートアップについて書いていたのをまとめた書籍。
リーンスタートアップの実践的な手法のガイドという立ち位置。
なお、THE LEAN SERISというエリック・リースがキューレーターを務める企画？の1冊目。
イントロダクション
- 製品の構築コストは下がったが、スタートアップが成功する確率は上がっていない
- スタートアップの多くは失敗している
- 成功したスタートアップの2/3は当初のプランを途中で大幅に変更している
- 当初のプランが優れていたのではなく、リソースを使い切る前にうまくいくプランを見つけた
- Running Leanはリソースを使い切る前に、プランAからうまくいくプランへと反復的に移行するプロセス
- 顧客の要求を収集後、リリースまで顧客から離れる
- この離れている期間が問題
- 車を作る際に顧客に要望を聞いていたら「速い馬が欲しい」と答えていただろう
- つまり、顧客から本当に欲しいものを聞き出すのは難しい
Running Leanとは
- 速度・学習・集中
- 顧客の行動を計測して、ビジョンをテストする
- 製品開発サイクルを通じて、顧客と関係を築く
- 短いイテレーションで製品と市場の検証を同時に行う
- 規律のある厳格なプロセス
- 数々の方法論や思想家を参考にしている
顧客開発
- スティーブ・ブランクが作った
- 製品開発サイクルにあわせて、顧客との継続的なFBループを構築する
リーンスタートアップ
- エリック・リースが提案
- 顧客開発とアジャイルソフトウェア開発とリーン手法を統合したもの
- リーンは無駄を省くという意味
- 単位時間あたりの顧客に関する学習量の最大化が目的
ブートストラッピング
- ビジョイ・ゴスワミが提唱
- 顧客からの収益で資金をまかなうという意味
メタ原則
- 原則は何をするか導く
- 戦術はどうするか示す
プランAを文章化する
- 強いビジョンと実現するプランAがあるが、ビジョンは信念で裏付けされている
- ビジョンを事実で裏付けする必要がある（ビジョンはテストされていないので
- 最初にすることはビジョンを書き出して、誰かと共有をする
- 1枚にすべてが収まるリーンキャンバスがおすすめ
- 数時間で書ききることができる
- 短い文章で書く必要があるので、本質が抽出できる
- 1ページなので共有も楽
- ソリューションの面積は1/9しかない
- 起業家はソリューションに目を向けがちだが、顧客はソリューションには興味がない
- 最高のソリューションを作るのではなく、ビジネスモデルの全体を把握しまとめることが大事
- ビジネスモデル自体を製品と扱う
- リーンキャンバスとはビジネスモデルを9つの部品に分解し、各項目をテストするもの
プランで最もリスクの高い部品を見つける
- ソリューションは基本的に最もリスクの高いものではない（製品はなんとか作ることができる
- 最も大きいリスクは「誰も欲しくないものを作る」こと
- 「課題・解決フィット」→「製品・市場フィット」→「拡大」
課題・解決フィット
- 解決に値する課題はあるか？
- それは顧客が必要としているか？
- 顧客は金を払うか？誰が金を払うのか？
- 解決可能か？
製品・市場フィット
- 必要とされるものを構築したか？
- MVPがどれだけ解決しているかテストする
拡大
- どうやって成長を加速させるのか？
ピボットと最適化
- 「課題・解決フィット」、「製品・市場フィット」と「拡大」で分ける
- ピボットとは学習し方向性を変更すること
- 最適化はプランを加速すること
- 最も学習できる状態は50%の状態
- そのため大胆な成果を狙って学習をするべき（小さいテストは後で
プランを体系的にテストする
Running Leanの実例
- この書籍を書いたときの例
いかにして書籍を執筆反復したか
- 何人かに本を書いてと言われたが無視していた
- たくさん言われ始めたので本を書くことを考えた
- 読者に電話をして、どうして本を書いほしいか聞いた
- 本書のUVP(独自の価値提案)を理解する
- 顧客開発・リーンスタートアップの実践に苦労している人が多い（課題）
- ブログを段階的なガイドとして読んでいる（ソリューション）
- webの製品を開発している（アーリーアダプター）
- 目次と書名と書影のサイトを構築
- 本のリスクの高いところは目次
- 顧客に目次を聞いてFBもらって、目次を改良した
- しかし顧客が10人くらいなので、ブログで告知した（解決に値する課題ではなかった）
- 1000個のメアドが集まったので、先に進むことを決めた
- ブログのコピペをしようとしたが満足できるものにはならなかった
- 目次をもとにワークショップを3回行い、中身を改良していった
- 2週間ごとに2章ずつPDFでリリースする方式をとった
- 半分は好きな端末で読みたがっていた
- しかし、半分（アーリーアダプター）は同意した
- 2週間ごとにリリースし、FBをもらい、推敲して誤字を修正していった
- 実際に1000人くらいに売れてから、出版社からお金をもらい、出版した
リーンキャンバスの作成
見込み客を考える
- 最初はぼんやりとしたアイデアしかない
- この時点で製品を作ったり、ビジネスモデルを決めるのは危険
- 複数のモデルを同時にテストしていく
- 顧客はお金を払うが、ユーザーはお金を払わない
- 顧客のセグメントを細かく分ける
- 最初は一枚のリーンキャンバスを書く
- その後に顧客セグメントごとにリーンキャンバスを書く
リーンキャンバスをスケッチする
- 一気にスケッチする（15分以内くらい）
- 正しいことを書こうと議論するより、適当に書くか、空欄にする
- リスクが高いことがわかる
- 短く書く
- 現在の分かる範囲で書く
- リーンキャンバスの書き方は顧客主導型で
- ターゲットとなる顧客セグメントに対して、課題を1~3位まで書く
- もしくは、顧客に必要なジョブ（作業）の観点から課題を考える
- 代替品を列挙する（オンラインコラボツールの代替品はEメール）
- ユーザーを特定する
- UVPを決める
- ソリューションはゆるく書く
- 課題とソリューションの統合はできるだけ遅らせる
- チャネル（顧客への経路）
- 収益の流れは最初から考える
- 学習時は大勢の顧客はいらない
- 課金のシステムを考えているなら最初から実装して課金させるべき
- 価格は製品の一部（似たような水でも高いほうが品質が良いと感じてしまう）
- 価格が顧客を決める
- 課金は難しい行為だが、早めに検証ができる
- コスト構造をリストにする
- 主要指標はAARRRで見る
- 獲得(Acquisition)は何も知らない訪問者が、見込み客になった時点を表す
- 花屋なら店に入ること
- ウェブサイトは登録ページを見た訪問者と定義（サイト次第
- アクティベーション(Activation)は見込み客が満足の行くユーザー体験をした時点を表す
- 花屋なら入った後店がしょぼかったら駄目
- ウェブサイトは使ってみて期待（UVP)と製品を結びつける
- 定着(Retention)は製品の反復利用
- 花屋ならまた来る、サイトならまた来る
- 収益(Revenue) は課金イベント
- 花の購入やウェブなら製品の申し込み
- 紹介(Referral)は口コミとか
- 圧倒的優位性は最も難しい
- 機能数とかは関係ない
- 先行性もあまり関係ない
- コピーする価値あるものはコピーされる
- 本当に優位性のあるものはコピーされずらい
- 内部情報、専門家の支持、ドリームチーム、信頼性、巨大なネットワーク、コミュニテイ、既存顧客、SEO
ビジネスモデルの優位性
- リスクの優先順位を間違えるのは最も無駄
リスクとは
- 不確実は複数の結果が存在する状態
- リスクは好ましくない状態になりえる不確実な状態
- 機会費用と実質費用の両面から数値化し、優先順位をつける
- 本の場合は価格がリスクではない
- 良い本を書けば買われないリスクは下がる
- なのでリスクは顧客が欲しい良い本が書けるか否か
- 製品リスク：正しい製品を作る
- 顧客リスク：顧客への経路を作る
- 市場リスク：実現可能なビジネスを作る
- 計測や定量化は確率統計的手法を利用
- インタビューなど定性的計測はダグラスハバードがおすすめ
ビジネスモデルの比較
- 十分に大きな市場を持ち、製品の周りにビジネスを構築でき、必要とする顧客に近づけるビジネスモデルを見つけるのが目的
- 顧客の不満レベル（課題）
- 顧客セグメントに優先順位をつける
- 近づきやすさ（チャネル）
- 価格と粗利益（収益の流れとコスト）
- 市場規模（顧客セグメント）
- 技術的実現可能性（ソリューション）
- いろいろな顧客セグメントごとにリーンキャンバスを書いて、どの顧客セグメントから検証するか決める
- 決定したら誰かに見てもらう（アドバイスを鵜呑みにしてはいけない
- リーンキャンバスを見てもらおう
- 2割説明して残りは聞き出すのに時間を使う
- 最もリスクが高いと思われるのはどこか？
- 似たようなリスクを克服したことはありますか？
- リスクをどうやってテストしますか？
- 他に話を聞いたほうがいい人はいますか？
実験の準備
課題チームと解決チームを作る
- 部署をぶち抜く
- 課題チームはユーザーインタビューやユーザビリティテストなど
- 解決チームは開発・テスト・リリース
- メンバーが重なっても良い
- 1つのチームで両方の役割を担っても良い
- 顧客とのやり取りは全員の責任
- 小規模でなく最小でチームを作る
- コミュニケーションが楽でコストが低い
- 課題と解決のバランスが大事
- 開発・デザイン・マーケの3つがチーム作りで必要
- 基本外部委託しないほうがいい
効果的な実験
- 最適な実験をするには、速度・学習・集中が必要
- 速度と集中しかないと高速に学びのないところをぐるぐる回るだけになる
- 学習と集中しかないと速度がないのでリソースを使い切ってしまう
- 速度と学習しかないと早すぎる最適化をしてしまう（製品がないのにLPを最適化したり
- 実験するときは1つの指標と目標にする
- 反証可能な仮説にする（間違いがはっきりわかる文）
- あいまいな仮説「専門家になってアーリーアダプターを集める」
- 反証可能な仮説「ブログに投稿して100人集める」
- 最初は強いシグナルを受け取る（5人の顧客のインタビューで十分）
- 肯定的な意見は仮説を定量的データで検証してもいいということ（定性的から定量的へ）
- 計測結果を具体的で反復可能な行動に結びつけて製品を変更するのは難しい
- インタビューはパターンが見えるまで同じ方法を繰り返す
- 定量的検証はコホート分析やスプリットテストなどを使う
- わかりやすいダッシュボードを作る
- コンバージョンダッシュボードとリーンキャンバスなどを1つのダッシュボードで管理する
イテレーションのメタパターンをリスクに適用する
- 中途半端な学習や否定的な学習でやる気を無くす
- 肯定的な学習から楽観的になってしまう
- 正しい製品かつ拡張性のあるビジネスモデルを作るのが大事
- 学習自体を目的に実験せず、目標のための実験にしていく必要がある
- 単位時間あたりの学習量（どのリスクが高いか）を最大化する
- 課題を理解→ソリューションを決定→定性的に検証→定量的に検証
- 製品リスク：正しい製品を作る
- 解決に値する課題かどうか確認する
- MVPを決める
- MVPを構築し、小規模に検証する（UVPのデモ）
- 大規模に検証をする
- 顧客リスク：顧客への経路を作る
- 不満を持っている人を特定する
- 製品を今すぐ欲しいと思うアーリーアダプターに範囲を狭める
- アウトバウンドチャネル等から始める
- インバウンドチャネルの構築
- 市場リスク：実現可能なビジネスを作る
- 既存の代替品から価格を設定する
- 顧客の声を聞いて価格をテストする（口約束）
- 顧客の行動を聞いて価格をテストする
- コスト構造を最適化する
顧客インタビューへの準備
学習するには顧客と話すこと。
アンケート調査もフォーカスグループも不要
- アンケートは正しい質問があることが前提
- 正しい質問を作るのは難しい
- 顧客インタビューとは何がわからないのさえわからないことの探求
- アンケートは正しい答えがあることが前提
- 正しい答えの選択肢を用意するのが必要
- 最初は「自由回答形式」の質問を使って学習する
- アンケートはボディランゲージが見えない
- フォーカスグループは「集団思考」を形成してしまうのが問題
- アンケート調査は顧客インタビューから学習したことを検証するのに効果的
- 統計的有意性の実証に使う
人と会話するのは難しい
- ピッチではなく学習を中心に考える
- ピッチの問題点は顧客が「正しい」製品の知識を持っている前提になっていること
- 「正しい」ソリューションの前に、「正しい」課題を理解する必要がある
- 顧客に何が欲しいか効かず、行動を観察する
- 嘘つくかもしれないし、儀礼的に答えることもあるので、インタビュー中に行動から言葉を検証する
- 口約束ではなく行動を示す（課金など
- 台本に合わせて会話をする
- 広く網を広げて局所化を防ぐ
- サンプルを厳選するのではなく、結果から厳選をする
- インタビューは直接会うこと
- いきなり知らない人でなく、知り合いから始める
- 誰かと一緒に行って、第三者目線を取り入れる
- コーヒーショップなど中立的な場所でやる
- 謝礼などはしない（お金を払う客を見つけるのが目的なので）
- 録音をすると自意識過剰になったりするので、録音は基本無しで
- インタビュー後すぐに文章化をする
- 4~6週間で30~60人インタビューをする
- スケジュール調整は無駄な作業なので委託しよう
見込み客を探す
- 知人バイアスがかかるが、誰とも話さないよりはいいので知人から
- 紹介による顧客探し
- 親近感は大切なので地元で探す
- 予告ページでメアドを登録してもらう
先制攻撃と反論
- 顧客インタビューに対する反対意見
- 顧客は自分の課題を把握していない
- 数10人と話しても統計的に有意がない
- 定量的指標で十分
- 自分が顧客だから、誰かと話す必要はない
- 友達が良いねと言っている
- 週末でなにか作れるのに、インタビューする必要はあるのか
- すでに課題を把握しているからテストは不要
- 課題がわからないのでテストができない
- 誰かにアイデアを盗まれる
課題インタビュー
学習すべきこと
- 製品リスク：何を解決するのか？
- 市場リスク：競合は誰なのか？
- 顧客リスク：誰が困っているのか？
課題のテスト
- 最初は課題に対する顧客の反応を計測すること
- 現時点で解決できているか？どのように解決しているのか？
反証可能な仮説
- 反証可能な仮説 = 具体的で反復可能な行動 → 期待する計測可能な成果
課題インタビューの実施
- 歓迎、顧客情報の収集、ストーリーの伝達、課題の優先順位、顧客の世界観の探求、まとめ、結果の文章化
- 歓迎：インタビューの流れを簡単に説明する
- 顧客情報の収集：アーリーアダプターを選定するために、顧客情報に関する基本的な質問をする
- ストーリーの伝達：上位の課題をストーリーで説明する
- 課題の優先順位：課題を1 ~ 3つ選んで、見込み客に優先順位をつけてもらう
- 顧客の世界観の探求：インタビューの中心
- まとめ：引き続き興味を抱いてもらえるようなフックを提供と今後の協力のお願い
- 結果の文章化：記憶が新しいうちに文章化する
課題を理解していますか？
- 結果を週次でレビューする
- アーリーアダプターから始める
- 最も賛同してくれる顧客セグメントを特定する
- 課題を洗練する
- 必要ないというシグナルを受け取ったら削除して、絶対に必要と受け取ったら追加する
- 既存の代替品を理解する
- アーリーアダプターは既存の代替品と比較する
- 顧客が使う言葉に注目する
- UVPの鍵となる単語は顧客の言葉に耳を傾ける
- 最低10人にインタビューをして下記が可能になれば終了してもよい
- アーリーアダプターとなる顧客が特定できた
- 「絶対に必要」な課題が見つかった
- 現在の顧客の解決方法がわかった
ソリューションインタビュー
- 製品を作る前にデモを使ってソリューションのテストをする
学習すべきこと
- 顧客リスク：誰が困っているのか？
- 製品リスク：課題をどのように解決するのか？
- 市場リスク：どのような価格モデルにするのか？
ソリューションのテスト
- デモは実現可能でなければいけない
- デモを最終的な製品で使用しない技術を使って作ってはいけない
- デモは本物に見えないといけない
- デモは高速に反復する必要がある
- インタビューの結果をすぐデモに反映して、次のインタビューでテストできるようにする
- デモは無駄を最小化する
- デモは本物に見えるデータを使う
- デモはYotutubeとかに出しても良い
価格のテスト
- 価格のことは顧客に聞かず、ただ伝えるだけ
- 適正な価格は説得することができる
- 価格は顧客セグメントを定義するもの
- 登録の障壁を下げずに上げる
- 希少性：どっちつかずな100社より、やる気のある10社に注力をする
- アンカリング：価格は相対的だが、新しいカテゴリの製品は別の製品と比較して安く見せる
- ソリューションインタビューのAIDA
- 認知（Attention）：効果的に認知を集めるためには、顧客の課題を突きつける
- 興味（Interest）：デモを使って興味を引く
- 欲求（Desire）：欲求は段階的に引上げる
- 行動（Action）：製品に対する口約束・書面の契約・前払い金をとりつける
- ピッチは「オール・オア・ナッシング」の提案
- フレーミングは仮説を使って顧客の反応を引き出す
ソリューションインタビューの実施
- 既存の見込み客にお願いする
- 課題インタビューのときに今後の協力を依頼しておく
- 新規の見込み客を入れる
- 歓迎、顧客情報の収集、ストーリーの伝達、デモ、価格の検証、まとめ、結果の文章化
解決に値する課題はあったか
- 機能を追加・削除する
- 抵抗がなければ価格を上げる
- ソリューションインタビューは以下の革新が持てたら終了
- アーリーアダプターの顧客情報が特定できた
- 「絶対に必要」な課題がわかった
- 課題を解決するのに必要な最小限の機能が定義できた
- 顧客が支払ってくれる価格がわかった
- （概算で）うまくいきそうなビジネスがわかった
バージョン1.0をリリース
製品開発は学習の邪魔
- 開発やQAは学習できていない
- リリースまでのサイクルを短くして学習を加速させる
MVPの縮小化
- MVPのスコープを減らすということは、製品メッセージを希釈する不純物を取り除く
- 白紙から始める：機能を追加するたびに正当性を検討する
- 最上位の課題から着手する
- 「あれば嬉しい」「必要ない」機能は削除する
- 初日から課金するようにする（ただし、徴収は30日後）
- 最適化ではなく学習に集中をする
- 継続的デプロイ
アクティベーションの流れを定義する
- 顧客がサービスに登録をしてから最初の体験に満足するまでの道筋
- 顧客に速くUVPを体験してもらうこと
- 登録の障壁を下げても学習を犠牲にしてはいけない
- 手順を減らしても学習を犠牲にしてはいけない
マーケティング用のサイトを構築する
- 売るのを目的とする
- 最初の8秒が大切
- 概要ページで「会社」から製品を購入する理由を作る
- 利用規約プライバシーポリシー
- 製品ツアーページ（スクショなど
計測の準備
- 顧客ライフサイクルは可視化するだけでなく、計測できる必要がある
行動につながる指標
- 製品/市場フィット前の目的は、CVの最適化ではない
- 顧客ライフサイクルにおけるホットスポットの特定と、その解決
- インタビューなどでは、顧客の声に耳を傾けたが、これからは顧客の行動を計測する
- 行動につながる指標 = 観測結果を具体的で反復可能な行動につなげるもの
- DL数やPVは製品の現状を表すが、単体では次に何をすればいいかわからない
- これらは、計測対象ではなく、計測方法
指標は人が重要
- 評価尺度の実態は人である
- 数字の裏にいる人に話しかける必要がある
- 理想的なCVダッシュボードは、分析とカスタマーリレーションシップマネジメント（CRM）を併せ持つ
- 指標はそれ単体では何も説明しない
- 指標はどこが間違っているか教えるが、なぜ間違っているかは教えてくれない
- ユーザーの方からやってくることはない
- ユーザーはソリューションを丁寧に見てはいない
- うまくいかないことがあれば、すぐ不信感を抱いて、興味を失う
- すべての指標は等価ではない
- 多くのユーザーやBOTが来るので、指標を異なるバケツに分ける必要がある
単純なファンネルレポートは十分ではない
- ファンネルレポートはLPのCVのようなミクロレベルに適している
- 6月の、獲得、アクティベーション、収益のCVファンネルレポートがある場合
- 収益は5月の数値になるので、歪みが出る
- 7月の登録数が減ると、CVRがあがるかもしれない
- 新機能のリリースなどと結びつけるのが難しい
- いずれのファンネル分割が発生する
コホート
MVPインタビュー
- MVPの販売の前にアーリーアダプターに直接販売をして、デザインや価格などを改良する
学習すべきこと
- アーリーアダプターに20分インタビューで説得できないのであれば、LPに来た訪問者を8秒で説得できない
- 製品リスク：製品の魅力はなにか？（独自の価値提案）
- 顧客リスク：十分な顧客はいるか？
- 価格は適正か？
MVPインタビューの実施
- 歓迎、LPの提示、価格ページの提示、登録とアクティベーション、まとめ、結果の文章化
顧客ライフサイクルの検証
フィードバックを楽にする
- 顧客から学習する近道は、顧客に話しかけること
- 気にかけていることが伝わる
- 問い合わせが多すぎるという問題はない
- テクニカルサポートは継続的な学習のフィードバックループ
- テクニカルサポートは顧客開発
- テクニカルサポートはマーケティング
- 投票ツールによるフィードバックは使わない
試用期間中に問題を解決する
- 試用期間は顧客ライフサイクルを制限できる
- 試用期間の最初の目的は離脱を減らす、次に定着やエンゲージメント、課金
獲得とアクティベーション
- 優先事項：学習できるだけのトラフィックを稼ぐ
- ファンネルを掘り下げる
- どこかで離脱をしていないか？パターンを探す
- 離脱したユーザーをリストで持っておき、分析をする
- よきせずエラーをキャッチして通知させる
定着
- 優先事項：試用期間中にユーザーに戻ってきてもらって、使ってもらう
- 丁寧なリマインダーを送信する（メールなど）
- インタビュー相手に協力を求める
収益
- 優先事項：課金
- 決済システム
- 支払った顧客に電話をする
- （売りそこねた）見込み客に話を聞きに行く
紹介
- 優先事項：推薦の声をもらう
ローンチの準備
- 結果を頻繁にレビューする
- 最も重要な課題から着手する
- 可能な限り小さなことをやる
- 確実に改善する
- コンバージョンダッシュボードを監視する
ローンチ条件
- アーリーアダプターの80%がコンバージョンファンネルをうまく抜けたらOK
機能の押し売りをやめよう
機能は押し付けず引っ張ってもらう
- 追加機能は独自の価値提案（UVP）を薄める
- すぐにMVPに見切りをつけてはいけない
80/20ルールを実施する
- 80%既存機能の計測と改良
- 20%新機能の開発
機能の流れを抑制する
- かんばんで管理する
- バックログ
- MMF（市場価値最小限の機能：Minimum Marketable Feature）とバグを区別する
- 作業中
- 作業中のタスクの数を制限するのが大切
- 完了
- ほんとうの意味での完了は、顧客の検証により学習ができること
機能要求を処理する
- Getting Things Done方式のワークフロー
- 正しい行動で、適切な時期か？
- 小さな機能、またはバグか？
- 緊急か？
機能ライフサイクル
製品/市場フィットの計測
製品/市場フィットとは
- 市場を満足できる製品がある状態
ショーン・エリスのテスト
- 製品が使えなくなったときにどう思うか？
- 非常に残念、少し残念、残念でない、使っていない
- 40%が非常に残念と答えたならよい
- アンケートは学習より、検証に効果的
- 統計的有意性を得るためにはサンプル数が膨大である
「適切な」マクロ指標に集中する
- 一度きりのサービスはサービスの体験が重要
- アクティベーションの指標で計測できる
- SaaSのような何度も使うサービスも体験が重要
- 本当の成功は繰り返しの利用
- 人が欲しがるものを作る指標は、定着である
- アクティベーションの済んだユーザーの40%が定着すれば、トラクションがあると言える
収益について
- 価格は製品の一部
- ただし、収益は検証の1つの形にすぎない
- 収益は最初の検証だが、定着は究極的な検証
人が欲しがるものを作ったか
- コンバージョンダッシュボードを毎週レビューする
- 目標とバックログの優先順位をつける
- 大胆な仮説を作る
- 機能を追加・削除する
- 価値指標を監視する
- ショーン・エリスのテストを実施する
- 40%のユーザーが定着・ショーン・エリスのテストを通過したら初期は終了
製品/市場フィットにおける市場
- 解約率、ウィルス係数、顧客獲得コスト、顧客生涯価値などがビジネスモデルを拡大させる要因
- 初期のトラクションを実証する前に、ビジネスの拡大をするのは無駄
- 3つの成長のエンジン
- 粘着型：高い定着率
- ウィルス型：高い紹介率
- 支出型：高い利益率
- 価値指標の検証から着手する
- 顧客の製品に対する態度を理解する
- 調整するエンジンを選択する
ネットワーク効果のある製品
- 製品の数はユーザーの数
- 定着は王様
- 成長させる前に検証
マルチサイド製品
- 売り手がいないと買い手がいなく、買い手がいないと売りてはいない
- 両サイドのキャンパスを作る
- ミクロ単位で仮説検証をする
- 仲介処理の自動化は後
結論
拡大
- 製品/市場フィットの達成が最初のマイルストーン
- 重点が学習から、拡大になる
- 成功の指標を使って進捗を計測し、成功の確率をあげる
低燃費スタートアップの作り方
- ブートストラッピングは外部資本なしに企業を設立する（正しい行動を適切な時期に）
早すぎる資金調達は無駄なのか
- 資金調達は検証ではない
- 検証がなければ大きくできない
- 投資家は進捗を別の方法で計測する
- 資金調達は思っているよりも時間がかかる
- お金を持つとダメになる
- アドバイスや人脈は？
- 製品/市場フィットまでどうやって生き残ればいいか
- 本業は続ける
- バーンレートを節約しよう
- 初日から課金しよう
- 関連する商品を売ろう
リーンスタートアップにおけるフローの達成方法
- リーンスタートアップの基本原理は、無駄の削除
- 建物の外の活動は創業者が参加する
- 建物の中の活動も参加する
- 2つのスケジュールの綱引き問題が発生する
- 綱引きの均衡点を見つけるときに、フローという概念が約立つ
- 絶好調な精神状態を表す：フロー状態
- 明確な目的がある
- 高度な集中力を必要とする
- 中断や妨げるものがない
- 明確で即時的なFBがある
- やりがいがあって挑戦できる
毎日のフローを作る
- 予定しているクリエイターの活動
- 予定しているマネージャーの活動
- 予定していない活動
- クリエイターの仕事は中断されない時間を作る
- クリエイターの目標は早い時間に達成する
- マネージャーの仕事は遅い時間に設定する
週単位のフローを作る
- 顧客開発に最適な曜日を見つける（火〜木）
- 顧客の休止時間にクリエイターの仕事を入れる（月、金）
ソフトウェアの無駄を排除する
- 製品は顧客にプルしてもらう
- 顧客が要求するまでは製品を作らない
- 80%は既存機能の最適化に費やす
SaaS製品の価格設定
- スタートアップの最初の目標は、最適化ではなく学習
- 最初は「無料のお試しプラン」だけを用意する
- 最初は料金プランは1つ
- コストを考慮に入れる
フリーミアム
- 無料で提供し、顧客獲得後付加価値サービスをつける
- コンバージョンが低い
- 価格設定は売り手ではなく、買い手の気持ちが決める
- 検証サイクルに時間がかかる
- 間違った指標に集中してしまう
- 無料ユーザーは無料ではない
- フリーミアムの有償部分から始める
- 優れた無料プランは、無料体験版のようでなければいけない
予告ページの作り方
- 興味のない訪問者に興味のある見込み客になってもらう
- 大きな約束をする（UVP）
- 即効性のある明確な見出し = 顧客が望む結果 + 明確な期限 + それが達成されなかったときの代替案
- 顧客に結びつけて考える（課題）
- 関心と欲求を生じさせる（ソリューション）
