#garagekidztweetz

id:garage-kid@76whizkidz のライフログ・ブログ!

”Running Lean ―実践リーンスタートアップ”の読書メモ

スポンサーリンク

読書メモを公開していこう 2013 (第一弾) - #garagekidztweetz でシェアしていくことにした 4 冊中、 3 冊目を飛ばして 4 冊目は「Running Lean ―実践リーンスタートアップ (THE LEAN SERIES)」。
Lean Startup の実践書。著者自身が実践者ということもあり、とても説得力のある内容。
起業する方だけでなく、社内のプロジェクト立ち上げをする方にも参考になる。
手元においておきたい一冊。

エリック・リースによるまえがき

The lean series の一冊目
成功率を上げたい起業家のためのハンドブック
生産手段の借用により、現代は起業家が最も多い時代
スタートアップとは実験。現代の企業は想像できるものならば何でも構築できる。もはや答えるべき質問は、「構築できるか?」ではなく、「構築すべきか?」
新しい製品を成功させるには、収益の源泉を発見する普遍的で厳密な実験が必要

はじめに

ウェブベースの製品を構築する起業家たちが実践できるガイドを目指した

イントロダクション

➤ Running Lean

スタートアップの多くは失敗している
スタートアップが成功するのは、最初のプラン(プランA)が優れていたからではなく、リソースを使い切る前にうまくプランを見つけたから★
→Running Lean とは、リソースを使い切る前にうまくいくプランへと反復的に移行する体系的なプロセス

➤なぜスタートアップが難しいのか

・製品の構築方法に誤解があるから
・古典的な製品中心の手法ではソフトウェアをリリースするまで顧客実証をしないから
→意見を集めてから実装が終わるまでの間に顧客は離れる、断絶が生まれる
・顧客がすべての答えを持っていたとしても、なにがほしいか聞くことはできない

➤うまくいく方法

Running Lean は
・速度、学習、集中
・顧客の行動を計測してビジョンをテストします
・製品開発サイクルを通じて顧客と関係を築きます
・短いイテレーション(反復)で製品と市場の検証を同時に行います
・規律のある厳格なプロセス
・数々の方法論、思想家を参考にしている

*顧客開発
製品開発サイクルにあわせて、顧客との継続的なフィードバックループを構築するという並行プロセス

*リーンスタートアップ
顧客開発とアジャイルソフトウェア開発方法論とリーン手法(トヨタ生産方式)を統合したもの

リーン→ムダを省き、リソースを効率的に活用するということ
→★単位時間当たりの(顧客に対する)学習量の最大化を目的

*ブーストラッピング
銀行や投資家からの負債や資金調達を極力減らす技法
自己資金のことではない
顧客からの収益で資金を賄うこと

➤本書で学習できること

ーxxv

➤著者について

Wiredreach社をブートストラップ
早い段階で気づいたのは、水面下で製品をつくるのはダメだということ
誰もあなたのアイデアなんて見ていない
スタートアップは人生を消費する
誰も欲しがらないものを作るほど人生は長くはない
↓最後に気づいたのは
やり方を知らなければならないということ

➤なぜ本書なのか

2つの技法をCloudfireという製品でテストしようとしていた
多くの問題に直面
リーンスタートアップを実践しようとしたが疑問を抱えたまま旅をすることになった
その旅の成果がRunning Lean

➤実証実験
➤免責事項

・実践は理論に勝る
→自分の状況に応用が必要。財務、組織構造、知的財産などについては専門家にアドバイスを求めよう
・銀の弾丸はない

第 I 部

一章 メタ原則

➤ 1.1 プランAを文書化する

*ビジョンの中にわたしがいる
プランAは役に立たない

*ビジネスモデルの仮説を捕まえる
最初の手順はビジョンを書き出して、すくなくとも一人と共有すること
プランAはあとで間違っていると証明されることがあるので、事業計画書よりも柔軟に変化できるものが必要

リーンキャンバス ー5
リーンキャンバスとビジネスモデルキャンバスの違いへのリンク

高速性
簡潔性
携帯性

➤あなたの「製品」は製品では「ない」

500startup
起業家たちはソリューションに時間を使いすぎていて、ビジネスモデルのそのほかの部分に時間を費やしていない
あなたの仕事は最高のソリューションを構築するだけでなく、ビジネスモデルの全体像を把握して各要素をうまくまとめること

★メタ原則は、スタートアップのプロセスを分割統治する技法

リーンキャンバスとは?ビジネスモデルを9つの部品に分解し、リスクの高いものから体系的にテストするもの

➤1.2. 手順:プランで最もリスクの高い部分を見つける

成功する製品を構築するというのは、リスクを緩和するということ
製品開発を参考にした技法→「最もリスクの高い部分から着手する」
スタートアップの最も大きなリスクとは、誰もほしくないものを作ること

*スタートアップの3つのステージ
*第一ステージ:課題/解決フィット
ソリューションの構築に時間をかける前に解決に値する課題があるかを判断
アイデアは安くてもそれに取り組むコストは高い★
必要性/成長性/実現性

*第二ステージ:製品/市場フィット
重要な質問:誰に必要とされるものを構築したか?
それを計測する
→第IV部に詳しく
トラクション(事業が空回りしていないこと)あるいは製品/市場フィットはスタートアップにおける最初の重要なマイルストーン

*第三ステージ:拡大
重要な質問:どうやって成長を加速させるのか?
成長に目を向ける段階

*製品/市場フィットの前にピボット、それから最適化
製品/市場フィット前→学習とピボットに集中
製品/市場フィット後→成長と最適化に集中

ピボットはうまくいくプランを探すことであり、最適化はプランを加速させること

ピボットの実験→ビジネスモデルの仮説を検証、うまくいくプランを探す
最適化の実験→ビジネスモデルの仮説を改善してうまくいくプランに近づける

最も学習ができるのは、期待する成果の見込みが50%のとき
→つまり、何が期待できるのかよく分からないとき

学習を最大化するには、細かな改善を進めるのではなく、大胆な成果を狙うべき
ひとつの顧客セグメントのUVP(Unique Value Proposition)に変更するよりも、複数の顧客セグメントにさまざまなUVPを試す方がいい

*資金調達について
37signals
Getting Real Rework

資金調達にてきした時期は、製品/市場フィット後★
そのころには、あなたの目標と投資家の目的が一致している
→ビジネスの拡大

