リーン顧客開発 ―「売れないリスク」を極小化する技術 (THE LEAN SERIES)

著者 : シンディ・アルバレス 児島修

制作 : エリック・リース 

• オライリージャパン (2015年4月25日発売)

作品紹介・あらすじ

リーン手法において核となる顧客開発について解説！
顧客開発とは『アントレプレナーの教科書』や『スタートアップ・マニュアル』の著作で知られるスティーブ・ブランクが提唱した考え方です。本書は、リーンスタートアップの中の顧客開発モデルにおいて、顧客ニーズやビジネスモデルを仮説検証する際に行う「顧客へのインタビュー」をはじめ、様々なテクニックと感が手について具体的に解説します。

感想・レビュー・書評

[University of the Ryukyus Libraryさんの感想 · 2024年1月10日]

【琉大OPACリンク】
https://opac.lib.u-ryukyu.ac.jp/opc/recordID/catalog.bib/BB18860815

[cmano8さんの感想 · 2023年8月14日]

- 顧客の声を聞いてサービスを作る、ということの概観を捉える本。MVPの話より、インタビューの話が中心。
- リーンってなんだ、からのこの本を手に取ったので、ちょっと思ってたのと違った。(開発フレームワークのような話は出てこない)
- いわゆる「インサイトを得る」ための「ヒアリング」系の本は、他にもいくらでもありそうだけど、この本は「開発をする人の視点で見たユーザーインタビューとは」という感じで書かれており、スモールにMVPまで行くための所作的なものは詰まっていそう。
- ただ逆に言うともっとモノづくり全体についてちゃんと(？)学びたければMVPをどう作るかから学んだほうが良いのかも。

[mcmrさんの感想 · 2023年2月25日]

2024/04
また読んだ。良書of良書

2023/02
以前読んだときも良書だな〜と思っていたが、顧客インタビューをするようになってから読んだら染み方が段違いだった。具体的な質問集があったり、プラクティスが載っていてかなり実践的な書籍だと思う。

[takashiiwasakiさんの感想 · 2023年2月15日]

・顧客インタビューが図々しいと思わないで良い。なぜならペインを抱えた顧客であれば嬉々としてそれを話す。話すことによって自分は優秀だという印象を与える機会をプレゼントしている

・顧客はいつか見つけなければならない。製品開発後ではなく、前に見つけるからこそリスクを最小化できる

・その他、インタビューの仕方やバイアスの認知の作法が網羅的に書かれているのでユースケースに合わせてリファレンス的に読む

[j-okさんの感想 · 2022年7月26日]

開発した製品が顧客が買わないものだったとしたら。。商品・サービス開発における最大のリスクを早期に回避するための顧客開発プロセス。

課題仮説の立て方からその検証のためのインタビュー手法、アプローチ方法など、実践する際の参考になる。つい抱いてしまう思い込みや、インタビューイーが悪意なくとる行動特性など知っておくべきTipsが多くあった。

まず何より、オフィスの外に出ることが大事だ。

[japapizzaさんの感想 · 2021年12月18日]

１章　なぜ顧客開発が必要なのか
　あなたの身近な人がそうであるように、人は自分の能力を過大評価しがちなものです。わたしたちのアイデアのほとんどは、顧客や会社にとって、価値を高めることにつながりません。Microsoftもアイデアのうち、想定通りの改善につながったものは３分の１であると言います。Amazonは試しに出した機能のうち、役立つものが50％未満としています。これはYammerでも同じですし、NetflixやIntuitmもこれより成功率が高いとは主張していません。

■まとめ
・顧客開発に1時間をかければ､文書作成やコーディングや設計の時間を5～10時間以上節約できる。
・顧客開発の目的は､ 顧客が欲しがるものについての誤った思い込みを早く見つけ、顧客が本当に購入してくれる製品の開発に集中できるようになることである。
・顧客開発はスタートアップだけでなく、あらゆる規模の企業に役立つ｡
・顧客開発は製品開発に代わるものではない。顧客開発は顧客が誰かを特定すると同時に、顧客の具体的な課題を解決する製品やサービスを特定する。
・顧客開発により､ プロダクトマネージメントに役立つ情報－何を構築し、どの機能を優先するかの決定をしやすくなる。
・誤った思い込みは、早く発見しなければならない。人には生まれつき見たいものを見て、見たくないものから目を背けようとする認知バイアスが作用していることに注意する。

