顧客に欲しいものを尋ねるやり方は効果がない

顧客に欲しいものを尋ねることがなぜ効果的でないのか

• どのチームも、自分たちの視点を裏付ける情報だけを見る確証バイアスに陥っている。
• 各チームの視点は間違ってはいないが、顧客が製品を「雇う」本当の目的を反映できていない。

Intuitの事例: 顧客の要望に応えることの問題点

• Intuitの開発チームは、顧客が望む新機能について大規模なアンケート調査を実施した。
• 顧客のフィードバックに基づいて機能を追加したが、顧客が製品を雇う本当の「仕事」を理解できておらず、正しい機能を選ぶことに失敗した。

ミルクシェイクの販売増加事例

• あるファストフードチェーンが、ミルクシェイクの売上を増やす方法を研究した。
• 顧客のフィードバックに従ってさまざまな試みを行ったが、売上に変化はなかった。
• ミルクシェイクを「雇う」仕事という新しい視点からアプローチし、朝の時間帯にミルクシェイクを購入する顧客の本当のニーズを把握した
  • 午前9時前に来た客がミルクシェイクを多く買い、しかもそれだけを買っていった
  • 彼らに、なぜミルクシェイクを「雇った」のかを尋ねた
  • 長距離運転のとき、バナナはすぐに空腹になり、ドーナツは崩れやすくベタつき、ベーグルは乾いていて運転中にクリームチーズを塗ることもできない
  • しかしミルクシェイクは、運転の多い朝の空腹を満たすのに最適だった

仕事を見つける方法

1. 身近なところで仕事を見つける

• 世界的なイノベーターが、直感だけで成功した事例がある。
• 例えば、Khan Academyはサル・カーンがいとこの数学学習を助けるために始めたプロジェクトである。

2. 何とも競合していない

• 消費者が満足できる解決策を見つけられず、何もしない場合がある。
• Airbnbによれば、顧客の40%はAirbnbがなければ旅行をしなかったという。

3. 回避策と補償行動

• OpenTableは、人々がレストラン予約を回避する方法から生まれた。
• 不便な予約プロセスを解決して成功した。

4. 人々がやりたがらない仕事を見つける

• ネガティブな仕事は、しばしばイノベーションの機会になる。
• CVS MinuteClinicsは、医療サービスに対するネガティブな経験から出発した。

5. 異常な使われ方

• 人々が仕事を解決するために回避策や補償行動を使っているのを観察すると、イノベーションの機会になり得る。

GN⁺の見解

• 顧客が製品を「雇う」本当の「仕事」を理解することが重要である。
• 単に顧客の要望を聞くのではなく、彼らの本当のニーズと問題を把握することがイノベーションの鍵である。
• この記事は、イノベーションと顧客中心の思考に関心がある人に興味深いインサイトを提供する。

[GN⁺]

Hacker Newsの意見

• プロダクト管理における古典的な失敗:

  • ユーザーが自分の欲しいものを分かっていると仮定するのは、まれにしか当てはまらず、実際に必要なものを見極めるのがプロダクトマネージャーの役割である。
  • ユーザーが欲しがっているものを作っていると仮定しても、それはユーザーが実際に使ってみるまで証明できず、多くのスタートアップが誰にも望まれていない製品を作る罠に陥る。
  • ユーザーの要求が本当に必要なものだと仮定するのは危険であり、なぜそれを求めているのか、実際に作ったら使うのか、そしてそれがどれほどの価値を持つのかを常に把握しなければならない。
  • 営業チームが顧客の希望だと言うことが、本当に顧客の望みや必要性を反映していると仮定するのは厄介で、ときには営業チームの分析が誤っていることもある。
  • 特に新製品では、ユーザーがそれを望んでいるかを見極めるのは難しく、ユーザーは新しいものを要求しないこともあるため、製品を提示して説明する必要があり、それでも理解してもらえないことがある。

