フィードバックとインサイトを製品開発の指針として利用

インサイトを利用する理由

関連するインサイトを収集し、それらをアイデアの裏付けに利用することで、提案の信頼性が高まります。リソースの効率的な使用や、最大の効果を得られる分野でのチームの懸命な取り組みを重視していることが分かるからです。

インサイトによって、顧客のニーズと市場の需要を中心に会話を進め、アイデアを製品の成果につなげることができます。これにより、チーム、顧客、経営陣の信頼を得て、優れた製品の構築に必要な自主性を主張することができます。

優先順位付けに関する議論が大声や説得力のある声によって脱線してしまった場合は、必ずインサイトに従って軌道に戻します。

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 チームがどのようにフィードバック チャンネルをセットアップし、それを製品開発に役立てたかについて具体的に説明します。

インバウンド フィードバックからのインサイトの収集

インバウンド フィードバック (製品を積極的に使用しているユーザーの懸念事項、コメント、質問) は、最も重要なインサイト ソースの 1 つです。

Jira Service Management でフィードバックを収集する

Jira Product Discovery チームでは、Jira Service Management を使って、カスタマーとエンドユーザーが構造化されていないフィードバックを直接共有できるようにしています。

専用の Slack チャンネルでフィードバックを収集する

社内の関係者が質問したり提案したりできる専用チャンネルを Slack と Teams に作成しました。私たちはこれらの内容を確認した後、Jira Slack アプリを使ってアイデアをインサイトとして追加します。

専用の Jira Product Discovery プロジェクトでフィードバックを収集する

Jira Product Discovery チームはこの方法を使用していませんが、多くのカスタマーはフィードバックを収集するために専用の Jira Product Discovery プロジェクトを設定しています。

これは製品やデリバリーのバックログとは別の専用スペースとなり、ここではコントリビューターが独自のアイデアを作成したり、他のアイデアにコメントやインサイトを追加したり、相互の貢献に投票したりできます。

これは非常に効果的です。ただし、専用プロジェクトが適切に運用されるようにすることが条件です。そうしないと、すぐに、重複や冗長性のある大小のタスクがただ延々と並ぶ状況になります。

それでも、慎重に設定すれば、関係者の数が限られ、アイデアの数が管理可能な場合は、かなり良好に機能します。

ユーザー調査によるインサイトの収集

インバウンドのフィードバックにより、一般的にどの領域に製品を改善する余地があるかがよく見えるようになります。しかし、それだけでは製品に関する意思決定の指針にはなりません。特に、文脈が欠けています。

ユーザーからの 1 つのフィードバックや機能リクエストから全体像を把握することは困難です。

• ユーザーが直面している根本的な問題
• この問題がユーザーのワークフローにとってどの程度重要か
• 製品の他の部分にどのような影響があるか
• 別の解決策で問題を解決できるかどうか

こうしたことなどについて、ユーザーと定期的に会話することは何よりも有益です。

調査に適したユーザーを集めにくいことがあります。しかし、インバウンドのフィードバックやアンケートのソリューションがあれば、それをチャンネルとして使用して、生産的な調査対象になりそうなユーザーを特定して連絡し、チャットすることもできます。

Dovetail によるユーザー調査

Jira Product Discovery チームは皆リモートで、グローバルな顧客基盤を持っているため、主に Zoom ミーティングを利用しています。カスタマーが私たちのチャンネル (アプリ内フィードバック ウィジェットまたはコミュニティ グループ) のいずれかに興味深いフィードバックを入力したら、Calendly のリンクでカスタマーに連絡し、時間を取り決めて招待します。

インタビュー対象者の許可を得て、これらのミーティングを記録し、Dovetail にアップロードします。そこで会話の重要な部分にタグ付けして、関連するアイデアへのインサイトとして追加できます。

以前に、今日の Jira Product Discovery が形作られるのを助けてくれた Lighthouse ユーザーをそのように発見しました。

調査レポートによるユーザー調査

トピックによっては、より詳細なユーザー調査を利用するほうが適している場合があります。アトラシアンには調査とインサイトのチームがあり、特定のトピックを深く掘り下げ、厳密な調査手法を使ってそれらをインサイトへと抽出しています。