最初の目標は、ビジネスモデルを顧客とテスト・検証できるように必要十分な滑走路を構築すること
ブートストラッピング+リーンスタートアップ=低燃費スタートアップ

➤1.3 手順3. プランを体系的にテストする

*実験とは何か?
・アイデアや仮説を用意、仮説をテストする成果物を構築(モックアップ)
・この成果物を顧客の前に提示して顧客の反応を定性的・定量的に計測
・このデータを仮説の検証、反証の学習に使う
・そして、再び構築

*イテレーションのメタパターン
反復の基本的なメタパターン↓ ー13
課題を解決する→ソリューションを決定する→定性的に検証する→定量的に検証する

2章 Running Lean の実例

➤2.1 ケーススタディ:いかにして私は本書を反復したか?

最初は執筆するきはなかった
ブログを著作にしたらどうかという意見をたくさんもらった、が、最初はなにもしなかった

*課題を理解する
まず、その理由を聞いてみた、すでにある本と何が違うのか
(既存の代替品に対する本書のUVP(独自の提案価値)を理解しようとした)
↓学習
・著者と同様に顧客開発、リーンスタートアップに苦戦する人がほかにもたくさん(課題)
・著者のブログを段階的なガイドとして読んでいる(ソリューション)
・著者とおなじくWebベースの製品を開発している創業者だった(アーリーアダプター)

*ソリューションを決定する
状況がわかったので1日かけてデモをつくってみた
最もリスクが高いのは目次
私がこの本を書いたら買ってくれますか?と問いかけた(ソリューションの決定)
読者が数十人では、解決に値する課題ではないので予告ページはそのままにブログに「今夏刊行」と書いた(チャネルテスト)

1000のメールアドレスが集まった(潜在見込み客)

*定性的に検証する
ブログのコピペではなく、もっと小さくて顧客のことを学習できるものを構築する必要があった(実用最小限の製品)
ワークショップの告知、2回開催(小さなバッチを反復)
課金も始めてみた(課金は最初の検証)
ソフトウェアのように反復的にリリースすると伝えた
→事前購入すれば、2週間ごとにpdfフォーマットが手に入る
残りは完成品を読みたいと(さまざまなフォーマットで)
→アーリーアダプターとの違いを学習した ー18

*定量的に検証する
紙とeBOOKの選択肢についてアンケート調査
マーケティングサイトもつくった
(正しい行動を適切な時期に)
実際に本が1000部売れたということが出版社のリスクを下げた→出版社からの連絡
オライリーの支援
顧客との継続的なフィードバックループをつくった
→この版はさまざまな起業家たちを対象にしたインタビューとワークショップの成果を反映している

*本書は完成するのか
大規模なソフトウェアと同じように、書籍も完成することはありません。ただリリースされるのみ
今もブログは更新中★
Running Lean Masteryというニュースレターを書いている、隔週で★

第II部

プランAを文書化する

3章リーンキャンバスの作成

➤3.1 見込み客を考える

早い段階から顧客セグメントやビジネスモデルを選択するのはムダ
危険なのは「選択バイアス」がテストされずにうまくいかないビジネスモデルや局所最適化につながってしまうこと

**顧客とユーザを区別する
製品にお金を払ってくれるのが「顧客」、「ユーザ」はお金を払ってはくれない

**顧客セグメントを細かく分ける
あらゆる人をターゲットにした製品を効果的に設計・構築・出荷することはできません

**最初はすべてを一枚の紙にまとめよう
**顧客セグメントごとにリーンキャンバスを書く

➤ 3.2 リーンキャンバスをスケッチする ー27

**一気にスケッチする
最初は15分以内に終了してみる

**空欄があっても構わない
**簡潔に書く
**今わかる範囲で考える
**顧客主導型を使う
→Running Lean は顧客を重視しているから

*課題と顧客セグメント ー29
**上位1-3位の課題を挙げましょう(ターゲットとなる顧客セグメントに対して)
**既存の代替品を列挙しましょう
課題に対してアーリーアダプターがどのように対処しているかを考えて文書化してみる

**ユーザを特定する
例:ブログプラットフォームの場合、ブログの著者が顧客で、ブログの読者がユーザ

**アーリーアダプターに狙いを定めましょう

*UVP(独自の価値提案)
→あなたが他とは違っていて注目する価値がある理由★
最初の戦いは販売ではなく、見込み客の注目を集めること

**UVPのつくり方
変わったものにしましょう。ただし、その違いが重要なものに限る
アーリーアダプターをターゲットにしましょう
成功ストーリーに注目しましょう
→利点は顧客の立場になって考えなければなりません
言葉はよく選んで使いましょう
誰が・何を・なぜに答えましょう
→リーンキャンバス、USERcycle
優れたUVPを調べてみましょう
ハイコンセプトピッチを作りましょう

*ソリューション
課題に取り組むための簡単なスケッチをしましょう
課題とソリューションの結合はできるだけ遅らせましょう

*チャネル
スタートアップが失敗する主な理由は、顧客への経路が作れないこと
スタートアップの最初の目的は学習、拡大ではない
最初は見込み客に到達するチャネルなら何を使っても構いません

**無料と有料
無料のチャネルはない。ブログですら人件費がかかる。
一般的な有料チャネルとしては、SEM(検索エンジンマーケティング)
→Googleアドワーズ

**インバウンドとアウトバウンド
プル型とプッシュ型
それぞれの例
インバウンドチャネル→ブログ、SEO
アウトバウンドチャネル→SEM、営業電話
など

**直販と自動化
最初は手動で販売して、あとから自動化しよう

**直接と間接
早い段階から戦略パートナーを作ろうとするのもエネルギーのムダ
他人に任せる前にまず自分で製品を売らなければなりません

**紹介の前に定着
価値を広める製品が必要

*収益の流れとコスト構造
リーンキャンバスの最下部、「収益の流れ」「コスト構造」
→3-5年後を予測するために使う

**収益の流れ
価格の問題を遅らせようとしてはならない
MVP は不完全な製品やバグの多い製品とは違う
MVP は顧客が重視している上位の課題を解決するだけでなく、それが解決に値する課題でなければいけません
→課金できるだけの十分な価値を届ける計画が必要

新製品をローンチするときには、登録の障壁を下げるべきと皆、考えるが

