メインコンテンツへ移動

プラクティスのナレッジベース

Customer-Centricity Reviews

定期的な顧客のフィードバックやストーリーのレビューは、チームが製品の実際のメリットを理解し、日々の業務をユーザーニーズに結び付けるのに役立ちます。

組織 チーム customer-centricity-reviews
ドキュメントのセクション

これは何か

Customer-Centricity Reviewsは、チームが顧客のフィードバック、問い合わせ、インタビュー、ストーリーを読み、実用的な結論を導き出す短い定例の習慣です。このプラクティスは、製品に関する議論を内部の計画や指標だけでなく、実際の人々の課題に立ち返らせます。チームが生の顧客シグナルにアクセスでき、結論をアクションに移すオーナーがいる場合に最も効果的に機能します。

役立つとき

  • 従業員が、製品が顧客に提供するメリットを十分に理解していない。
  • チームが、実際の顧客の問題を根拠とせずに優先順位について議論している。
  • フィードバックで同じ不満が繰り返されているが、製品や運用上の決定に反映されていない。
  • 人々が自分の仕事と会社のミッションとの関連性を見出せていない。
  • 欠陥や緊急のタスクだけに焦点を当てることで、製品に対する誇りが低下している。

始め方

  1. 1 顧客シグナルのソースを1つ選びます:サポートへの問い合わせ、フィードバック、インタビュー、または営業記録。
  2. 2 毎週3~5件の新しい事例を収集し、個人情報を除去するオーナーを任命します。
  3. 3 チームで短いレビューを実施します:顧客が何をしようとしていたのか、どの時点でメリットや問題が生じたのか、何が私たち次第なのか。
  4. 4 1つの結論と1つのアクションを記録します:タスクの明確化、テキストの修正、仮説の検証、または問題のオーナーへの引き継ぎ。
  5. 5 次のレビューで、選択したアクションがどうなったか、次のステップが必要かを確認します。

期待される効果

チームは、誰のために働いているのか、どの顧客の問題が繰り返されているのかについて共通の認識を得ます。マネージャーは優先順位を製品のメリットと結び付けやすくなり、従業員は自分の役割が顧客の成果にどのように貢献しているかを確認できます。

よくある間違い

  • レビューを、顧客の不満の繰り返される原因を探す代わりに、責任追及に終始させること。
  • 目立つ称賛だけを共有し、都合の悪いシグナルを議論しないこと。
  • フィードバックを収集するだけで次のアクションがないため、ミーティングがすぐに形骸化すること。
  • 個人情報や機密情報を除去しないまま、チームに生の顧客データを提供すること。
  • この定例の習慣が本格的な製品リサーチやサポート業務の代わりになると期待すること。

さらに詳しく読む

  • 書籍:Clayton Christensen、『Competing Against Luck』
  • 書籍:Marty Cagan、『Inspired』
  • 書籍:Teresa Torres、『Continuous Discovery Habits』
  • 記事:Harvard Business Review、製品意思決定におけるJobs to Be Doneの理解

FAQ

このプラクティスのオーナーは誰が務めるべきですか?

通常、オーナーは製品、カスタマーエクスペリエンス、またはチームのマネージャーの近くにいます。重要なのは、信頼できる顧客シグナルを選択し、結論を具体的な業務アクションに落とし込めることです。

1回のレビューにはどれくらいの時間がかかりますか?

最初は短い定期的なミーティングで十分です。主な時間は議論ではなく、良い事例の準備と明確な次のステップの文書化に使われます。

リサーチャーやコンサルタントなしで始められますか?

はい。すでに利用可能なサポートへの問い合わせ、フィードバック、営業メモ、または公開されている顧客のコメントから始めましょう。これを市場調査にしてはいけません。最初のステップの目的は、顧客の生の声を業務上の意思決定に戻すことです。

チームがネガティブなフィードバックに対して防衛的になった場合はどうすればよいですか?

人とシステムを切り離してください。誰が間違えたかではなく、どのカスタマージャーニーが壊れたのか、どの製品の約束が機能しなかったのか、そしてチームが検証できる小さな一歩は何かを議論します。

このプラクティスが機能しているかどうかは、どう判断すればよいですか?

レビュー後に具体的な解決策が生まれているかを見てください:明確化された優先順位、修正されたテキスト、引き継がれた問題、新たな仮説。ミーティングが業務を変えていない場合は、フォーマットを簡略化するか、シグナルのソースを変更する必要があります。