リーン顧客開発（売れないリスクを極小化する技術）
※私個人が特に学びになった部分のみピックアップして紹介
第1章 なぜ顧客開発が必要なのか
顧客開発とは何か
- ビジネスが成り立つための大前提について、仮説検証を繰り返すアプローチのこと
- 顧客開発では、仮説や思い込みが本当にその通りなのか徹底的に検証する
- 起業する時、新製品を開発する時、新機能を追加する時のいずれも適用できる
リーン顧客開発とは何か
- リーン= 実用的、現場での使いやすさ、手軽さ
- リーン顧客開発に1時間を費やすことができれば、文書作成、コーディング、設計の作業を5-10時間以上削減できる
- リーン顧客開発はスタートアップだけでなく、あらゆる規模の企業に役立つ
リーン顧客開発のステップ
- 仮説を立てる
- 潜在的な顧客イメージを明確化する
- 適切に質問する
- 受け取った答えを正しく解釈する
- 製品の仕様を明確化し、学びを取り込み続ける
第2章 どこから始めるべきか
- 想定の明確化の書き出し
- 顧客は〇〇についての課題を抱えているはずだ
- この製品を購入しない顧客は〇〇を購入するだろう
- 人工統計データは顧客ではない
- 少なくとも、数千、数万の単位で製品が出荷されるようになるレベルに到達するまでの間は、素晴らしい製品を作るためには、具体的で詳細な描写が可能な少ないサンプル情報の方が重要
第3章 誰と話をすべきか
製品を開発する前にどうやって顧客を見つければいいのか
- 製品の開発前に顧客を探すことで、売れない製品を作るリスクを避けることができる
- 製品の開発前に顧客を探すのは、製品の開発完了の後になって探すのと同じこと
エバンジェリストユーザーの重要性
- 探したい顧客像は、実際に課題に直面し、その解決を試みている人やまだ有効性が証明されていない未完成の製品をリスクを承知で積極的に使う人（エバンジェリストユーザー）
- エバンジェリストユーザーは、頼んでもいないのに、不格好で欠陥だらけのベータ版をせっせと試しては大量のバグや多くの建設的な提案を記した長い電子メールを送ってくれる
- エバンジェリストユーザーは好意でそうしてくれるのではなく、切実な課題を抱えてイライラしたり腹を立てているからこそ、課題の解決に役立つかもしれないと期待して、自分のメリットのために必要な情報を解決してくれる
第4章 何を学習すべきか
- 顧客開発の基本的質問を行いつつ、相手が質問に対して答えた内容に対してオープンエンド型(はい/いいえで回答できないような質問)質問を行うのが効果的
- 抽象化のレベルを1つあげて質問することが必要
- 例えば、顧客には「インターネットでの食料品の注文方法」を尋ねるのではなく、「家族の食事の世話をどうしているのか」を尋ねる
- 顧客に最大の価値をもたらす機能かどうかの見極めのポイントとしては、「将来」ではなく、「現在や直近の過去」に注目する
- 私たちは、近い将来の物事と、遠い将来の物事について違う基準で選択をしている（本気度が違う）
- 遠い将来のことほど高潔な判断基準を持っている（スポーツジムの会費は支払うのに、事務にはろくに通わない）
魔法の杖
- 解決先のない課題は、顧客に課題として認識されていない可能性がある
- 「現実的な考えは一旦捨てて、もし魔法の杖を振ってなんでも解決できるとしたら、何をしますか?」とハードル下げて問うことで、顧客側からもっともな課題や創造的なアイデアを話し出すことがある
第5章 オフィスから飛びだせ
なぜ?をうまく使う
- 5Whys
- 課題に対する表面的な答えよりも、根本原因を見つけるための技法
欲しいものリストは避ける
- 顧客の要求通りに作ったものは、失敗するケースが多々ある
- 願客が望むものを知る必要はなく、顧客がどのように行動しているか、顧客が何を必要としているか、言い換えれば、顧客が欲しがるソリューションよりも、課題の方に焦点を当てる必要がある
第6章 検証済みの仮説はどのように見えるか
- 相手が受け身でハイと答えた場合、重要性は低く見積もる
- 顧客になる人とならない人の話し方なパターンの比較
- 前者は能動的で具体的な話をしてくれる、後者は受動的な過程に基づいた話をする
第7章 実用最小限の製品をどのように開発すべきか
- MVPを作る上で、「顧客に価値を示すための十分な体験を提供すること」｢仮説を証明/棄却するために十分な情報を提供すること」の2つの観点で考える必要がある
- たとえば、Googleアドワーズ広告の購入は良いMVPだとは考えない。Googleアドワーズ広告によってわかることは、ユーザーがリンクを何回クリックしたかということだけで、「なぜ」ユーザーがクリックをしたのかはわからず、クリックしたからといって、そのユーザーがお金を使うと想定することもできないため
MVPの種類
プレオーダーMVP
- 顧客に支払いの意思があるか確認する上でとても効果的なMVP
- 例.クラウドファンディング、誓約、プレオーダー、基本合意書、パイロットプログラム
オーディエンス開発型MVP
- プレオーダーと違い、支払いの意思は確認できないが、顧客の維持と参加を測定できる
- ブログ、メーリングリスト
コンシェルジュMVP
- 顧客の課題を手作業で解決する
- 顧客も手作業であることを知っている
- スケーラブルではなく、自動化もされていないが、需要を検証できる
オズの魔法使いMVP
- 表面的には自動化プロセスにより、顧客の課題を解決しているようにみせかけ、裏側では人間が実行している
- スケーラブルではない。
シングルユースケースMVP
1つの課題やタスクのみに焦点を当てた製品や技術。これにより、1つの仮説を検証できる
他社製品MVP
- 競合他社のリソースを基礎的な道具にすることで、迅速な学習と検証が可能にする
- 競合についての詳細を学び、競合に対抗するための自社の利点を明らかにすることもできる
- 他社製品MVPは、以下のような状況で効果的
- 競合他社によってすでに確立された市場に参入する場合
- チームのエンジニアリングリソースが限られている場合
第8章 既存顧客がいる場合の顧客開発
- 顧客が失望を感じているなら十分なMVPではない。顧客が不満を口にしているなら良いこと。
- 最小限の機能と完全な機能を慎重に区別したケース
- MVPへのよくある反論と答え
- 製品を顧客に売り込む際は、「すばらしい製品を売ること」ではなく、「製品によって顧客をすばらしい気持ちにさせること」という観点が重要
ソフトウェアは顧客のワークフローに沿っているか?
- あなたが提案する操作手順が、顧客の手順や社内の規則となじまないことがある。あなたが「1人が、1セッションで完了する」と想定しているプロセスには、実際には複数のセッションが必要だったり、複数のプロセスに分かれて上司の承認を得るために一旦中断しなければならなかったりすることがある
第9章 継続的な顧客開発
- 要求は1つでも、根底の課題は複数ある。反対に、要求は複数でも根底の課題は1つしかない場合がある
- 顧客には、目の前の課題よりもただ機能要求の話をしがちな傾向がある。抽象度のレベルを1つ挙げて話を理解しなければならない。
付録
顧客開発を実践する上で、効果的な質問の例を複数列挙