リーン顧客開発 ―「売れないリスク」を極小化する技術 (THE LEAN SERIES)
- オライリージャパン (2015年4月25日発売)
本棚登録 : 408人
感想 : 20件
１章 なぜ顧客開発が必要なのか
あなたの身近な人がそうであるように、人は自分の能力を過大評価しがちなものです。わたしたちのアイデアのほとんどは、顧客や会社にとって、価値を高めることにつながりません。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つの根本的な課題を解決するために、異なる提案をする場合があるためである。また顧客は、根本的な課題が異なるのに、同じような提案をすることもある。
・顧客に電子メールを送るときに、メッセージの末尾に質問を追加する。質問には、回答結果を集計して評価できるような枠組みを作る。
0
- 感想投稿日 : 2021年12月18日
- 読了日 : 2021年12月18日
- 本棚登録日 : 2021年12月18日
みんなの感想をみる