これではビジネスモデルの最もリスクの高い部分の検証が遅れてしまう
→顧客の強い「コミットメント」がないので、学習の効果がない

学習するのに大勢のユーザはいらない。優れた顧客が数人いればよい
→価格は製品の一部
→価格が顧客を決定する
→課金は最初の検証
ー40

**コスト構造
製品を市場に送り出すまでのコストをリストにする
将来のコストを正確に計算することはできないので、現在の基準で考える

*主要指標
ビジネスの動向をリアルタイムで教えるキーナンバーを見つけておくこと
例:デイブ・マグルーアの海賊指標 ー43

**獲得
**アクティベーション
→関心のある見込み客が満足のいくユーザ体験をした時点

**定着
製品の「反復利用」やエンゲージメントを表す

**収益
お金を払っていただくイベントを表す

**紹介
ユーザ獲得のチャネルの応用、口コミ

*圧倒的な優位性
「コピーする価値のあるものはコピーされる」
圧倒的な優位性の例:
内部情報、正当な「専門家」の支持、ドリームチーム、その人の信頼性、巨大なネットワーク効果、コミュニティー、既存顧客、SEOのランキング

➤3.3 次はあなたの番です

LeanCanvas.comでオンラインキャンバスをつくる
パワポやKeynoteをつくる
紙にスケッチするなどして

第III部

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

4章 ビジネスモデルの優先順位

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

➤4.1 リスクとは

不確実とリスクは同じものではない
リスクはなくとも不確実なものはある

不確実:確実性のないこと、複数の結果が存在すること
リスク:損失や失敗などの好ましくない結果になりうる不確実な状態

リーンキャンバス
→不確実性を明確化できる
→機会費用と実質費用の両面から定量化する

スタートアップのリスク
・製品リスク P
・顧客リスク C
・市場リスク M
→リーンキャンバスにプロットしたものが ー52

➤4.2 ビジネスモデルの比較

リーンキャンバスを順番に並べて、どのモデルから手をつけるかを決める
目的:
十分に大きな市場を持ち、製品の周りにビジネスを構築でき、その製品を必要とする顧客に近づけるようなビジネスモデルを見つけだすこと
↓著者の使っている評価指標 ー53
1. 顧客の不満レベル(課題)
2. 近づきやすさ(チャネル)
3. 価格と粗利益(収益の流れとコスト構造)
4. 市場規模(顧客セグメント)
5. 技術的実現可能性(ソリューション)

➤4.3 外部の意見を求める

ビジネスモデルは最低でも自分以外の誰か一人と共有しなくてはなりません
正しいアドバイザーとは、「プラン全体」のリスクを特定してくれたり、モデルの改良やダメ出しを手伝ってくれたりもする

↓ビジネスモデルインタビューのガイドライン
*スライドを10枚にするのをやめましょう
→インタビューで大事なのはピッチよりも学習
話にあわせてビジネスモデルを少しずつ明らかにしていく

*20%を準備に、80%を対話に使いましょう
*具体的な質問をする ー57
*「アドバイザーパラドックス」に気をつける
→顧客インタビューは顧客に何がほしいかきくためのものではない。同様にアドバイザーのインタビューもアドバイザーに何をすればいいかきくためのものではない
→★リスクの特定や優先順位をつけるための手段だと考えるようにする(あなたのビジネスモデルを所有しているのはあなた)

*先見性のあるアドバイザーを採用する

5章 実験の準備

➤5.1 課題チームと解決チームをつくる

*部門のことは忘れる
二つのチームをつくる
課題チームと解決チーム
ただし、二つのチームは機能横断的であり、メンバーも重なっている

*小規模ではなく最小のチームで開始する
課題チーム、解決チームは2-3名が最適
コミュニケーションが簡単
作れるものが小さいから
コストを低く抑えられるから

*絶対に必要な3つの要素:開発・デザイン・マーケティング
デザインとは外見やユーザビリティのこと
顧客の立場になって考えることのできる人が必要→マーケティング

*課題/解決チームの外部委託は慎重に
絶対に顧客について学習することを委託し手原ならない★

➤ 5.2 効果的な実験

*速度・学習・集中を最大化する
構築ー計測ー学習のループで測定する→速度
顧客についての学習は重要
集中も。

*主要指標と目標を特定する
一つに集中したほうが効果的だという著者の意見

*学習に必要な最も小さいことをやるー64

*反証可能な仮説
反証可能な仮説とは?→間違いがはっきりとわかる文 ー65例
反証可能な仮説=具体的で反復可能な行動→期待する計測可能な成果

*定性的検証と定量的検証
最初の目標は強いシグナルを受け取ること、サンプル数は少なくてもいい

否定的なシグナル→すぐ改善か破棄をすべきという意味になる
肯定的なシグナル→その仮説が統計的有意性を確保できるという意味ではない。仮説を定量的データで検証してもいいということ

*結果を具体的な行動に結びつける
計測結果を具体的で反復可能な行動に結びつけて、製品を常に変更していく
定性的検証では、パターンが見えるまで同じ方法を繰り返す

*わかりやすいダッシュボードをつくる ー67

*学習を早めにしょっちゅう伝える
毎週定期的に外部のアドバイザーや投資家に、最後の実験から学習した教訓について伝えるようにする
ふりかえり、つぎの行動計画をよりよいものとする
→革新会計の基礎になる
ー68 学習した教訓のアウトプット例
まずは、右上→目標と主要指標を決める
左→学習したことをまとめる(仮説、見解、実験)

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

リスクには何度も実験して取り組む
製品/市場フィット前であれば、定性的に学習することになる
※一回の実験ですべてのリスクは軽減できない

気をつけなければならないこと
中途半端な学習や否定的な学習でやる気を失ってしまい、早々にピボットや実験の中止をしてしまわないこと
肯定的な学習から必要以上に楽観的になり、あとで行き詰まってしまわないこと

単位時間当たりの学習量(どのリスクが高いか)を最大化しましょう
↓各ステージで体系的に取り組む方法

体系的にリスクを排除する ー70
ステージ1. 課題を理解する
誰が課題をもっている?どんな課題?現時点ではどう解決されている?

ステージ2. ソリューションを決定する
ソリューションはうまくいきそうか?アーリーアダプターは誰か?価格モデルは大丈夫か?

ステージ3. 定性的に検証する
MVPをつくってアーリーアダプターにみてもらう

