はじめに
Pendoフィードバックを既存のワークフローに実装する最適な方法についてよくお客様から質問があります。
フィードバックを使用するために、現在の設定を大きく変更する必要はほとんどありません。少しの修正で済みます。
ゼロから始める場合は、最初から最後まで読んでいただいた上で、自由に自分のプロセスを計画してください。ここでは、計画時にワークフローの各ステップで考慮すべき点について説明します。
すでにフィードバックを使用しているお客様で、別のワークフローを使用している場合は、最も関連性の高い部分に移動して、この手順に従い現在のプロセスを更新できます。
1．Pendoフィードバックのユーザーとは
フィードバックに関与する人は大きく3つのグループに分類されます。チャンピオン、マネージャー、アナリストのグループです。
フィードバックチャンピオン
フィードバックチャンピオンとは、フィードバックに関するすべてのベストプラクティスに精通している社内の人間です。
組織の誰かがフィードバックの使用について質問がある場合に基本的な問い合わせ先となるとともに、トレーニングセッションも開催します。
最終的には、フィードバックのオーナーになり、成功に向けて責任を負います。
フィードバックマネージャー
フィードバックマネージャーは、お客様の製品に関して深い知識を持ち、お客様対応にも優れています。
新規リクエストを優先順位付けして［フィードバック待ち］に更新すること、そしてロードマップを最新の状態に保つことに責任を持ちます。
フィードバックアナリスト
フィードバックアナリストは、お客様の製品に対して顧客が何を求めているかを分析します。アナリストは製品チームに所属していることが多く、次回のロードマップミーティングの前に、顧客や見込み客が何を求めているのかを知りたいと考えています。あるいは、商談が取れない理由を知りたいセールス部門の責任者や、電話で話す前に顧客の優先順位を知りたいカスタマーサクセスマネージャー（CSM）の場合もあります。
フィードバックアナリストの役割は、収集データをフィードバックのレポート機能を使って分析し、それを今後の製品計画に役立てることです。
2．ワークフローの概要
ワークフローの背景には、ワークフローが既存の仕組みに簡単に統合できるという考えがあります。時間が大してかからない割に、良い成果が得られます。
ワークフローの一部として完了すべきタスクは大きく4つあります。
それらのタスクは次のとおりです。
- トリアージ（優先順位付け）
- 調査
- 分析
- 更新
トリアージ（優先順位付け）
このステップには、受信した新規リクエストの確認も含まれます。幸い、このステップは思っているほど負荷が高い作業ではありません。実際、受信するリクエストの95%は、数秒で一括トリアージができます。
やるべきことは、新規リクエストのステータスを［フィードバック待ち］に変更するだけです。
このステップにより、フィードバックを送信するすべてのユーザーがレスポンスを迅速に受け取れるようになり、フィードバックループをクローズするのに役立ちます。その後は、リクエストに対してユーザーが投票し、優先順位を付け、フィードバックを追加するまで待ちます。そのため、現在の作業に集中でき、個々の顧客が何を求めているのかを気にかける必要がなくなります。
このタスクは、1人以上のフィードバックマネージャーがオーナーになる必要があります。
注：フィードバックアカウントをさらに管理したい場合は、顧客に対して新規リクエストを送信する権限を付与せず、開発予定のプロジェクトに関するフィードバックのみを収集することをお勧めします。これは［設定］ページのオプションです。
調査
おそらく、お客様は将来に向けてすでに多くことを計画しており、製品をどうしたいかについてのアイデアを持っているはずです。
フィードバックは、顧客やチームメンバーの声を既存の計画に反映させるのに役立ちます。
ワークフローのこのタスクでは、フィードバックを使用して、計画した特定プロジェクトの詳細情報やフィードバックを収集します。これにより、すでに取り組んでいる作業を強化できます。
このタスクは、フィードバックマネージャーが実行することが多いですが、最終的には、必要があれば誰でもフィードバックを使用して情報を取得できます。
分析
現在のプロジェクトと今後予定しているプロジェクトを進めていくと、さらに将来の計画を立てる必要が出てきます。
このタスクでは、フィードバックレポート機能を使用して、顧客、見込み客、チームメンバーそれぞれの優先順位を識別して、次に何に取り組むべきかを判断します。
また、ロードマップにギャップがある場合に、取り組むべきクイックウィンを見つけることもできます。
ワークフローのこのタスクでは、通常、フィードバックアナリストがオーナーになりますが、ロードマップのオーナーや製品のオーナーも関与します。
更新
実はこれがフィードバックワークフローの最も重要なタスクです。ユーザーとコミュニケーションを取らないと、ユーザーとの間に距離が生まれ、将来のフィードバックの量と質が低下する可能性があります。
コミュニケーションが足りないと、何を開発するかよりも、何を開発しないのかの方が強く伝わってしまいます。しかし、フィードバックを常に最新の状態にしておくと、顧客やチームメンバーは今後の予定に期待してくれます。
フィードバックマネージャーがワークフローにおけるこのタスクの責任者になります。
3．ワークフローの実装方法
ワークフローの概要と各タスクの責任者について理解できたと思いますので、次はワークフローの実装方法について説明します。
以下の各セクションでは、標準的な推奨事項、お客様向けカスタマイズオプション、および整理に役立つアクション項目について説明します。
プロセスの各ステップの概要はチームのガイドラインドキュメントに記載します。これにより、トレーニング、一般的な質問への回答、新入社員の短期間での育成が可能になります。
トリアージ（優先順位付け）
基本的なトリアージは次のとおりです。
- まず、顧客とのコミュニケーションに使用できるような、［フィードバック待ち］の優れた保存済みレスポンスが必要になります。フィードバックに感謝していることを伝え、期待値を込める必要があります。ロードマップおよび製品フィードバックポリシーのリンクを入れることをお勧めします。
- 1～2週間ごとに、各フィードバックマネージャーは新規リクエストに目を通して、［フィードバック待ち］ステータスに一括更新する必要があります。
- 明らかな重複や誤って送信されたリクエストを見つけた場合は、マージまたは削除する必要がありますが、ほとんどの場合、リクエストを一括更新しても問題はありません。（受信するフィードバックに対してこのアプローチが最適な理由を確認してください。）
- できるだけ早くタグ付けを自動化します。リクエストを手動でタグ付けする必要がある場合は、その理由を明確にします（例：リーダーシップチームが、自動でタグ付けできない特定のタイプのリクエストを除外する必要があるため）。
お客様の会社のワークフローに合わせて推奨事項をカスタマイズする方法：
標準的な推奨事項以外にも、独自のワークフローを完成させるために決めるべきことがいくつかあります。以下に、それらのオプションと、何がお客様にとって役に立つかという観点での推奨事項を示します。
1：トリアージで考えるべきこと
通常は、新規リクエストを［フィードバック待ち］ステータスに一括更新しますが、同じリクエストが重複して送信された場合はどうしますか？開発しないと分かっているリクエストはどうしますか？複数の言語でのリクエストを受信しますか？
フィードバックマネージャーができるだけ効率的に作業できるように、具体的なガイドラインを作成しましょう。
2：オーナーシップの分割方法
アプリ、プロダクトエリア、またはリクエスト担当者で、新規リクエストにオーナーシップを割り当てます。（特定の日や週で責任を割り振っても、効果はありませんでした。）
それぞれのアプリやプロダクトエリアにマネージャーのチームを設定することもできますが、更新作業に最終的な責任を持つ人を1人、必ず設定しましょう。
3：バグが報告されたらどうするか
この場合はリクエストを拒否し、バグレポートとしてサポートに対応を移管した旨の通知を顧客に送信することをお勧めします。その後で、フィードバックからリクエストを削除できます。
頻繁に発生する場合は、そのリクエストをフィードバックに残しておき、他のユーザーが拒否ステータスを参照することで重複リクエストの送信を防ぐという手もあります。ただし、長期的にはトリアージに時間がかかるようになります。
4：開発しないとわかっているリクエストの場合はどうするか
フィードバックで拒否されたリクエストのバックログを作成する価値はあります。そうすれば、将来他の人から同じリクエストが来た時に、十分に検討したレスポンスを返すことができます。トリアージの時間も短縮されます。
5：モデレーションをオンにするか
モデレーションを使うと、リクエストが即時に他の顧客に公開されなくなります。これは［設定］ページで設定できます。
「トリアージ」ステップのアクション項目は次のとおりです。
- ［フィードバック待ち］の優れた保存済みレスポンスを設定する。
- 機能のタグ付けを自動化する。
- チームのガイドラインドキュメントを更新する。
- フィードバックマネージャーのトレーニングを開催する。
調査
調査フェーズを慎重に計画して、お客様とチームの調査が完了するまで開発計画を策定しないようにします。
内部と外部の両方に対応する開発プロジェクトは、開発フェーズに移行する前にフィードバック上に作成するのが理想的です。（下記の「更新」の手順を参照してください。）
開発計画を策定する前に次のステップを実行してください。
まず、プロジェクトに関連するリクエストを検索します。
関連するリクエストがフィードバックに存在する場合は、投票したユーザーに柔軟なメールを送信し、調査中のプロジェクトに基づいて、各ユーザーに最新のユースケースの情報提供を依頼します。
このメールを新しいセグメントの顧客やチームメンバーに送信することもできます。たとえば、企業顧客向けのプロジェクトに取り組んでいる場合は、企業アカウントに送信します。
関連するリクエストがフィードバックに存在しない場合は、そのプロジェクトの新規リクエストを作成し、達成目標を記入します。
ここでも柔軟なメールを使って該当するユーザーにフィードバックを依頼し、ディスカッションを開始します。
以下は、当社が調査している新機能でお客様が何を必要としているかを判断するために送信したメールの例です。
これにより、すでに進めている作業の改善に役立つ有益な情報が得られます。
お客様の会社のワークフローに合わせて推奨事項をカスタマイズする方法：
調査のセクションでは、以下について決める必要があります。
1：調査はどの段階で開始すべきか？
ほとんどのお客様は、［開発中（Building）］に移行するタイミングを調査します。その理由は［計画済み（Planned）］に移行するまでにしばらく時間がかかるためですが、［計画済み（Planned）］を「次の予定に到達」したステータスとして使用している場合は、このタイミングで調査を行いましょう。
「調査」ステップのアクション項目は次のとおりです。
- アカウント、ユーザー、およびチームメンバーに自動タグを付ける。これで、柔軟なメールを最大限に活用できます。
- この調査ステップを開発プロセスに取り入れる。
- チームのガイドラインドキュメントを更新する。
- フィードバックマネージャーまたはこのステップに責任を持つ他のユーザーのトレーニングを開催する。
- 案件が［開発中（Building）］ ステータスに更新された時に、メールまたはSlackで正しいユーザーに通知するようにzapierを設定する。
分析
分析フェーズは、ロードマップに少し余裕がある場合に最適で、次は何を検討すべきかをフィードバックレポートを使って確認できます。
各アナリストは、それぞれの目標に基づいて異なるアプローチを採用します。
製品チームの観点では、お客様の製品戦略を基に、お客様の目標、およびお客様が確認すべきレポートを識別します。
この四半期の目標が、より多くの企業商談を獲得することであれば、価値の高いお客様向けの事前定義レポートを参照し、次に価値の高い見込み客が求めていることを参照します。
一方、カスタマーサクセスマネージャーは、電話する前に、特定のアカウントの優先順位を知りたいだけかもしれません。
チャンピオンは、すべてのアナリストが見たいと思うレポートを逐一識別したり、それをいつ見たいかを識別したりする仕事ではありませんが、自分でデータを取得するために必要な情報を提供することはできます。
フィードバックレポートの詳細についてはこちらの記事をご覧ください。
「分析」ステップのアクション項目は次のとおりです。
- チームのガイドラインドキュメントを更新する。
- フィードバックアナリスト向けのトレーニングを開催する。
更新
大規模な戦略的プロジェクト、クイックウィン、またはその中間であっても、取り組んでいるものはすべて、フィードバックに入力してください。
フィードバックで管理していれば、リクエストのステータスが、進行状況に応じて更新されます。プロジェクトが開発の次の工程に進むたびに、関連するリクエストを必ずフィードバック上で更新してください。
フィードバックを最新の状態に保つための簡単な方法は、フィードバックマネージャーをロードマップ会議に参加させ、その中でステータスを更新させることです。
お客様の会社のワークフローに合わせて推奨事項をカスタマイズする方法：
更新のセクションでは、以下について決定する必要があります。
1：フィードバックマネージャーが製品チームの開発情報を取得する頻度
これは、即時に、継続して行う必要はありません。開発が完了するまで、週1回、月1回、年4回程度で十分です。
ロードマップを決める製品ミーティングに、関係するフィードバックマネージャーを参加させ、すべてが網羅されるように、ロードマップまたは社内（製品チーム）の計画ドキュメントを共有することをお勧めします。
2：更新ステップの責任者は誰か
トリアージのオーナーシップと同様、アプリ、プロダクトエリア、およびリクエスト担当者は、フィードバックマネージャーの中でオーナーシップを割り当てるために最適です。
オプション：既存のワークフローを更新する方法
すでにフィードバックを使用していても、ワークフローを実装していない場合は、さらに簡単です。少しの作業で済みます。
行うべき作業は次のとおりです。
- フィードバックチャンピオン、マネージャー、アナリストを決定します。
- 上記のワークフローを作成し、現在のプロセスに必要な変更を書き留めます。
- フィードバックに［未レビュー］のリクエストが多く残っている場合は、「マネージャーのトレーニング」の一環としてそれらのリクエストをトリアージします。
- チームのガイドラインドキュメントを更新するか、まだ作成していない場合は作成します。
- 関係する従業員のトレーニングを行います。
まとめ
フィードバックを導入するといっても、ゼロから始めたり、まったく新しいプロセスを会社に導入するわけではないことを理解してもらえたと思います。
フィードバックは既存のワークフローに簡単に統合でき、既存の作業を改善および強化することができます。
ただし、以下のように誰が何をするかを決める必要があります。
- フィードバックチャンピオンは、フィードバックの全体的な処理を担当し、フィードバックに関する質問に回答するために必要です。
- フィードバックマネージャーは、新規リクエストを優先順位付けし、フィードバックを最新の状態に保つために必要です。
- 最後に、フィードバックアナリストは、レポートデータを基にインサイトとユーザーの優先順位を明らかにするために必要です。
ワークフローは、次の4つの異なるタスクで構成されています。
- トリアージ：新規リクエストが［フィードバック待ち］に設定されます。
- 調査：より多くのデータを収集して、作業を改善します。
- 分析：レポートを使って、ロードマップで次の作業を計画します。
- 更新：フィードバックが定期的に更新されるようにし、ユーザーと共有します。
このワークフローに従うか、または既存のワークフローに取り込んでください。フィードバックは、きっと最適な製品の開発に役立ちます。