たとえば、最近では、ある調査担当者が Jira Product Discovery 評価者にとっての問題点を理解するのを手伝ってくれました。このレポートからのインサイトに Jira Product Discovery のアイデアとしてタグ付けし、その結果を使用して、評価者がアプリ内でどのように参加するかを再考しています。

Pendo を使ったユーザー アンケート

Jira Product Discovery チームでは、Pendo を使って、セグメンテーションと製品利用状況データに基づく、特定のユーザー コホートを対象としたアンケートを作成しています。

毎月の CSAT アンケートのような定期的な調査だけでなく、特定の質問に答える 1 回限りのアンケートも行っています。通常、これらの質問は、間違うと製品に広範囲にわたる影響を与える可能性があり、明確でタイムリーなデータが必要になる場合に行います。

アンケートから得られた知見は Confluence のページにまとめ、関連するアイデアへのインサイトとして追加します。

インサイトを収集するためのコミュニティ グループの構築

コミュニティ グループは、ユーザーを集めてフィードバックを得る方法として非常に有効です。これらのグループに対して、製品に関する質問への回答を求めたり、新機能のアーリー アダプターを募集したり、発表したり、ベストプ ラクティスを共有したりできます。

アトラシアンのコミュニティ グループ

Jira Product Discovery の開始以来、ユーザーとの直接的な交流はアトラシアン コミュニティのサブグループである Jira Product Discovery グループで行ってきました。時間の経過に伴い、パワー ユーザーが他のユーザーをサポートし始め、製品についてのナレッジを共有するようになりました。私たちはこれらの会話から多くのことを学びました。

製品分析からのインサイトの収集

最後に、インサイトを評価し、それに基づいて行動する方法を決定する際には、質的なユーザー フィードバックだけでなく、量的データも考慮することが重要です。

製品分析では、次の 2 つのレベルでインサイトを得ることができます。

1. 解約率や顧客LTVなどの成長指標
   
   たとえば、評価者がアクティブ ユーザーへの転換に失敗し、最初のセッションの後に離脱したことに気付いた場合は、新機能の実装をやめて、オンボーディング フローを見直してみる必要があるでしょう。
2. 機能の使用状況とユーザー行動データ
   
   たとえば、ある機能について否定的なフィードバックが多く、データからその機能があまり使われていないことが明らかになった場合は、その機能を維持する価値があるのか、廃止すべきなのかを話し合う良い機会となります。

製品分析ツールを使用したインサイトの収集

もちろん、使用される製品分析ツールは会社によって異なります。Jira Product Discovery チームでは、この目的で Amplitude と Pendo の両方を使用しています。特に、使用率、機能の人気、ユーザーが当社のオンボーディング フローをどのように利用しているかを追跡するために使用しています。繰り返しになりますが、当社では製品バックログのアイデアに重要なインサイトを追加しています。

インサイトについての話し合いを習慣化

製品チームは毎日意思決定をしています。顧客データに基づいてこれらの意思決定をできるだけ多く行うには、継続的にインサイトを活用する必要があります。

どのフィードバックやリサーチ チャネルを使用するにせよ、それらがうまく機能するためには、チームはインサイトの収集とそれに基づく行動を継続的に行う必要があります。チームが顧客からのフィードバックに月に 1 回しか対応しない場合、タイムリーな顧客からの意見なしで 1 か月分の意思決定を下すことになります。

Teresa Torres 氏が『Continuous Discovery Habits』の中で述べているように、製品の意思決定にインサイトを使用することには多くのメリットがあります。

1. 共通認識の強化
   
   チーム メンバーは、自分たちの取り組みの理由を理解し、ユーザーが気にかけていることについて共通認識を持てるようになります。
2. エビデンスに基づく優先順位付け
   
   チームは、時間をかけて収集したインサイトに基づいて優先順位を付けることができます。また、どこに投資するかを客観的に決定できるようになります。
3. ロードマッピングがより簡単に
   
   投資分野を簡単に明確化できるようになり、時間をかけて収集されたインサイトによって潜在的な投資分野に集中できるようになります。また、適切なリソース配分がわかり、情報に基づいた方法でトレードオフができます。
4. 関係者の関与が向上
   
   顧客のニーズと優先事項について明確な説明が可能となります。チームは簡単にこの説明を関係者に伝え、顧客の懸念とその影響について会話を再構成することができます。

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 チームでこれを行う方法の例を示します。