ステージ4.定量的に検証する
改善した製品を多くの人たちにみてもらう

リスクを基準にしたもの↓ ー71
製品リスク:正しい製品をつくる
顧客リスク:顧客への経路をつくる
市場リスク:実現可能なビジネスをつくる

*圧倒的な有意性
圧倒的な優位性は競争がなければできない
製品/市場フィットを明らかにするまでは競争は起きないだろう

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

6章 顧客インタビューの準備

➤6.1 アンケート調査もフォーカスグループも不要

・アンケート調査は正しい質問があることを前提にしている
→顧客インタビューとは、何がわからないのかさえわからないことの探求
・アンケート調査は正しい答えがあることを前提にしている
→最初は自由回答形式の質問を使って学習する
・アンケート調査は顧客のしぐさが見えません
→ボディーランゲージが伝えてくれることの大事さ
・フォーカスグループは間違っています
→集団思考をしてしまうことが問題

*アンケート調査が適していること
アンケート調査は初期の学習には適していないが、顧客インタビューから学習したことを検証するには効果的

➤6.2 でも、人と話をするのは難しい

何を話せばいいのか?
・ピッチではなく学習を中心に考える
・「正しい」ソリューションについてピッチする前に、顧客の「正しい」課題について理解しなければならない
・顧客に何がほしいか聞いてはならない、行動を観察すること
・台本にあわせて会話をする
→学習という目的を忘れないために
・網を広く投げる
→最初の目的はアーリーアダプターを見極めることだが、見込み客のすべてがアーリーアダプターになるわけではない。見込み客を絞り込むのはあとからでいい
・直接面会してインタビューする
・知り合いからはじめる
・誰かと一緒にはじめる
・中立的な場所を選ぶ
・十分な時間をもらう
・謝礼や贈り物はしない
・インタビューを録音しない
・インタビュー後すぐに文書化する
・30-60人にインタビューする
・インタビューのスケジュール調整を委託してみる

➤6.3 見込み客を探す

見つける方法
・近しい人からはじめる
→誰とも話さないよりははなした方がいい
・紹介をお願いしてみる
・地元で探してみる
・予告ページでメールアドレスを登録してもらう
・何等かの形でお返しをする
・電話、メール、リンクトインを使って依頼する

➤6.4 先制攻撃と反論(または私は如何にして顧客インタビューをしないか)

顧客インタビューに対する反対意見の紹介、そしてそれに対する反論 ー63
・顧客はなにがほしいかわかっていない
・数十人と話しても統計的に有意ではない
・定量的指標で十分だ
・自身が顧客なので、誰かと話をする必要がない
・わたしの友達がそのアイデアをいいねと言っている
・週末で何か作るのにどうして何週間もかけて顧客と話をするのか
・すでに課題が明確なのでテストは必要ない
・課題が明確でないのでテストができない
・誰かにアイデアを盗まれる
・誰もペイパーウェアにお金を支払わない
・製品を販売したほうがリスクの軽減につながる

7章 課題インタビュー

➤ 7.1 学習すべきこと

製品リスク:何を解決するのか?
市場リスク:競合は誰なのか?
顧客リスク:誰が困っているのか?

➤7.2 課題のテスト

最初の目的は課題に対する顧客の反応を計測すること
特に、現時点で課題を解決できているか、解決できているとしたらどのように解決しているのかを理解する
→デザイン思考やユーザ中心設計などの手法で採用されている観察技法や構造化インタビュー技法を使います

➤ 7.3 反証可能な仮説

インタビューの結果を行動につなげるために、キャンバスの仮説を反証可能な仮説に返還する必要がある
→課題、既存の代替品についてテストする
→反証可能な仮説の公式を使って実験の基礎をつくる


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

➤7.4 課題インタビューの実施

課題インタビューの台本の分解図 ー 91
場の設定→顧客セグメントの検証→課題の文脈の設定
(準備、アーリーアダプターの特定)

課題の文脈の設定→ストーリーの伝達(課題の検証)→顧客の世界観の探求(課題の検証)
(課題の検証)

フックとお願い
(今後の協力依頼、紹介)

結果の文書化


課題インタビューのテンプレート ー96 ★
Note: Wufooや Google フォームなどのツールをつかうと結果を簡単にまとめられ、分析するときにもレポートを出力できる

➤ 7.5 課題を理解していますか?

インタビュー結果の分析、台本の改良、終了条件について
・結果を週次でレビューする
・アーリーアダプターからはじめる
・課題を洗練させる
→必要ないという強いシグナルを受け取ったら、その課題を台本から削除する
・既存の代替品を理解する
・顧客の使う言葉に注意する

*課題インタビューの終了条件
以下のことが可能となれば終了
・アーリーアダプターとなる顧客が特定できた
・絶対に必要な課題が見つかった
・現在の顧客の解決方法がわかった

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

➤ 8.1 学習すべきこと

優先順位のついた課題と既存の代替品を理解すれば、ソリューションの計画とテストの準備ができたといえる

➤ 8.2 ソリューションのテスト

顧客にソリューションの「デモ」を見せて、課題が解決できるかどうかを検証すること
顧客は課題について説明するのは得意ですが、ソリューションを思い浮かべるのは不得意です


デモについてのガイドライン★
・デモは実行可能でなければならない
・デモは本物に見えなければならない
→デモが本物に見えれば、その分だけ正確にソリューションをテストできます
・デモは高速に反復する必要があります
・デモはムダを最小化しましょう
・デモは本物に見えるデータを使わなければならない

➤ 8.3 価格のテスト

顧客インタビューの目的はピッチではなく学習→誤解せぬよう★
インタビューには反復可能な仮説をもって臨まなければならない
→仮説がボコボコになるかもしれないがそれは構わない


*価格のことは顧客に聞かず、ただ伝えるだけ
顧客に絶対に必要な課題があると説得することはできません(すべきでもない)が、あなたの製品に「適正な」価格があると説得することはできる(そうすべき)。そして、あなたや顧客が考えているよりも、その価格は高い


*登録の障壁を下げずに上げる
→直感に反するとは思うが。
原則となるもの ー109
・賞品
→ Pitch Anything (書籍)、フレーミングの法則
・希少性
→どっちつかずの100ユーザより、やる気のある10アーリーアダプターに注力する
・アンカリング
・度胸


*ソリューションインタビューのAIDA
Attention, Interest, Desire, Action

