フィードバックは、ほかのどのプロダクトシグナルよりも多様な形で届きます。アンケートの回答、サポートチケット、機能リクエスト、公開ボードへの投票、そして何かが壊れているとしか書かれていないバグ報告。一つひとつはただの逸話です。必要なのは、逸話の山を優先順位を付けられるものに変えることで、それは主に3つの習慣にかかっています。役に立つ答えが返ってくる質問をすること、その人が何をしていたかという文脈を残すこと、そして一番大きな声ではなくパターンを取り上げることです。
以下の記事は、フィードバックを集めるフォームから、要望に投票するボード、セッションが添付された状態で届くバグ報告まで、一連の流れ全体を扱います。どれも同じところに行き着きます。顧客が伝えたことがその後どうなったかを、顧客に伝えるチームです。
読む順番
どこから読むか
- SaaS 向けカスタマーフィードバックフォーム:何を尋ね、回答をどう活かすか
出発点から始めましょう。ノイズではなくプロダクトの証拠になる質問はどれか、どの質問にどの形式が合うのか、そしてなぜ各回答をその発生元のセッションとひも付けておくべきなのかを解説します。
- フィードバックをロードマップの根拠に変える
集まった回答をどうするか。要望とその裏にある困りごとを切り分け、各コメントに行動データをひも付け、逸話ではなくパターンを評価します。
- 機能投票ボードに振り回されずに運用する方法
公開投票は大規模なフィードバックですが、特有の偏りがあります。ボードを公開する前に投票が何を意味するかを決める方法と、ボードが機能し続けるように結果を伝える方法を扱います。
- セッションリプレイ付きのバグ報告:スクリーンショットを頼むのはもうやめよう
最も緊急性の高いフィードバック。リプレイ、コンソールログ、エラーが添付された状態でバグ報告を受け取り、チケット単位ではなくバグ単位でトリアージする方法です。
フィードバック
このトピックのすべての記事
セッションリプレイ付きのバグ報告:スクリーンショットを頼むのはもうやめよう
すべてのバグ報告を、原因となったリプレイ、コンソールログ、エラーとともに届くようにし、チケット単位ではなくバグ単位で振り分ける方法。
機能投票ボードに振り回されずに運用する方法
公開ロードマップ投票は、声の大きな要望を証拠に変えます。ただし、票が何を意味し何を意味しないかを先に決めた場合に限ります。
SaaS 向けカスタマーフィードバックフォーム:何を尋ね、回答をどう活かすか
SaaSカスタマーフィードバックフォームは、別のスプレッドシートを作成する代わりに、回答をユーザー行動、セッションリプレイ、プロダクト分析に接続するべきです。
フィードバックをロードマップの根拠に変える
ユーザーコメントをセッション、イベント、そして影響を与えるべきプロダクトベットに接続する軽量な方法。
関連