２章　どこから始めるべきか？
■土台作り
・想定は何か？
・課題仮説は何か？
・ターゲット顧客のプロフィールは何か？

■想定を書き出すヒント
・顧客は＿＿＿についての課題を抱えている。
・顧客は、この解決のために＿＿＿を投資する用意がある。
・この製品の使用購入に関わるステークホルダーは、＿＿＿である。
・この製品の開発／流通に関わるパートナーは＿＿＿である。
・この製品の開発／サービス提供に必要なリソースは＿＿＿である。
・この製品を購入／使用しない顧客は、＿＿＿を購入／使用するだろう。
・この製品を使い始めた顧客は、＿＿＿を得ることができる。
・この問題は、顧客の＿＿＿に影響する。
・顧客はすでに＿＿＿のようなツールを使用している。
・顧客の購買決定は＿＿＿＿の影響を受けている。
・顧客は、［役職] [社会的アイデンティティ] だ。
・この製品は＿＿＿という理由で、顧客にとって有用になるだろう。
・顧客はテクノロジーに対して＿＿＿である。
• 顧客は変化に対して＿＿＿である。
・この製品の開発／製造には＿＿＿を要するだろう。
・＿＿＿社／人の顧客または＿＿%の市場占有率を得るには＿＿＿を要するだろう。

■まとめ
・チームで時間を作って想定を書きとめ、妥当性を検証する。チームメンバーの考えが揃っていると思うときでも、そうでないことが多い。
・課題仮説を書き出す（［顧客像］は、［タスク］をするとき、［課題］を抱えている）。
・仮説は可能な限り具体的にする。焦点を絞るほどすばやく検証できる。
・チームで特性の尺度を使ってターゲット顧客のプロフィールを作成する。