認知:効果的に認知を集めるには顧客の課題を突きつけること
興味:デモをつかって UVP をどのように提供するかを示して興味をひく
欲求
行動:製品に対する口約束・書面の契約・前払い金をとりつける


*ピッチとどこがちがうのか?
フレーミングは学習
ピッチは「オール・オア・ナッシング」の提案になるが、フレーミングは仮説を使って顧客の反応を引き出すもの
→期待する反応を引き出すことができれば、その理由を深く掘り下げることになる

➤8.4 テスト可能な仮説

インタビューでテストする仮説を文書化する

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

・既存の見込み客にお願いする
・新規の見込み客を入れる

*歓迎(場の設定)

*顧客情報の収集(顧客セグメントの検証)
→アーリーアダプターを選定するために。顧客情報に関する基本的なことを質問する。

*ストーリーの伝達(課題の文脈の設定)
→共感してもらえなかった場合には、ソリューションインタビューを続けるのではなく、課題インタビューに切り替える
→見込み客の課題を学習する

*デモ(ソリューションの検証)
をつかって、課題の解決方法を説明する

*価格の検証(収益の流れ)
適正な価格を見つけるというのは科学ではなく、技芸
そもそも適正な価格とは?
→顧客が少し抵抗を見せながらも受け入れる価格。

*まとめ(質問)
→サービスの準備ができたときに、テストに協力してもらえるようにお願いする

*結果の文書化ー118

➤8.6 解決に値する課題はありましたか?

インタビュー結果の解釈、台本の改良、終了条件
・結果を週次でレビューする
・機能を追加、削除する
・前回の仮説を確認しましょう
・価格設定をしましょう

*ソリューションインタビューの終了条件
以下の確信がもてたときに終了する
・アーリーアダプターの顧客情報が特定できた
・「絶対に必要」な課題がわかった
・課題を解決するのに必要な最小限の機能が定義できた
・顧客が支払ってくれる価格がわかった
・(概算で)うまくいきそうなビジネスが構築できた

9章 バージョン1.0をリリース

➤製品開発は学習の邪魔

典型的な製品開発
要求→開発→QA→リリース
この中でもっとも学習できるのは、製品をリリースしたあと
✔開発やQAをなくすことはできないが、要求からリリースまでのサイクルを短くすることはできる
↓そうすれば
学習を加速できる

➤9.2 MVPの縮小化

MVP は濃縮された強烈で風味豊かなソースのように凝縮しなくてはならない

1. 白紙からはじめる
2. 最上位の課題からはじめる
→MVPの価値提案役割は説得力のある約束をすること、MVPの役割は約束したものを届けること
3. 「あれば嬉しい」や「必要ない」は削除しましょう
4. 2位、3位の課題のモックアップに対して手順3を繰り返す
5. 顧客の機能要求を検討する
6. 初日から課金しましょう、ただし徴収は30日後
7. 最適化ではなく学習に集中

➤9.3 継続的デプロイを始める

ソフトウェアを継続的にリリースするプラクティス

要求→継続的デプロイ→リリース

トヨタの流れ化をもとにしている
ソフトウェアにおけるもっとも大きなムダは「次の工程の待ち時間」
✔継続的デプロイは品質を落とすことにはならない
→むしろ、緻密なテストや監視が要求される
✔継続的デプロイのプロセスは学習や改善のフィードバックループなので、小さく始めることができる
✔継続的デプロイは本番環境に小さなバッチでデプロイする。このコードはユーザーに見せる必要はない
→付録に継続的デプロイのはじめ方✔

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

アクティベーションの流れとは、顧客がサービスに登録してから最初の体験に満足するまでの道筋を表したもの

*アクティベーションの流れの解剖
アクティベーション
↓ファンネル
登録
追加手順
主要活動

アクティベーションの流れの目的は、顧客にできるだけ早くUVPを体験してもらうこと
→「最適化よりも学習」を目的としてアクティベーションの流れを計画することが大切
↓そのためのいくつかの方法
・登録の障壁は下げても学習を犠牲にしてはいけない
→登録ページでは必要最小限のみの情報を集める
・手順を減らしても学習を犠牲にしてはいけません
・UVPを届けましょう
・うまくいかなかったときのことを考えておく
→ヘルプなどの用意

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

目的は単純→製品を売ること
顧客ライフサイクルを開始するのに不可欠
獲得とは、最初に単なる訪問者としてウェブサイトに到着したときから、興味のある見込み客にいたるまでの顧客の道筋を表したもの

*マーケティング用のサイト解剖
獲得
↓ファンネル
UVP→なぜ注目するべきか?
他のページ→もっと詳しい情報が必要
価格→どれだけかかるか?
登録をクリック→どうすれば始められるか?

各手順にページを割り当てるとよい
各ページには行動を促すものをふたつ用意する
必要なページはいかのとおり
・概要ページ
→顧客とつながる機会
・サービス利用規約ページとプライバシーポリシーページ
・製品ツアーページ
→顧客や顧客の動機の理解につながる

*ランディングページの分解
→✔ランディングページが一番難しい ー133に図例
・独自の価値提案
・ビジュアルの支援
・明確な誘導
・もっと詳しく知るための情報
・社会的証明

10章 計測の準備

➤10.1 行動につなかる指標が必要

製品/市場フィット前は定性的学習をすることがありますが、顧客ライフサイクルを可視化して計測できるのような行動につながる指標も必要。
製品/市場フィット前の目的は、コンバージョンの最適化ではない
→顧客ライフサイクルにおけるホットスポットの特定と、その解決をすばやく行うことがすべて

*行動につながる指標
→観察結果を具体的で反復可能な行動につなげるもの
→反対は虚栄の指標、アクセス数やダウンロード数など✔→計測対象ではなく、計測方法に過ぎない

➤10.2 指標な人が重要

数字の裏にいる人に聞かなければいけない
理想的なコンバージョンダッシュボードとは、分析とカスタマーリレーションシップマネジメントを合わせ持つもの(CRM)
↓理由
・指標それ単体では何も説明しません
・ユーザーのほうからやってくるわけではない
・すべての指標は等価ではありません

➤10.3 単純なファンネルレポートは十分ではない

ファンネルレポートの例 ー138
→獲得とアクティベーションのイベントが短いライフサイクルの。収益イベントが長い

