フィードバックとインサイトを製品開発の指針として利用
優先順位付けセッション中に関連するインサイトにアクセスできると、その結果が大きく変わる可能性があります。インサイトがあれば、焦点を絞り、顧客のニーズや要望と結び付いた意思決定を証拠に基づいて行うことができます。
インサイトがなければ、優先順位付けは必然的によくある罠に陥ってしまいます。つまり、直感に基づいて決定を下したり、最も声高に、または説得力をもって話す意見に耳を傾けたり、室内で最上級のリーダーの意見 (HipPO、最も高収入を得ている人の意見とも呼ばれます 🦛) が既定で採用されたりすることになります。
こうした意見はどれも必ずしも悪いわけではありません。データと証拠で裏付ける必要があるだけです。製品チームにとって、その証拠を与えてくれるのがインサイトです。
インサイトとは?
インサイトは形状も形態もさまざまです。どのインサイトも、製品内に存在する機会、課題、改善の余地がある分野を明らかにしてくれます。
サポート チームが特定した、繰り返し発生する問題
営業チームが特定した製品ギャップ
顧客からの提案
さまざまな部署の従業員からの提案
市場調査と業界動向
競合分析とベンチマーク
ブレーンストーミング セッションとアイディエーション ワークショップ
企業の戦略と目標に関する経営陣の意見
これらのインサイトはどれも、独自の長所と短所があります。製品に関する優れた意思決定を行うには、これらすべてをバランスの取れた視点で見る必要があります。
インサイトを利用する理由
関連するインサイトを収集し、それらをアイデアの裏付けに利用することで、提案の信頼性が高まります。リソースの効率的な使用や、最大の効果を得られる分野でのチームの懸命な取り組みを重視していることが分かるからです。
インサイトによって、顧客のニーズと市場の需要を中心に会話を進め、アイデアを製品の成果につなげることができます。これにより、チーム、顧客、経営陣の信頼を得て、優れた製品の構築に必要な自主性を主張することができます。
優先順位付けに関する議論が大声や説得力のある声によって脱線してしまった場合は、必ずインサイトに従って軌道に戻します。
営業チームからのフィードバックに頼り過ぎると、既存の顧客にとって重要な摩擦点を見逃す可能性があります。同様に、経営陣からのフィードバックに依存し過ぎると、現在の製品エクスペリエンスの向上ではなく、新規顧客を獲得するための新しい戦略的な賭けに集中してしまう可能性があります。どちらも既存顧客の解約につながる可能性があります。
Jira Product Discovery のインサイト
Jira Product Discovery では、インサイトはすべてのアイデアに欠かせない要素です。Jira Product Discovery の Chrome 拡張機能、Slack または Teams アプリ、パートナーが構築したいずれかの統合を使用して、関連するインサイトをアイデアに追加することを習慣付けましょう。
Jira Product Discovery を、サポート、セールス、調査、フィードバック管理のソリューションと併用します。Jira Product Discovery の目的は、なぜそのアイデアが重要なのか、どのように優先順位を付ける必要があるか、そのアイデアによって何が引き起こされるかについて説明する、関連フィードバックやインサイトをアイデアに追加できるようにすることです。
これにより、優先順位付けの話し合いを始めたときに、インサイトをすぐに利用できます。
インサイトを集めるためのチャンネルをセットアップ
意思決定の指針となる十分なインサイトがなくても、インサイトを集め始めるのに遅すぎるということはありません。このデータを収集するための進行中のプロセスがある場合は、それを改良してあらゆる製品決定の裏付けに必要なインサイトにすることができます。
この章では、顧客や顧客対応チームとの直接的なコミュニケーション チャンネルをセットアップして、独自の調査中に見つけたデータの取得を開始する方法について説明します。
インサイトを収集するために複数のチャンネルをセットアップすることをお勧めします。
こうしたチャンネルを通じて受け取ったデータやフィードバックをすべてインサイトに変換するようなことはしないでください。プロジェクトが乱雑で騒々しいものになってしまいます。代わりに、製品バックログに追加する前に、学んだことをインサイトへと改良するためのスペースとして上記チャンネルを使用します。
Jira Product Discovery チームによるインサイトの収集方法
Jira Product Discovery を構築するプロセス全体は、インサイトの収集を指針として形成されました。このセクションの残りの部分では、Jira Product Discovery チームがどのようにフィードバック チャンネルをセットアップし、それを製品開発に役立てたかについて具体的に説明します。
Jira Product Discovery チームでは、以下のチャンネルからインサイトを取得します。
アプリ内のフィードバック コレクター (Jira Service Management を使用)
Slack 内にある、顧客対応チームのための社内フィードバック チャンネル
Dovetail にある、ユーザー インタビューのリポジトリ
アトラシアンのコミュニティ内にあるコミュニティ グループ
Pendo を使用した製品分析
Pendo を使用したアプリ内調査
Confluence 内のアトラシアンのナレッジ リポジトリ
インバウンド フィードバックからのインサイトの収集
インバウンド フィードバック (製品を積極的に使用しているユーザーの懸念事項、コメント、質問) は、最も重要なインサイト ソースの 1 つです。
Jira Product Discovery には、このようなインバウンド フィードバックを収集して管理するための専用チャンネルが複数あります。このことにはいくつかの利点があります。
アプリに埋め込まれたポータルやフィードバック収集ウィジェットなど、フィードバックを共有するための専用チャンネルをユーザーに提供できます。
フィードバックを処理するための専用の領域が提供されます。これによって製品バックログが区別してまとめられるため、製品バックログに何を含め、新しいアイデアやインサイトを既存のアイデアにどのような形で追加するかを製品チームが判断できます。
フィードバックについて報告者と会話する、次のステップへの期待を設定する、報告者とやり取りするといったことが可能になるので、さらに詳しい情報が必要な場合や、Zoom チャットを提案したい場合に便利です。
ユーザーからのフィードバックから生まれた機能をリリースするとき、フィードバックした人物に通知して、フィードバック ループをクローズできます。
Jira Service Management でフィードバックを収集する
Jira Product Discovery チームでは、Jira Service Management を使って、カスタマーとエンドユーザーが構造化されていないフィードバックを直接共有できるようにしています。
ユーザーは Jira Service Management の組み込みウィジェットを使用して、Jira Product Discovery からフィードバックを直接送信します。
このフィードバックは Jira Service Management キューに入ります。チームの PM は週に数回これを確認します。
コメントを使用してユーザーと直接フィードバックについて話し合った後、Jira Product Discovery Chrome 拡張機能を使って関連するアイデアへのインサイトとして追加します。
Jira Product Discovery チームはこれらの追加を毎週確認し、ユーザーからのフィードバックから生まれた新しいアイデアやインサイトについて話し合います。
リソース セクションに、Jira Service Management キューを設定してカスタマーや社内チームからのフィードバックを受け取れるようにする方法のデモがあります。
専用の Slack チャンネルでフィードバックを収集する
社内の関係者が質問したり提案したりできる専用チャンネルを Slack と Teams に作成しました。私たちはこれらの内容を確認した後、Jira Slack アプリを使ってアイデアをインサイトとして追加します。
これにより、チームが多数のチャンネルから過度に多数のダイレクト メッセージ、質問、リクエストを受け取ることで見逃しが発生しやすくなることを防ぎ、整理しやすくします。
関係者がここで質問することに慣れ、メッセージを直接送るのをやめるまでにはしばらく時間がかかりましたが、プロセスが確立されると、非常に効率的になりました。
フィードバック専用のチャンネルは 3 つあります。
Jira Product Discovery の社内ユーザー用の #help-jpd-dogfooders
営業チームとサポートチームがカスタマーや見込み顧客との話し合いに関する支援が必要な場合に使用する #help-jpd-sales と #help-jpd-support
リソース セクションに、製品フィードバック専用の Slack または Teams チャンネルを設定して社内チームからのフィードバックを受け取れるようにする方法のデモがあります。
専用の Jira Product Discovery プロジェクトでフィードバックを収集する
Jira Product Discovery チームはこの方法を使用していませんが、多くのカスタマーはフィードバックを収集するために専用の Jira Product Discovery プロジェクトを設定しています。
これは製品やデリバリーのバックログとは別の専用スペースとなり、ここではコントリビューターが独自のアイデアを作成したり、他のアイデアにコメントやインサイトを追加したり、相互の貢献に投票したりできます。
これは非常に効果的です。ただし、専用プロジェクトが適切に運用されるようにすることが条件です。そうしないと、すぐに、重複や冗長性のある大小のタスクがただ延々と並ぶ状況になります。
それでも、慎重に設定すれば、関係者の数が限られ、アイデアの数が管理可能な場合は、かなり良好に機能します。
Jira Product Discovery でフィードバック収集プロジェクトを設定する方法:
アイデア収集フォーム用の独自のテンプレートを作成します。使用するビューに特定のフィールドを追加して、要求する情報を定義します。
アイデアを提供できる人物を選び、プロジェクトのコントリビューターとして追加します。
ビューを作成して、コントリビューターが投票、コメント、インサイトの追加などの設定された方法で入力を提供できるようにします。
ユーザー調査によるインサイトの収集
インバウンドのフィードバックにより、一般的にどの領域に製品を改善する余地があるかがよく見えるようになります。しかし、それだけでは製品に関する意思決定の指針にはなりません。特に、文脈が欠けています。
ユーザーからの 1 つのフィードバックや機能リクエストから全体像を把握することは困難です。
ユーザーが直面している根本的な問題
この問題がユーザーのワークフローにとってどの程度重要か
製品の他の部分にどのような影響があるか
別の解決策で問題を解決できるかどうか
こうしたことなどについて、ユーザーと定期的に会話することは何よりも有益です。
調査に適したユーザーを集めにくいことがあります。しかし、インバウンドのフィードバックやアンケートのソリューションがあれば、それをチャンネルとして使用して、生産的な調査対象になりそうなユーザーを特定して連絡し、チャットすることもできます。
Dovetail によるユーザー調査
Jira Product Discovery チームは皆リモートで、グローバルな顧客基盤を持っているため、主に Zoom ミーティングを利用しています。カスタマーが私たちのチャンネル (アプリ内フィードバック ウィジェットまたはコミュニティ グループ) のいずれかに興味深いフィードバックを入力したら、Calendly のリンクでカスタマーに連絡し、時間を取り決めて招待します。
インタビュー対象者の許可を得て、これらのミーティングを記録し、Dovetail にアップロードします。そこで会話の重要な部分にタグ付けして、関連するアイデアへのインサイトとして追加できます。
以前に、今日の Jira Product Discovery が形作られるのを助けてくれた Lighthouse ユーザーをそのように発見しました。
しかも、カスタマーが困りごとについて語る 3 分間の動画は、テキストベースのドキュメントよりも、チームや関係者とのコミュニケーションの手段としてより影響力があることもわかりました。
調査レポートによるユーザー調査
トピックによっては、より詳細なユーザー調査を利用するほうが適している場合があります。アトラシアンには調査とインサイトのチームがあり、特定のトピックを深く掘り下げ、厳密な調査手法を使ってそれらをインサイトへと抽出しています。
たとえば、最近では、ある調査担当者が Jira Product Discovery 評価者にとっての問題点を理解するのを手伝ってくれました。このレポートからのインサイトに Jira Product Discovery のアイデアとしてタグ付けし、その結果を使用して、評価者がアプリ内でどのように参加するかを再考しています。
アンケートによるインサイトの収集
アンケートは製品チームが次のことを行うために最適なツールです。
質問してユーザーのフィードバックを集める
仮説をテストして検証する
意見ではなくインサイトに基づいて社内の議論を解決する
カスタマーは、フィードバックのアンケートを書くときのほうが、自分で簡単なインバウンドフィードバックを送る場合よりも多くの時間を割き、よく考える傾向があるようです。
Pendo を使ったユーザー アンケート
Jira Product Discovery チームでは、Pendo を使って、セグメンテーションと製品利用状況データに基づく、特定のユーザー コホートを対象としたアンケートを作成しています。
毎月の CSAT アンケートのような定期的な調査だけでなく、特定の質問に答える 1 回限りのアンケートも行っています。通常、これらの質問は、間違うと製品に広範囲にわたる影響を与える可能性があり、明確でタイムリーなデータが必要になる場合に行います。
アンケートから得られた知見は Confluence のページにまとめ、関連するアイデアへのインサイトとして追加します。
インサイトを収集するためのコミュニティ グループの構築
コミュニティ グループは、ユーザーを集めてフィードバックを得る方法として非常に有効です。これらのグループに対して、製品に関する質問への回答を求めたり、新機能のアーリー アダプターを募集したり、発表したり、ベストプ ラクティスを共有したりできます。
アトラシアンのコミュニティ グループ
Jira Product Discovery の開始以来、ユーザーとの直接的な交流はアトラシアン コミュニティのサブグループである Jira Product Discovery グループで行ってきました。時間の経過に伴い、パワー ユーザーが他のユーザーをサポートし始め、製品についてのナレッジを共有するようになりました。私たちはこれらの会話から多くのことを学びました。
このアプローチは仮定の検証に役立ち、方針の変更につながったことが何度もあります。
たとえば、Jira Product Discovery の価格を最初に発表したとき、驚くべき反響がありました。一部の企業は私たちが想定していなかった方法でコントリビューターを利用していたため、その価格設定では彼らのニーズに手が届かなかったことでしょう。
私たちはすぐに方向転換し、これらのユースケースをサポートするために無料の機能をコントリビューターの役割に追加しました。当社の製品バックログには、コミュニティ グループのディスカッションから得られたこのようなインサイトがたくさんあります。
製品分析からのインサイトの収集
最後に、インサイトを評価し、それに基づいて行動する方法を決定する際には、質的なユーザー フィードバックだけでなく、量的データも考慮することが重要です。
製品分析では、次の 2 つのレベルでインサイトを得ることができます。
解約率や顧客 LTV などの成長指標
たとえば、評価者がアクティブ ユーザーへの転換に失敗し、最初のセッションの後に離脱したことに気付いた場合は、新機能の実装をやめて、オンボーディング フローを見直してみる必要があるでしょう。
機能の使用状況とユーザー行動データ
たとえば、ある機能について否定的なフィードバックが多く、データからその機能があまり使われていないことが明らかになった場合は、その機能を維持する価値があるのか、廃止すべきなのかを話し合う良い機会となります。
製品分析ツールを使用したインサイトの収集
もちろん、使用される製品分析ツールは会社によって異なります。Jira Product Discovery チームでは、この目的で Amplitude と Pendo の両方を使用しています。特に、使用率、機能の人気、ユーザーが当社のオンボーディング フローをどのように利用しているかを追跡するために使用しています。繰り返しになりますが、当社では製品バックログのアイデアに重要なインサイトを追加しています。
インサイトについての話し合いを習慣化
製品チームは毎日意思決定をしています。顧客データに基づいてこれらの意思決定をできるだけ多く行うには、継続的にインサイトを活用する必要があります。
どのフィードバックやリサーチ チャネルを使用するにせよ、それらがうまく機能するためには、チームはインサイトの収集とそれに基づく行動を継続的に行う必要があります。チームが顧客からのフィードバックに月に 1 回しか対応しない場合、タイムリーな顧客からの意見なしで 1 か月分の意思決定を下すことになります。
Teresa Torres 氏が『Continuous Discovery Habits』の中で述べているように、製品の意思決定にインサイトを使用することには多くのメリットがあります。
共通認識の強化
チーム メンバーは、自分たちの取り組みの理由を理解し、ユーザーが気にかけていることについて共通認識を持てるようになります。
エビデンスに基づく優先順位付け
チームは、時間をかけて収集したインサイトに基づいて優先順位を付けることができます。また、どこに投資するかを客観的に決定できるようになります。
ロードマッピングがより簡単に
投資分野を簡単に明確化できるようになり、時間をかけて収集されたインサイトによって潜在的な投資分野に集中できるようになります。また、適切なリソース配分がわかり、情報に基づいた方法でトレードオフができます。
関係者の関与が向上
顧客のニーズと優先事項について明確な説明が可能となります。チームは簡単にこの説明を関係者に伝え、顧客の懸念とその影響について会話を再構成することができます。
Jira Product Discovery におけるインサイトについての議論
Jira Product Discovery チームでは、継続的な発見を習慣にするために次の 2 つの手法を取り入れています。
毎週の「フィードバック ローテーション」の割り当て:
毎週、製品チームの 1 人が「フィードバック ローテーション」に割り当てられます。その人は私たちのチャンネルを見て、フィードバックに答え、アイデアに関連するインサイトを追加します。これは通常、約半日分の作業で、それを 1 週間にわたって行います。
毎週の「データ バス」ミーティング:
このチームミーティングでは、その週のフィードバックを検討して、学んだことや得られた成果について話し合います。ミーティングの終わりに、「フィードバック ローテーション」の割り当てを次のプロダクト マネージャーに正式に引き継ぎます。
私たちはこの作業を継続的に行ってきたため、最新の状況を十分に踏まえたうえで、優先順位付けのすべての議論に対応することができています。
ライトハウス ユーザー
多くの顧客からフィードバックを受け取った場合、誰に耳を傾けるべきでしょうか?
アトラシアンには、30 万人以上の顧客がいます。Jira Product Discovery チームだけでも、毎週、製品に関する多数のフィードバックを受け取ります。すべてのフィードバックを直接処理することや、ましてやそれらに対応することなど不可能です。
ユーザーからのフィードバックは、製品の使用時に人々が直面する問題の種類と、どの問題がより蔓延しているかを把握するのに役立ちます。このフィードバックは製品のアイデアに影響を与えますが、そのフィードバックのみに基づいてソリューションを設計することはありません。
代わりに、ソリューションを開発、反復、出荷する際には、通常、小規模な専任のユーザー グループと協力します。私たちは、非常に詳細で的を絞ったフィードバックに耳を傾けながら、彼らとともに、彼らのために製品エクスペリエンスを構築します。
これらのテスト グループは「ライトハウス ユーザー」と呼ばれます。私たちの経験では、10 人のライトハウス ユーザーがいれば十分です。
なぜライトハウス ユーザーと協力するのか?
私たちの経験では、一度に何千人ものユーザーを満足させようと努力するよりも、ライトハウス ユーザーと協力する方が効果的です。
少人数での話し合いに基づいて意思決定できるため、迅速に行動できます。決定を下すために 1000 人のユーザーにアンケートを行う必要はありません。ライトハウス ユーザーにいち早くプロトタイプへのアクセスを提供することで、製品エクスペリエンスを早期にテストできます。これらのユーザーは予想される事態、すなわち、カバーされていないバグや特殊なケースが存在する可能性について知っています。
私たちはこれらのユーザーと信頼関係を築き、彼らの問題や動機を理解しているため、状況に応じた豊富なインサイトが得られます。多くの場合、多くの人と 1 回の会話をするよりも、よく知っているユーザーと複数の会話をする方が影響力が大きくなります。
チーム全体の緊急性が高まります。なぜなら、チームはライトハウス ユーザーを人間として認識し、サポートしたいと考えるからです。ライトハウス ユーザーをチーム全体に紹介すると、チームの切迫感と当事者意識が高まります。関心のある 1 人の問題を解決することは、調査レポートよりもはるかにモチベーションを高めます。
ライトハウス ユーザーの選び方
このような方法を採用すると決めた場合、誰がライトハウス ユーザーとして適しているのかを明確にする必要があります。選択を誤ると、間違った人々向けに間違った製品を構築することになる可能性があります。
Jira Product Discovery では、時間の経過とともに、ライトハウス ユーザーには次の属性があることがわかりました。
✅ 非常に明確なコミュニケーター
✅ ターゲットとする顧客セグメントに属している (たとえそれが何であるか私たちが繰り返し検討している場合でも)
✅ 解決しようとしている問題や課題の影響を強く受けている
✅ 問題点を解決する新しい方法を模索しているが、これまでのところ成功していない
✅ 競合アプリを使用していないので、機能の複製について議論の中心にならない
✅ 特定の機能を探しているのではなく、新しいさまざまな働き方に対してオープンである
✅ 初期段階の製品や機能を使用し、フィードバックを共有し、解決策について話し合うことを好む
ライトハウス ユーザーとの協力
私たちはライトハウス ユーザーとのコラボレーションに全力を注いでいます。基本的に、このユーザーはソリューションの共同作成者として扱われます。
フィードバックや質問を共有できる専用の Slack チャンネルをセットアップします
毎月会って、製品や製品管理、経験について話し合います
初期のデザインをライトハウス ユーザーと共有し、フィードバックを得ます
ライトハウス ユーザーに製品、エクスペリエンス、機能へのアーリー アクセスを提供します
自分ならソリューションをどのように設計するかを尋ねます
ライトハウス ユーザーについて詳しくは、アトラシアン コミュニティのこちらの投稿シリーズを参照してください。
次のステップ
すべての意思決定をインサイトに基づいて行うことで、製品チームは、ユーザーの問題を解決し、ユーザーの生活を楽にするという最終目標に集中して作業を続けることができます。
このハンドブックの最後の 2 つのセクションでは、製品バックログを次の目的で使用する方法について詳しく説明します。
Jira Product Discovery やその他の製品を使用して、Jira Product Discovery チームでこれを行う方法の例を示します。