３章　誰と話をすべきか？
■まとめ
この章のまとめ
・想定する課題について、もっとも深刻に悩んでいる人を見つける。その人たちは課題を解決することを熱望し、エバンジェリストユーザーになる可能性のある人々である。
・相手は「誰かの役に立ちたい」「他者から賢いと思われたい」「物事を解決したい」という理由で、あなたに話をしたがっている。
・知り合いに人を紹介してもらう。その際、当てはまる相手をなぜ求めているのか、理由をはっきりと説明する。
・LinkedIn、Quora、Twitter、フォーラムなど､ オンラインのリソースを使って人を探す (ただしCraigslistは使わないように）。
・ターゲット顧客がオフラインで集まっている場所に行く。
・インタビュー依頼メッセージは、明確かつ簡潔にし､ 相手が簡単に応答できるようにする。
・インタビューの間隔を空け、インタビューが長引いた場合の対処や、次のインタビューまでに前のインタビューのまとめができるようにする。

４章　何を学習すべきか？
顧客は自分たちが何を欲しがっているのかを知らない
顧客は、文化的、時間的、物理的な制約を受けていることを知っているが、そのことを自発的に言及しようとはしない
顧客は過去に試みて失敗したことを覚えているのに、あなたに話すのは忘れてしまう
顧客は（少なくともある程度）自らの能力やその限界を認識しているが、それを自主的に話さない
顧客は使用しているツールやプロセスに詳しいからといって、仕組みを理解しているとは限らない
顧客は自分は何が欲しいのかを分からないかもしれないが、必要としているものは隠せない

■まとめ
・顧客開発の5つの基本的質問を使って、顧客に話をさせ、その内容にもとづいてさらに詳しい答えを引き出す。
・自由回答形式(｢はい/いいえ」形式ではない)の質問をすることで、顧客が表面的なものを越えた回答ができるように仕向ける。
・顧客が現状どんな行動をしているかを明らかにする。顧客の現状の行動はあなたの製品やサービスが取って替わろうとする競合と言える。
・抽象度のレベルを1つ上げて、視野を広げる。
・実際の行動と願望の比較に注目する。「Xをする見込みはどれくらいありますか?」と尋ねるのではなく、直近の事実についての質問をする (「一番最近Xをしたときについて教えてください」「先月、Xを何回行ないましたか?」など)。
・顧客が抱えているメンタルブロック(「課題を課題だと認識していない」「課題は修正できないと考えている」 ｢リソースが限られいる」「自らの行動を制限する期待を持つ」など) を理解し、そうしたブロックを乗り越えるための質問をする。
・意思決定に関与する他のステークホルダー (家族, マネージャー 友人など) がいるかどうかを確認する。

５章　オフィスから飛び出せ
■まとめ
・同僚を使って模擬インタビューを行なう。
・2人組でインタビューを行ない、インタビューを改善し、顧客開発に多くの人 (顧客と直接話をすることに居心地の悪さを感じている人も含む)を巻き込む。
・インタビューは気軽でパーソナルな調子を心がける。
・最初の質問の後、相手がスラスラとしゃべってくれず沈黙があっても追加の質問に移るまで60秒は待つ。
・メモを取るときは相手の感情面に注目する。感情の観察に優先度を置く。
・仮説の妥当性をサポート / 棄却するもの、意外なものには何であれ耳を傾ける｡
・顧客の話が脱線したときにも耳を傾ける。脱線が頻発するならそれは探すべき別の機会かもしれないと考える。
・顧客が機能やソリューションを提案したときは､ 顧客が解決したい課題の話に戻す。
・インタビューを改善し内容を復習するために、インタビューの直後にメモを振り返る。

６章　検証済みの仮説はどのように見えるのか？
■まとめ
・仮説の検証では懐疑的であること。
・顧客が課題を実際に解決しようとしたのかどうか、しっかり聞きこむこと。課題を解決すべきだと考えていても、実際には製品を購入しない人は多い。
・顧客の将来的な行動を予測する最善の方法は、現在の行動に注目することである。インタビューメモに感嘆符が多く書かれていても、実際に行動をした証拠がなければ､ 仮説を検証したことにはならない。
・インタビューの内容は、5点ほどの箇条書き項目にまとめる。各項目は、「仮説を検証するもの｣「仮説を棄却するもの」「他の興味深い点」に分類する。
・検証済の仮説には、次の要素が含まれる。顧客が「課題があることを確認していること」「それを解決できると確信していること」 ｢その解決を試みていること」「解決を妨げるものがないこと」。
・インタビューを5回も行なえばあなたのソリューションに興奮する人に会えるはず。そうでない場合は仮説が棄却されたと考える。
・10人にインタビューをすると、パターンが見え始める。パターンの存在を確認するために、次のインタビューでは、パターンとは別の行動を取る架空の「他の人たち」の話をして、インタビュー相手にこれら の人たちと同じ行動をするか､ それともパターンと同じ行動をするかを尋ねる。
・相手の話に驚きを感じなくなってくるのが、十分な数のインタビューを行なったことの目安になる。

７章　実用最小限の製品をどのように開発すべきか？
■まとめ
・MVPを開発するときは「顧客は製品から得る価値をどのように測定するか」を考える。
・「最小限」を順守する。すべての機能を含めようとしない。
・プレオーダーMVPでは、何らかの方法で顧客にMVPに支払いをさせる。支払いは「誓約」「事前注文」「基本合意書｣「パイロットプログラム」などの形態を取る。どれが効果的かを明らかにするためにいくつか 試してみること。
・オーディエンス開発MVPは、市場の開発を支援する。
・コンシェルジュMVPとオズの魔法使いMVPでは、市場があることを検証するために、手作業で課題を解決する。
・シングルユースケースMVPは、顧客の課題の一部を解決したり、単一の機能に焦点を当てる。
・他社製品MVPは、他者のアイデアを活用して､ 顧客の需要があるかを検証する。

８章　既存顧客がいる場合の顧客開発
　Yammerでは、MVPを「ユーザーに価値を提供し、かつ当該の文脈でのユーザーの振る舞いを学習するために開発が必要な、最小限の製品」と定義しています。「実用最小限の機能」は、顧客が作業を１つ行なえる機能と定義しています。アナリティクス機能を使って「顧客が作業を繰り返すか」を測定したり、定性的なユーザーリサーチを使ったりして「顧客がその作業をどのように感じたか」を学ぶことができます。成功するアプローチではたいていこの２つを組み合わせているのです。

■真のカスタマーインテリジェンス
　顧客自身が製品について話すときに選ぶ言葉は、製品の販売に役立つ。
　顧客が言及した（しなかった）機能は、将来の製品開発での優先順位付けに役立つ。

■まとめ
・すでに製品と顧客がある場合は､MVPもそれに合わせたものにする。
・認知度の高いブランドは見込み客にバイアスを生じさせる。別ドメインや、ノーブランドのスケッチを使えば「匿名の顧客開発」を実践できる。
・「最小限」よりも「実用性」優先させる。ただし、最小限を大きく越えないようにする。
・「製品を使えなくなったら失望する」顧客を探す。
・既存顧客を相手にして顧客開発を行なう場合は、「具体的な何かを開発中というわけではなく、調査段階である」と徹底して説明する。
・ストーリーテリング・デモを使って、架空の人物が製品をどのように使うかを顧客に説明する。
・顧客に、製品を普段どのように使っているかたずねる。
・まだ顧客がいない場合は、製品の想定している使用方法を説明する。その際、断定的な話し方をすることで、相手が反対意見を述べやすくする。

９章　継続的な顧客開発
　Palantirではエンジニアは最初のうちは製品を開発せず、現場で顧客と直接話をして製品が顧客のニーズを満たしていることを確認します。Palantirのエンジニアは、顧客の課題にその場で取り組むことができるのです。何より、顧客がまだ気づいていなかったり、自分では気づかない新たな課題が明らかになることもあるのです。

「わたしはテクニカルサポートのログを分析してもっとも頻繁に生じている問題をつきとめ解決策を提案しました。顧客からの電話による問い合わせの最大の原因になっていたのは、アプリケーションで表示される画面のひとつでした。この画面はスタジオ経営の顧客が価格設定するために頻繁に使うものでしたが、悪夢のように複雑で使いにくいものでした。調査の結果平均的な顧客は15個のオプションのうちわずか４つしか使っていないことがわかりました。そこでほとんど使われていない11個のオプションは［詳細設定］をクリックするまでに表示させないようにしたところ、問い合わせの件数が激減しました。開発の初期段階から顧客と話をしていればこれらのオプションはそもそも開発不要と判断できていたかもしれません。」

■KISSmetricsの４つのＡ
・謝る(Apologize)
・非を認める(Admit)
・質問する(Ask)
・感謝する(Appreciate)

■まとめ
・顧客と話をしている社員全員に､ 顧客開発に参加するための簡単な方法を教える。
・顧客から機能要求をされたら、 ｢もし今その機能があったら何をするか」を尋ねる。
・顧客が何に価値を置いているかを理解するために、もっともアクティブで熱心な顧客にその製品を人にどのように説明するかを尋ねる。
・顧客開発の成果を社内で共有する。顧客から学んだことを示すことで、ポジティブな変化が生まれる。
・問題があることを示す最善のシグナルは、カスタマーサポートで生じている。
・怒っている顧客に質問をし、話に耳を傾けることで、課題の詳細を学ぶことができる。真摯に話を聞くことは顧客から学ぶ機会になるだけではなく､顧客の態度を和らげる効果がある。
・本当の課題を知るために、質問をしなければならない理由は、顧客が1つの根本的な課題を解決するために、異なる提案をする場合があるためである。また顧客は、根本的な課題が異なるのに、同じような提案をすることもある。
・顧客に電子メールを送るときに、メッセージの末尾に質問を追加する。質問には、回答結果を集計して評価できるような枠組みを作る。

[しょたろさんの感想 · 2021年3月29日]

LEAN 顧客開発　「売れないリスク」を極小化する技術
 
スタートアップには、「顧客開発」と呼ぶプロセスが欠けていると認識するに至った。
 
■顧客開発を実践できるのは誰か？
・以下3つの資質があれば、この本を読むことで、顧客開発をすぐに実践し始められるようになる。
・顧客開発とは、仮説検証と学習のための継続的なプロセスである。
●学ぶことへの飽くなき探究心がある
●不確実性を楽しめる
●現実を受け入れ、それを周囲に伝えていくことへのコミットメントがある
 
■1章：なぜ顧客開発が必要なのか？
・「顧客とは誰か」「顧客は何を必要としているか」「顧客はなぜ、いかにして製品を買うのか」「についての想定を問い直すことが、ビジネスのリスクを減らすことに繋がる。顧客を科学的に理解することによって、有効なビジネスモデルを確立し、顧客が求める製品を開発しやすくなる。
 
■顧客開発とは何か？
・顧客は誰か？
・顧客の問題やニーズは何か？
・顧客の現在の行動は何か？
・顧客が進んで購入するソリューションは何か？（製品が開発前/未完成であっても）
・顧客の意思決定、調達、購入、使用に合わせたソリューションの提供方法は何か？
 
■リーン顧客開発とは何か？（5つのステップで行われる）
・1.仮説を立てること
・2.潜在的な顧客イメージを明確化すること
・3.適切に質問すること
・4.受け取った答えを正しく解釈すること
・5.製品の仕様を明確化し、学びを取り込み続けること
 
■1章のまとめ
・顧客開発に1時間をかければ、文章作成やコーティングや設計の時間を5〜10時間以上節約できる。
・顧客開発の目的は、顧客が欲しがるものについての誤った思い込みを早く見つけ、顧客が本当に購入してくれる製品の開発に集中できるようになることである。
・顧客開発はスタートアップだけでなく、あらゆる規模の企業に役立つ。
・顧客開発は製品開発に代わるものではない。顧客開発は顧客が誰かを特定すると同時に、顧客の具体的な課題を解決する製品やサービスを特定する。
・顧客開発により、プロダクトマネージメントに役立つ情報―何を構築し、どの機能を優先するかーの決定をしやすくなる。
・誤った思い込みは、早く発見しなければならない。人には生まれつき見たいものを見て、見たくないものから目を背けようとする認知バイアスが作用していることに注意する。
 
■2章：どこから始めるべきか？
・仮説を明確化する
・課題仮説を明確に記述する
・顧客プロフィールをマッピングする
 
●想定の明確化（想定を書き出すヒントを以下に紹介）
・顧客は____についての課題を抱えている。
・顧客は、この課題の解決のために____を投資する用意がある。
・この製品の使用/購入に関わるステークホルダーは____である。
・この製品の開発/流通に関わるパートナーは____である。
・この製品の開発/サービス提供に必要なリソースは____である。
・この製品を購入/使用しない顧客は____を購入/使用するだろう。
・この製品を使い始めた顧客は、____を得ることができる。
・この問題は、顧客の____に影響する。
・顧客はすでに____のようなツールを使用している。
・顧客の購買決定は____の影響を受けている。
・顧客は、[役職]、[社会的アイデンティティ]だ。
・この製品は____という理由で、顧客にとって有用になるだろう。
・顧客はテクノロジーに対して____である。
・顧客は変化に対して____である。
・この製品の開発/製造には____を要するだろう。
・____社/人の顧客または____ %の市場占有率を得るには____を要するだろう。
 
●課題仮説の記述（次のフォームに、課題仮説を書き込んでみる）
[顧客像]は、[タスク]をするとき、[課題の内容]という課題がある。
または、
[顧客像]は、[制限/制約]のために、 [課題]を体験している。
 
■2章のまとめ
・課題仮説を書き出す（[顧客像]は、[タスク]をするとき、[課題]を抱えている）
・仮説は可能な限り具体的にする。焦点を絞るほど素早く検証できる。
・チームで特性の尺度を使ってターゲット顧客のプロフィールを作成する。
 
■3章：誰と話をすべきか？
●エバンジェリストユーザーの重要性
・探し出したいのは、熱心で情熱的な顧客。言い換えれば、課題を解決したいと強く思っている人たちのこと。
・探したいのは「課題に直面しその解決を試みている人」。これらの人々はアーリーアダプターとは違う人種で、特にテクノロジー好きなタイプでも、新しいものを積極的に取り入れようとするタイプでもない。これらの人々はただ「解決すべき課題を抱えている」のだ。
・エバンジェリストユーザーは、自分の課題やニーズや環境について、細かく教えてくれる。そうした人は頼んでもいないのに、不恰好で欠陥だらけのベータ版をせっせと試しては、大量のバグや多くの建設的な提案を記した長い電子メールを送ってくれます。その上、知り合いにあなたの製品を勧めてくれることもあります。切実な課題を抱えてイライラしたり腹を立てたりしているからこそ、あなたが作ろうとしている製品が、課題の解決に役立つかもしれないと期待して、自分のメリットのために必要な情報を提供してくれる。
 
■4章：何を学習すべきか？
●顧客は自分たちが何を欲しがっているのかを知らない
「顧客が何を求めているかについて探すのは、顧客の仕事ではない。あなたの仕事だ」―スティーブ・ジョブズ
・顧客が欲しがっているものと、実際に必要としているものは、はっきりと違う。
 
●どのような制約が顧客を押しとどめているか？
・実際には、多くの顧客は制約を受けている。こうした制約には、客観的な事実というより主観的なものも含まれているが、だからといって影響が少ないわけではない。顧客を抑え込んでいる制約のタイプを正しく理解できるかどうかによって、フォローアップの質問を価値のあるものにできるか、どのタイプのソリューションが最終的に効果的なものになるか、が決まる。
・一般的な制約の例を列挙。
┗課題が課題と認識されていない。
┗技術的に可能なことについての認識の欠如。
┗リソース（環境、時間、予算）が限られている。
┗行動を制限する文化的/社会的期待。
 
●顧客のフラストレーション（またはモチベーション）を高めるものは何か？
・あなたの製品がターゲットにする顧客を喜ばせる要素が、別の顧客にとっては気に入らないこともある。ですから、あなたの製品がターゲットにする顧客を喜ばせるものは何か、逆にどのようなことをしてしまうと製品を買わなくなるかを十分に考えておく必要がある。
・私たちがこれまで経験してきた顧客の満足をそぐ最大の要因の1つは「分かりにくさ」です。サービスの仕組みや、製品の活用方法が分かりづらいと、顧客は強い不快感を覚えてコストを払いたくなくなります。こうした顧客が手間やコストをかけてくれなくなってしまうのは、新製品を立ち上げようとする私たちにとって、深刻な問題です。そうならないように全力をあげなければなりません。
・あなたの製品が提供する価値は、顧客の価値観にあっていなければなりません。例えば、競合と競争に明け暮れている顧客なら競合に対する優位が重要でしょうが、競合ではなくお客さんの方を向いていて「ありがとう」を聞こうとしている顧客には、そうした競合優位のメリットをアピールしても意味がありません。
 
■4章のまとめ
・顧客開発の5つの基本的質問を使って、顧客に話をさせ、その内容に基づいて更に詳しい答えを引き出す。
・自由回答形式（「はい/いいえ」形式ではない）の質問をすることで、顧客が表面的なもおを超えた回答ができるように仕向ける。
・顧客が現状どんな行動をしているかを明らかにする。顧客の現状の行動はあなたの製品やサービスが取って替わろうとする競合と言える。
・抽象度のレベルの1つ上げて、視野を広げる。
・実際の行動と願望の比較に注目する。「Xをする見込みはどれくらいありますか？」と尋ねるのではなく、直近の事実についての質問をする（「一番最近Xをした時について教えてください」「先月、Xを何回行いましたか？」など）。
・顧客が抱えているメンタルブロック（「課題を課題だと認識していない」「課題は修正できないと考えている」「リソースが限られている」「自らの行動を制限する期待を持つ」など）を理解し、そうしたブロックを乗り越えるための質問をする。
・意思決定に関与する他のステークホルダー（家族、マネージャー、友人など）がいるかどうかを確認する。
 
■付録：効果的な質問
●A.1 顧客開発インタビュー全般で使える質問
・1.前回____をしたときのことを教えてください
・2.もし魔法の杖を振って[タスクの実行]方法を何でも変えられるなら、何をしますか？
・3.____のためにどのようなツールを使っていますか？
・4.[ツール]を使い始めたとき、どのようなメリットを期待していましたか？
・5.どのくらいの頻度で____を行いますか？例えば先月は何回行いましたか？
・6.この現象が発生した場合、どの程度の時間やお金が追加コストとして発生しますか？
・7.他に誰がこの問題を体験していますか？
・8. ____を行う（または使う）とき、その直前に準備していることはありますか？
・9.ユーザーリサーチやβテストにご参加いただけますか？
 
●A.2 既存製品に関する質問
・1.[私たちの製品]を使用するとき、最初に行うことは何ですか？
・2.私たちの製品で日常的に行っていることの中で、あなたにとって最も有益なのは何ですか？
・3.もし、[要求された機能]があったとしたら、あなたの暮らしはどのように良くなるのですか？
・4.他の顧客は、[課題]を体験していると言っています。

[air1さんの感想 · 2021年1月19日]

顧客との会話を重視すること。
インタビュー相手の探し方、具体的な質問例などを紹介。

[Yomosukeさんの感想 · 2020年12月19日]

新規プロダクトを作る際に、いかにその対象となる顧客を開発していくのか具体的な方法が書かれている。新機能や新サービス、大小あれど方法論として参考になる部分は多いと思う

[rio-purpleさんの感想 · 2019年10月22日]

第1章 なぜ顧客開発が必要なのか
顧客開発とは、顧客の特定・分析
・「製品開発」を補完するために同時に実施し、MVPを小さくできる
・ユーザーリサーチと手法は同じだが、使われ方や実施者が違う（？）
・リーン顧客分析のプロセスは、仮説立案→Intvによる仮説修正/検証→製品への落とし込み

第2章 どこから始めるべきか
・顧客の課題や製品内容について、
①想定の明確化：付箋によるグループワーク、ビジネスモデルキャンバス
②課題仮説の記述：5W1H、検証しやすいよう具体的に
③顧客プロフィールのマッピング：顧客特性の軸をとる（節約重視/時間重視）

第3章 誰と話をすべきか
・課題を解決しようとしている顧客は、Intvやレビューに協力的
・見込み顧客は、知人の紹介やLinkedin・実際の店舗での声かけで見つける
（BtoCだと20人くらいユーザを見つける）

第4章 何を学習すべきか
・顧客が今していること
・顧客の持っている制約
・フラストレーションやモチベーションを高めるもの
・頻度（広さ）、なぜ困るのか（深さ）を定量化

第5章 オフィスから飛び出せ
・最初の質問の後、相手が沈黙しても次の質問まで60秒まつ
・機能、ソリューションより課題を探る
・仮説と逆の例を出して、誘導尋問を避ける
・「もし魔法の杖がつかえたら、XXをどう変えますか」実現性を無視して対応

第6章 検証済みの仮説はどのように見えるのか
・顧客が言行一致とは限らない
・すでにあるものと比較する
・5人インタビューすれば1人は熱狂するひとがいる

第7章 実用最低限の製品をどのように開発すべきか
・プレオーダーMVP：クラファン、いいねボタン

第8章 既存顧客がいる場合の顧客開発
・製品がなくては生きていけない人を見つける
・「製品がなくなったらとても失望する」4割以上いると筋がいい
・他社の例として紹介するとバイアスをとりのぞける

第9章 継続的な顧客開発
・機能追加の要望には、その理由を確認する