・不正確なコンバージョン率
・トラフィックの変動
・進捗の計測が困難
・ファンネルの分割

➤10.4 コホートによろしく

ファンネルとコホート分析を結びつける
コホート:ある決められた期間内に共通の特性(年齢など)や経験(薬品やワクチンの投入など)を持った人の集団のこと

138のファンネルを書き直したもの ー140
週次で出し直している→収益のコンバージョン率が大きく異なる

・トラフィックの変動に対応
・進捗の計測が可能
・ファンネルの分割

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

Google analytics
Mixpanel
KISSmetrics

11章 MVP インタビュー

➤11.1 学習すべきこと

まずは仲のよいアーリーアダプターに直接販売してみる
そこから学習して、ローンチのためのデザイン・ポジショニング・価格を改良する
↓MVPインタビューでの質問で探すこと
・製品リスク:製品の魅力は何か?
・顧客リスク:十分な顧客はいるか?(チャネル)
・市場リスク:価格は適正か?(収益の流れ)

➤11.2 仮説の構築
➤11.3 MVP インタビューの実施

これもピッチよりも学習。
MVP インタビュー台本の分解図 ー144

*歓迎
*ランディングページの提示(UVPの検証)
*価格ページの提示(価格の検証)
*登録とアクティベーション(ソリューションの検証)
*まとめ(フィードバックループの維持)
*結果の文書化

12章 顧客ライフサイクルの検証

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

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

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

試用期間の最初の目的
→獲得やアクティベーションにおけるユーザーの離脱を減らすこと
次の目標
→定着やエンゲージメントを増やすこと、可能であればお金を払ってもらうこと、顧客の推薦の声をあつめること

*獲得とアクティベーション
優先事項→学習できるだけのトラフィックを稼ぐ
・ファンネルを掘り下げる
・ユーザに連絡する
・予期しないエラーをキャッチして通知する

*定着
優先事項→試用期間中にユーザーに戻ってきてもらって、製品を使ってもらう
・丁寧なリマインダーを送信する
・インタビュー相手に協力を求める

*収益
優先事項→お金を支払ってもらう
・決済システムの実装
・支払った顧客に電話
・「売り損ねた」見込み客に話を聞く

*紹介
優先事項→推薦の声をもらう
お願いしてみる

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

製品を世の中に公開する前にやるべきこと
1. 結果を頻繁にレビューする
2. 最も重要な課題から着手する
3. 可能な限り小さなことをやる
4. 確実に改善する
5. コンバージョンダッシュボードを監視する

*ローンチ条件
アーリーアダプターが以下のことをできなければいけない
・独自の価値提案(UVP)を明確に理解している
・本サービスに登録するつもりがある
・価格モデルを受け入れている
・アクティベーションの流れをうまく通り抜けている
・好意的な推薦の声を提供してくれる

*3,2,1…ローンチー
学習に「ちょうど十分」なトラフィックを獲得すふのが目的

ー具体例 ー155✔

13章 機能の押し売りはやめよう

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

✔継続的デプロイを実装しても機能を作りすぎないように注意する
多くのことが間違った方向に進む可能性がある
↓理由
・追加機能は独自の価値提案(UVP)を薄めてしまう
・すぐにMVPに見切りをつけてはいけません
・機能には隠れたコストがある
・顧客は本当にほしいものをわかってはいない

➤13.2 80/20ルールを実施する

優先順位をつけるときには。

➤13.3 機能の流れを制御する

コンバージョンダッシュボードを指標の追跡に使うように、かんばんダッシュボードは機能の追跡に使います
→どちらもマクロ的視点に焦点をあてています ー164

かんばん、3つのバケツ✔
1. バックログ
・既存機能の改善
・顧客の機能要求
・自分たちへの機能要求
先へ進むために、MMFと小さな機能やバグ修正を区別する
著者が機能というときは常にMMFを指している
MMF は小さな作業項目(タスク)で構成されている
継続的デプロイを実施していれば、この作業項目が小さなバッチになる

2. 作業中
モックアップの作成、コーディング、デプロイなど

3. 完了
ただし、リーンスタートアップでは、顧客の検証による学習ができることを本当の「完了」といっている

➤13.4 機能要求を処理する

GTD のワークフローの説明
まず、作業の必要性や優先順位を確認する
正しい行動で、適切な時期か?
小さな作業項目かつ緊急であれば、すぐに着手する
そうでなければ、タスクボードのバックログに追加、優先順位もそこでつけておく

➤13.5 機能ライフサイクル

*かんばんボードで機能を追跡する
かんばんボードの説明ー168
・目標→かんばんボードのうえに書いておくとよい
・仕掛品の上限
・機能はいつでも中止可能
・継続的デプロイ
→実装の下には「コミットーテストーデプロイー監視」
・2段階検証
→定性的検証ができたら「完了」そうすれば、仕掛品のロックを解放できるので、データを収集しながら他の機能に着手できる

*各手順と説明
・課題を理解する
1. バックログ
最初は機能をバックログ列の上部に配置、製品の目標にあわせて優先順位
機能が決まったら解決に値する課題かどうかをテストする
a. 顧客からの要望
b. 内部からの要望

・ソリューションを決定する
1. モックアップ
2. デモ
3. コード
→機能を複数の小さな作業単位に分割し、タスクボードを使って追跡する

・定性的に検証する
1. 部分的展開
2. 定性的検証

・定量的に検証する
1. 全面展開
2. 定量的検証
→機能の種類によってはスプリットテストが必要、ただし慎重に判断
✔ガイドライン
→著者の場合、新機能ではスプリットテストはやらない。新機能がないときのコホートと比較できるから
→定性的検証で強いシグナルを受け取ったときもやらない
→定性的検証で中程度のシグナルを受けた、改善フローや代替フローをテストするときはスプリットテストの実施をすすめる

14章 製品/市場フィットの計測

➤14.1 製品/市場フィットとは

市場を満足させることのできる製品のある状態ということ
ー173

➤14.2 ショーン・エリスのテスト

転換期のスタートアップの支援に特化
ユーザーからサンプルを抽出し、定性的な調査を実施し、製品に初期のトランザクションがあるかどうかを判定する
↓この調査で重要な質問が以下、
✔(製品名)が使えなくなったときどう思いますか?
アンケート調査は学習よりも検証に効果的

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