• XY問題に見せかけた機能リクエストの例:

  • メールサポートを多く担当しているあるユーザーは、機能リクエストがXY問題を装っているケースを数多く見つけている。
  • ユーザーが要求した機能を実装する前に、まず根本的な問題を理解しようと努めており、ほとんどの場合、ユーザーは問題ではなく自分たちの解決策を語っている。
  • 機能をエレガントに追加し、他の人にも役立つ形で文書化するためには、その機能が解決しようとしている根本的な問題を理解する必要がある。
  • ときには問題が社内的なもので、営業チームには必要でも、顧客は実際には使わない機能が追加されることもある。

• 製品の歴史と顧客の要求:

  • ある製品の歴史は、顧客（銀行）が自社のビジネスをどう捉えているか、そして製品がそれをどう改善できるかに関心を持ったことから始まった。
  • 途中で、10社以上の異なる顧客を満足させようとすると、結局は何も残らないことに気づいた。
  • 現在、その製品は特定のソフトウェアや技術というより、ターンキー型のコンサルティングパッケージに近い。顧客は今では、ビジネス運営の方法に関する指針を製品に求めている。
  • この種の顧客は群れで動く傾向があり、いったん数社の顧客を特定の方向へ動かせば、残りはほとんど労力をかけずについてくる。

• 記事タイトルへの意見と顧客ニーズの把握:

  • 記事は良いが、タイトルは気に入らないという意見を述べている。
  • 顧客には多くを尋ねるべきだが、その言葉を額面どおりに受け取らず、問い続け、深く掘り下げる必要がある。
  • 顧客が求める機能をそのまま実装するのは破滅への確実な道であり、フィードバックの聞き方を学ばなければならない。
  • ChristensenとDemingの勧めに同意し、さらにSidney Dekkerの『Field Guide to Human Error』を推薦している。

• 顧客の要求と製品設計:

  • たいていの人は自分が何を望んでいるのか分かっていないため、優れたプロダクトデザイナーには大きな価値がある。
  • プロダクトビジョンとフィードバックの聞き方は区別しなければならない。
  • プロダクトビジョンは、経験、直感、技術的知識、既存の代替案の観察、技術的・経済的・社会的変化を予測する方法などを必要とする技能である。
  • フィードバックを聞くことは、ユーザーが何に混乱し、何に妨げられているかを特定することに関わっており、そのためにはユーザー観察、テスト、アンケートなどの従来手法が有効に使える。
  • この二つはまったく異なるスキルセットであり、どちらか一方でも習熟するのは難しいのに、両方に長けるのはなおさら難しい。
  • Intuitをケーススタディとして使った記事では、顧客の望むものを提供しようとする試みが説明されている。

• 少数の顧客意見に耳を傾けることの危険性:

  • 少数の顧客の意見に耳を傾けることは落とし穴になり得る。
  • たとえば、Hacker Newsやその他の技術に明るいプラットフォームを読んでいると、小さな画面のiPhoneに大きな需要があると思うかもしれない。
  • しかし実際には、iPhone miniの販売実績は期待外れであり、技術系ハードウェアについてオンラインで多く書く人たちは、iPhoneユーザー全体を代表しているわけではない。

• 顧客の意見を聞いて理解することの重要性:

  • すべての人の意見に耳を傾けることは役立つ場合があり、不満を聞いて理解することは、誰かをより良くする最も簡単で安価な方法である。
  • ほとんどの場合、要求を満たすことはできないが、人々の話に耳を傾け、問題を明確にし、理解しようと努めることは、その人たちをより良くする。
  • 人はたいてい自分が何を望んでいるのか分かっていないが、プロダクトマネージャーは製品のビジョンと、それが問題の背後にある問題をどう解決するのかについて、全員を納得させなければならない。

• 顧客フィードバックによる製品改善:

  • スタートアップ／中小企業モードでは、顧客フィードバックを実際に役立つソリューションへと変換することに長けた創業者がいた。
  • 買収後に創業者は会社を去り、今では企業のUXチームが、最も不慣れなユーザーにどう動作すべきかを尋ねる動画をメールで送ってくるようになった。
  • テストグループへの参加に同意する人たちは、基本的なUIメタファーを理解できない人々を自己選別しているように見える。