製品/市場フィットまたは、トランザクションを達成するというのは、人が欲しがるものを作るということ
あるいは、UVPを届けるということ
✔人がほしがるものをつくる指標は、定着になる
アクティベーションの済んだユーザーが毎月40%以上いれば、初期のトランザクションがあるといえる
→✔40%以上の人が「非常に残念」と答えれば今後も継続的に顧客を獲得できるといえる

➤14.4 収益について

収益は最初の検証、定着は究極的な検証

➤14.5 人がほしがるものを作ったか

初期のトランザクションを達成するための反復プロセスに関する説明
1. コンバージョンダッシュボードを毎週レビューする
2. 目標とバックログの優先順位をつける
3. 大胆な仮説をつくる
4. 機能を追加/削除する
5. 価値指標を監視する
6. ショーン・エリスのテストを実施する

*初期のトランザクションの終了条件
・ユーザーの40%が定着した
・ショーン・エリスのテストを通過した

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

*成長のエンジンの特定
スタートアップが持続的に成長するために必要とするメカニズム

・粘着型:高い定着率
解約率→製品を使わなくて一定期間が経った顧客の割合

・ウィルス型:高い紹介率
ウィルス計数とは、顧客一人当たりの紹介数を計測
顧客獲得率>解約率ならビジネス成長

・支出型:高い利益率
顧客生涯価値(LTV)>顧客獲得コスト(COCA)を続けているのであれば成長を続けている

✔成長エンジンを選択するガイドライン ー179
1. 価値指標の検証から着手する
2. 顧客の製品に対する態度を理解する
3. 調整するエンジンを選択する

ケーススタディ
教訓1. 差別化は、その違いが重要なときにしか意味がない。
教訓2. お金儲けは最初の検証だが、それだけでは不十分。
教訓3. スタートアップは人生を消費する。解決に値する課題を選択すべし。
→何でもいいから全力で情熱を傾けること

➤14.7 まとめ

本書のワークフローを示したもの ー185

*ネットワーク効果のある製品のデザインパターン
ネットワーク効果のある製品?→その価値がユーザーの数によって決まる製品
例:古典的には電話。Twitter、Facebook

・注目は換金可能な資産
・定着は王様
→最初の重要なマイルストーンはみんなのほしいものをつくること
・成長エンジンはウィルス型

*マルチサイド(マーケットプレイス)製品のデザインパターン
買い手は十分な売り手がいないので興味をもたない。売り手は十分な買い手がいないので興味を持たない。

・両サイドのキャンバスをつくる
・アーリーアダプターのマーケットプレイスで価値を検証する
→最初はミクロ単位の価値を実証
・仲介処理は自動化しないようにする
・両サイドに適切な成長エンジンを選ぶ
→推薦の声など

15章 結論

➤15.1 そして拡大へ

*製品/市場フィット後の時代
・あらゆるプロセスは人を増やすまでうまくいく
キャズムを越えるために顧客にあわせて成長エンジンのチューニングや再設定を継続的に行っていると、企業の成長に応じた新しい問題に直面するようになる

実験を通じた学習の文化が必要

*私(著者)は約束を守れましたか?
「方法論は成功を保証するものではない」
成功の指標を使って進捗を計測し、成功の確率をあげるということ

*(著者の)連絡先 ー193
*情報源書籍の紹介 ー193
書籍、ブログ、ツール

付録:低燃費スタートアップの作り方

ブートストラップ
→外部資本なしに企業を設立すること
→正しい行動を適切な時期にすること

スタートアップのあらゆるステージにおいて、「正しい」行動というものがある。時間・お金・労力の見返りを最大化してくれるもの。リーンあるいはブートストラップの起業家はそれ以外のことを無視していいのです

➤A.1 なぜ早すぎる資金調達はムダなのか

・資金調達は検証ではない
・検証がなくては大きくできない
→製品/市場フィットの信頼性がないということになる
・投資家は進捗を別の方法で計測する
→検証による学習で進捗を計測
・資金調達は思っているよりも時間がかかる
・お金をもつとダメになる
→お金は銀の弾丸ではなく促進剤。制約がイノベーションを生む、そしてそれが行動につながる
・アドバイスや人脈
・製品/市場フィットまでどうやって生き残ればいいか?
→外部資金を得る理想的な時期は、製品/市場フィットのあと

最初にブートストラップする最も大きな理由
→✔かつてないほど会社をはじめるのが簡単になっているから

・本業は続けましょう
課題/解決フィットを見つける最初のステージでは、作る機能はわずかでなければならない
→それ以外には手をつけない

・バーンレート(資本の消費率)を節約しましょう
SWビジネスで最もお金がかかるのは人件費
HWは買わずに借りよう
・初日から課金する
・関連する製品を売る

*リーンスタートアップにおけるフローの達成方法
基本原理はムダの排除

*時間の綱引き
リソースは奪い合うもの
時間も例外なし

建物の外の課題
→機能横断的なチームには、創業者が参加しなくてはいけない
建物の内の課題
→建物の外で見つけた課題とソリューションの差を埋めるために

二つのチーム→課題チームと解決チーム
→スケジュールの駆け引きが発生する
↓生産性の工場にかかせない概念
✔フロー状態 ー199

フロー状態の活動の特徴
・明確な目的がある
・高度な集中力を必要とする
・中断や注意を妨げるものがない
・明確で即時的なフィードバックがある
・やりがいがあって挑戦できる
→このフローは思い通りに発動できるものではない

しかし、二つ目のフローは自分でコントロールできる
↓著者の使っているhack
*✔毎日のフローをつくる
毎日の活動を3つに分ける
・予定しているクリエーターの活動
・予定しているマネージャーの活動
・予定していないクリエーターとマネージャーの活動

✔仕事のhack1. クリエーターの仕事をするときは中断されない時間をつくる
✔仕事のhack2. クリエーターの目標はできるだけ早い時間に達成する
✔仕事のhack3. マネージャーの活動をできるだけ遅い時間に割り当てる
✔仕事のhack4. 顧客サポートなどの予定していない活動の準備をしておく

*週単位のフローを作る
毎日のフローとは別に活動のスケジュールをつくる
✔仕事のhack5. 顧客開発に最適な曜日を見つける
→火曜日か、木曜日
✔仕事のhack6. 顧客の休止時間を活用する
→月曜日、金曜日は顧客の活動が緩やかなので、クリエーターの活動に割り当てる
✔仕事のhack7. 顧客と会う時間を調整する
→台本のない課題を学習するには、台本のない会話が一番

*ソフトウェアのムダを排除する
より少ないコードでより多くの学習が理想
→スタートアップでは課題やソリューションがよくわからない。仕様通りにソフトウェアを構築することも難しい
✔仕事のhack8. 製品は顧客に「プル」してもらう
→労力の80%は新機能よりも既存機能の最適化に費やす
✔仕事のhack9. 3-5個の行動につながる指標を反復する
取り組むべき項目を見つけて優先順位をつけるために
✔仕事のhack10. ソフトウェアにフローをつくる
継続的デプロイをしているので、スケジュールはない
伝統的な製造プロセスでは機械の時間を調整するが、「リーン」はこの手法とは対照的に人間の時間を調整する

➤A.2 SaaS 製品の価格設定

最初は「無料のお試し版」プランだけを用意する
・最初は料金プランを一つにする
・「無料のお試し」プランを使う
・テストする価格を選ぶ
・コストを考慮に入れる

*フリーミアム
まず、ユーザーから金銭的価値を引き出さないのであれば、フリーミアムのモデルはビジネスモデルではなく見込み客を集めるマーケティング戦術
✔早い段階で価格設定をテストしたいがフリーミアムだと学習が遅れてしまう

*フリーミアムの課題
お薦めしない理由
・コンバージョンが低い
→無料版に機能を盛り込みすぎるという過ちをおかしがち
・価格設定は売り手ではなく買い手の気持ちが決めるもの
→データがないから有料プランに移行するような無料プランをつくれない
・検証サイクルに時間がかかる
・間違った指標に集中してしまう
→無料とユーザーは(まだ)顧客ではない
・S/N比を下げる
→機会さえあれば、誰もが辛口批評家になる
・無料ユーザーは「無料」ではない

*フリーミアムの使い方
・フリーミアムの有償部分から始める
→顧客にひとつの料金プランを提示する
→利用データがたまってきたら、上下に複数の料金プランを設定すればよい
・優れた無料プランとは何か
→無料体験版のようでなくてはならない
・体験版とフリーミアムのどちらを選択すればよいか

➤A.3 予告ページの作り方

インタビューを受けてもらうための戦術
→最終的には興味のない訪問者から興味のある見込み客になってもらわなくてはならない

*セールスレターの書き方
・大きな約束をする(UVP)
→心理学的法則:予測外で明快な力強い約束に注目が集まる
・顧客に結びつけて考える(課題)
→心理学的法則:顧客のことを理解すれば共感が得られる
・関心と欲求を生じさせる(ソリューション)
→心理学的法則:顧客にソリューションが課題を解決することを見せれば、関心と欲求が生まれる

*予告ランディングページの作り方
・製品の名前を選ぶ
・TwitterのIDとFacebookのページ名が取得可能か確認する
・最初はUVPのことだけを説明する
・基本はSEO
→タイトルタグには製品名よりUVPのキーワードを入れる
・ロゴは何でもいい
・メールアドレスの収集
・ウェブサイトを計測する

➤A.4 継続的デプロイのはじめ方

継続的デプロイのサイクル ー211
コミット→テスト→デプロイ→監視→コミットへ

*コミット
継続的デプロイがムダを排除するのは、仕掛品(デプロイされていないコード)を排除するから
デプロイされていないコードが増えれば慣性が大きくなりすぐに反応できなくなる

・小さなバッチでコードを書く
・trunkを常に安定させておく

*テスト
手動テストがないのが不安に感じると思うが↓
・テストはみんなの責任
・継続的インテグレーションサーバーを使う
・失敗するテストを大目にみてはいけない
・ユニットテストよりも機能テスト
・アクティベーションの流れからはじめる

*デプロイ
マシン台数が多くなる前に自動化しておく
・サーバーのインフラはできるだけ外部に委託する
・必要であればステージング環境をつくる
・ワンクリックデプロイスクリプトとロールバックスクリプト
・手動でデプロイしてから自動化する
・簡単な機能フリッパーシステムを実装する

*監視
予期しないエラーを自動的に検知したり、警報をだしたりするもの
→自動的に回復するものも
ただし、最初から完璧である必要はない
→監視システムの作りすぎはムダ

*すぐにできる監視からはじめる
Ganglia、Nagios、New Relicなど

*予期しない問題の再発を防止する
→五回のなぜをつかって真因を分析する

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

設計原則→データの収集とデータの可視化をわけるということ

➤A.6 データの収集方法

・指標とイベントを一致させる
・生のイベントを監視する
・すべてのログをとる
→イベントと一緒に「興味深い」属性もログに記録

*コンバージョンダッシュボードの可視化方法
・週次のコホートレポートを作る
・ファンネルを掘り下げる
・数字の理由を調べる

*定着の追跡方法
・アクティブユーザーの定義
→最も基本的なもの、ユーザーのログインを計測
ー220
エンゲージメントを測るなら「顧客幸福指数(CHI)」

・コンバージョンダッシュボードの定着を可視化する
・詳細なビューを提供する
→定着数の傾向を示すとよい

➤解説

ビジネスに興味のなかったソフトウェアエンジニアこそが読むべき本

この手法のメリットが最大にでるのは「コードがバリバリかける人」が起業するとき
✔「機能を小出しにリリースして顧客の反応を見てどんどんカイゼンしていく」というのがリーンスタートアップ手法の基本だから
ファウンダーは技術系が好ましい

結局、ITでの起業にはユーザーを理解するビジネスのスキルとコードを書くスキルの両方が必要

ただし、リーンスタートアップの手法は万能薬ではない
最も効果を生むのは製品/市場フィットにいたるまで

➤訳者あとがき

リーンスタートアップビジネスモデル・ジェネレーション
→手元にあるとよい

*新しいツールの登場
*戦略&リスクボード
[]プランBー破壊的イノベーシヨンの戦略
の影響
「類似例や反例の断片を混ぜ合わせて取捨選択することで、会社を業界で突出させられるような新しい戦略とビジネスモデルを生み出す創造的なるつぼができる」

*検証による学習ボード
リーンスタートアップの「構築ー計測ー学習ループ」を一覧にして、かんばんボードと組み合わせたもの
→リンク ー229

*訳者が選ぶ参考文献
ー230

読了 ー2/4 12:15

こちらもあわせてどうぞ