発案からデリバリーまで、アイデアで製品の成果を実現
Jira Product Discovery の製品バックログで扱う主なオブジェクトは「アイデア」です。継続的な検証と学習のプロセスをサポートするために、私たちはアイデアを存続期間が長いオブジェクトとして使用します。アイデアは開発が始まるとバックログに残りますが、必要な効果が得られるまで、ディスカバリーとデリバリーの繰り返しを通して存続します。
成功している製品チームは実験的な考え方を採用しており、コンテキスト、ユーザーからのフィードバック、仕様、デザインを追加することで、時間をかけてアイデアを繰り返します。アイデアのライフサイクルの各段階で、何がうまくいったか、何がうまくいかなかったかを評価し、重要な質問に答え、前提条件を検証して、投資と、得られたフィードバックや検証が釣り合っていることを確認します。
大小さまざまのアイデア
Jira Product Discovery で使用するオブジェクトの名前は「アイデア」ですが、製品のアイデア、機会、問題、解決策などを表すことができます。製品バックログは、さまざまな形や詳細レベルのアイデアを格納するよう設計できます。
これらのカテゴリを定義し、プロセスに参加する全員がそれに同意することが重要です。これにより、分類して比較するフレームワークがないままに製品バックログに超大型から超小型までさまざまな項目が混在する状況を回避できます。
Boulder (大岩)、Rock (岩)、Pebble (小石): アイデアを分類する 1 つの方法
Jira Product Discovery チームでは、アイデアを boulder、rock、pebble の 3 つのレベルに分類しています。
Boulder: 大きな見返りが得られる可能性があるが、不確実性も高い大規模な投資
例: 大胆な新しい賭け、新しい製品の柱、大規模なエンジニアリング プロジェクト
Rock: リスクの少ない中規模の投資
例: 新機能、新しいオンボーディング実験、フィードバックに基づく再設計
Pebble: 小規模で、通常は簡単な投資
例: UX の小規模な改善、「軽微な問題」の修正
チームでは、これらのアイデアのカテゴリごとに異なるビューを使用して議論しています。
アイデアの属性
Jira Product Discovery では、それぞれのアイデアは、1 行の要約、詳細な説明、顧客のフィードバックなどのインサイト、アイデアのデリバリーのための Jira チケットへのリンクで完成します。
有用性と実用性をできる限り高めるために、製品バックログのアイデアのそれぞれに次の属性を含めるようにします。
要素 | これは何か? |
|---|---|
要約 | アイデアの 1 行での説明。 |
説明 | 機会、問題、ソリューションについてのより詳細な説明。 |
フィールド | アイデアのさまざまな側面: アイデアがどの目的に貢献するか、そのステージ、製品のどの部分に関与するか、優先順位付けに役立つ情報 (影響や労力など)、仕様やデザインへのリンクなど。 |
インサイト | あらゆるチャンネルから得られたインサイト: ユーザー フィードバックから得た重要なナレッジ、顧客との会話や調査レポートの抜粋、そのアイデアが重要である理由を明確に示す製品分析など。 |
デリバリー | デリバリー作業で製品のアイデアを実際にリリースするための Jira のデリバリー チケット (エピックまたはイニシアチブ) へのリンク。 |
すべてのアイデアについて、この情報をすべて収集するには時間がかかることがあります。当初、アイデアは、顧客との会話で収集したインサイトなど、1 行の要約としてバックログに入るかもしれません。時間の経過に伴い、ユーザー インタビュー、営業やサポートからのフィードバック、または会社の戦略の変化に基づいて、それに関するより多くのインサイトが集まります。
アイデアを記述する方法は 2 通りあります。Jira Product Discovery で直接記述する方法と、Confluence をチームの Jira Product Discovery プロジェクトにリンクする方法です。
Jira Product Discovery で、アイデアの説明フィールドに要約または定義を書き込みます。提供されているテンプレートの 1 つを使用するか、独自のテンプレートを作成して、アイデアに関連する問題、ソリューション、仮説などを記述するための一貫した書式を用意します。
チームで Confluence も使用している場合は、アイデアの説明で、またはカスタムのハイパーリンク フィールドを使って、アイデアを Confluence ページにリンクできます。このアプローチの利点は、インライン コメントなど、Confluence のコラボレーション機能をすべて活用できることです。
説明の内容自体は、アイデアの種類とステージによって異なるものになります。
アイデアのライフサイクル
アイデアが時間とともにどのように進化するかは、アイデアの内容と同じくらい重要です。このため、それぞれのアイデアがライフサイクルでどのようなステージを経て移動するかを明確に定義することが重要になります。アイデアのライフサイクルの各ステージを共通の語彙で表すことにより、チーム内、そして関係者との会話がより生産的なものになります。
アトラシアンでは、Wonder (構想)、Explore (探索)、Make (開発)、Impact (影響) の 4 つのステージを使っています。アトラシアンではこれらの各ステージの意味を誰もが知っています。各ステージで、チームがどのようなタイプの作業に取り組み、どのような質問をすべきで、どのような支援が必要かがわかっています。この一貫性は、チーム内や他のチーム、経営上層部との話し合いにも当てはまります。
Jira Product Discovery を構築するとき、私たちのチームはこのアプローチを使ってアイデアを開発、検証、提供しました。ライフサイクルの各ステージで、私たちのチームがどのようにそれを実践したかを説明します。
Wonder、Explore、Make、Impact
すべてのアイデアはパーキングロットを経てこのライフサイクルに移ります。このステージでは、それは通常、そのアイデアの作成につながったインサイトを含む、単なる 1 行の要約です。これらのインサイトは、ワークショップや調査レポート、顧客との話し合いから得られたものもあれば、営業担当者やサポート担当者が共有したものもあります。
アイデアに関する活発な作業が始まると、次の 4 つのステージに進みます。
Wonder: そのアイデアで対処できる問題や機会、誰が影響を受けるか、その重要性について話し合います。
Explore: 顧客のフィードバックによる裏付けが得られるまで、考えられるソリューションを模索します。
Make: 十分な数の顧客のニーズを満たすまで、ソリューションの構築を繰り返します。
Impact: ソリューションをローンチして結果を測定し、求める結果が得られるまで改善を続けます。
これはウォーターフォール モデルではないため、これらのステージは必ずしも直線的ではありません。たとえば、Explore のアイデアが Wonder に戻ることは非常によくあります。ソリューションをテストすることで問題についてより深く理解できるためです。また、数回試しても適切なソリューションが見つからないアイデアは放棄することも想定されます。
次のセクションでは、Jira Product Discovery を構築する中でチームがどのような経過で進んだかを例に、各ステージについて説明します。
プロセスにご興味がある場合は、こちらの講演で詳細をご覧になれます。
Wonder
Wonder ステージでは問題や機会を検証します。
このステージでは、通常、顧客との定性的なインタビューを利用します。この調査から、チームは、顧客とビジネスにとっての価値の観点からどのようなメリットと成果をアイデアがもたらすかを把握できます。また、成果を測定する方法についての仮説を立てます。
このステージでのアイデアの検討には、Jira Product Discovery の「Problem definition (問題定義)」テンプレートを使用するか、独自のテンプレートを作成します。
Wonder、Explore、Make、Impact の各ステージで、調査や顧客との会話から得たナレッジをアイデアのインサイト セクションに取り込みます。
Wonder の実践
Jira Product Discovery を構築したときの Wonder ステージの様子を紹介します。この製品の当初のアイデアは次のことから生まれました。
Jira をソフトウェア デリバリーに使用しているプロダクトマネージャーへのインタビュー
アトラシアン自体の調査とインサイトのチームや、Gartner、Forrester などのアナリスト企業の調査の分析
Marty Cagan のブログや Teresa Torres の書籍などの、製品開発のベストプラクティスの例。
これらのインサイトを集めることで、次のことを確信しました。
PM は、効果的な優先順位付けから、ロードマップを全員に納得させることまで、多くのことに苦労しています。
PM は Jira でこれらの問題点を解決しようと考えましたが、Jira はその目的のために設計されていないため、成果は限定的でした。
PM は、発見優先の考え方で成果を出せるはずのところ、出荷機能などのアウトプットに集中して、デリバリーに行き詰まっていました。
テクノロジー企業以外でも製品管理が重要な機能になりつつあります。そのため、ソリューションに対する強い需要がある大きなチャンスがあると確信しました。
私たちは特に、需要に関する仮説の検証に重点を置きました。これが最もリスクの高い仮定だったからです。間違っていれば、製品を作っても買うのは数社ということになります。
そこで、コードを 1 行も書かないうちに、製品を宣伝するウェブ ページを作成しました。
その結果、2 週間で 3,000 人が順番待ちリストに加わり、仮説が裏付けられました。
探索
Explore ステージでは、Wonder で特定された問題や機会に対するソリューションのコンセプトを練り、テストして検証します。
多くの製品アイデアが失敗することはわかっています。これはプロセスの一部にすぎません。これらのあまり有望ではないアイデアをより早く見つけ、良いアイデアに道を譲るために、Marty Cagan は、プロダクト マネージャーが 4 つの主要なリスクに対処することを提案しています。特定した問題や機会に対する可能なソリューションを評価するときに、これらを使います。
このソリューションは顧客にとって価値がありますか。価値がない (すでに優れた代替手段にアクセスできているなど) 場合、ソリューションを構築しても使われないリスクがあります。
ソリューションは使いやすく、直感的か? ユーザーがソリューションから価値を得るためには、簡単にアクセスして使用できる必要があります。価値を得るためのハードルが高いと、リリースした機能の利用率が低くなるおそれがあります。
ソリューションは技術的に実現可能か? どれほど有望なアイデアであっても、それを機能させるために必要なスキルと技術がエンジニアになければ意味がありません。そうでないと、リソースを浪費するおそれがあります。
ソリューションは、企業のリソースと制約の範囲内で実現可能か? ソリューションを完成させるには、おそらく数回のイテレーションが必要です。したがって、その投資をするだけの備えが会社側にあるかどうか確認することをお勧めします。その用意がない場合、結果として放棄されるアイデアに時間を費やすおそれがあります。
チームの目標は、できるだけ効率的にリスクを最小化しながら、直感に頼って過剰投資をしたり、ソリューションに過度な思い入れを抱いたりしないようにすることです。機能をリリースした後でイテレーションや動作検証を始めると、このような問題が起きやすくなります。代わりに、Figma でプロトタイプを作成して顧客に見てもらい、早い段階でフィードバックを受けてからコードを書き始めるといった、負担の少ない手法を採用しましょう。
機能をリリースすることが決まったら、制約が多く残るライブ プロトタイプを開発し、少人数のアーリー アダプターのグループでテストし、速いペースでそれを反復します。このようにすると、特殊ケースのすべてを検討する必要がなくなります。アイデアがうまくいかない場合でも、その理由を短時間で理解でき、うまくいくまで開発とテストを反復するか、どうしてもうまくいかなければそのアイデアを破棄するという決断を下せます。
不確実な領域が大きい場合は、探索ステージの一環として技術的スパイクを行います。この種の取り組みは、チーム自体の制約、技術的に実現可能なこと、技術的に複雑な領域について理解を深めるのに役立ちます。
このステージでのアイデアの検討には、Jira Product Discovery の「Solution definition (ソリューションの定義)」テンプレートを使用するか、独自のテンプレートを作成します。
製品バックログの中で、各アイデアに関連するすべてのドキュメント、仕様、デザインをリンクしておくと、チームや利害関係者とアイデアについて話し合うときにそれらをすぐに取り出すことができます。各資産 (ワンページャーやデザイン) を追跡できるよう、各アイデアに「ハイパーリンク」フィールドを作成することをお勧めします。
その方法については、以下のデモをご覧ください。
探索の実践
アトラシアンでは、Jira Product Discovery を開発する際、次の手法を使用してお客様とともにソリューションを検証しました。
まず PM に対し、さまざまなソリューション候補をまとめたスライドを示して、最も反響の大きいソリューションを確認しました。ここでの会話を通して、お客様が苦労している問題や重視していることを詳細に把握したのです。その結果、「優先順位付け」を Jira Product Discovery の第一の柱に据えることが決まりました。
💡 作成、テスト、変更が簡単なスライドは、この検証段階で使うツールとして最適です。
次に、Figma でプロトタイプを作成してユーザーに示し、ソリューションがどのように役立ちそうか尋ねました。これを試すのに使用した最初のプロトタイプは、PM が利害関係者からのフィードバックに基づいて優先順位を決定できるというソリューションでした。
PM からは一定の関心を得られたものの、価値を実現するまでの準備に手間がかかりすぎるとの指摘を受け、このアイデアは却下となりました。
このようなフィードバックを何度も集めた後、私たちは、現在の Jira Product Discovery の姿、つまり製品のアイデアを議論するためのコラボレーション スペースへと進化するソリューションの検討を始めました。
この段階に至って、ユーザーとの会話は劇的に変化しました。とても便利そうなツールだがいつ利用できるようになるのか、と多くのユーザーが尋ねてくるようになったのです。正しい方向に進んでいると私たちが確信したのはこのときです。
このようなフィードバックを何度も集めた後、私たちは、現在の Jira Product Discovery の姿、つまり製品のアイデアを議論するためのコラボレーション スペースへと進化するソリューションの検討を始めました。
この段階に至って、ユーザーとの会話は劇的に変化しました。とても便利そうなツールだがいつ利用できるようになるのか、と多くのユーザーが尋ねてくるようになったのです。正しい方向に進んでいると私たちが確信したのはこのときです。
開発
開発ステージでは、探索ステージで決定したソリューションを構築して検証します。開発作業の大部分はこのステージで実施されます。
このフェーズの成果物は、機能するソフトウェア、つまり新しい製品や新しい機能、または既存のエクスペリエンスに対する改善です。それは、期待どおりの成果をもたらすことが証明され、十分な数の顧客が採用してその価値を実現し、すべての顧客が使用できる状態となっている必要があります。
このフェーズでも探索フェーズでも、デリバリーが始まったら、アイデアを Jira のデリバリー チケットに関連付けます (エピック レベル以上をお勧めします)。デリバリーの進捗状況を Jira Product Discovery 内で追跡しながら、すべての製品イニシアチブとチームの進捗状況を俯瞰的に把握できます。
アイデアの提供に複数のチームが関わっていて、それぞれが異なる Jira プロジェクトに取り組んでいる場合も、すべてのデリバリー チケットを製品バックログのアイデアにリンクできます。
その後、デリバリーの進捗状況を Jira Product Discovery 内で追跡しながら、すべての製品イニシアチブとチームの進捗状況を俯瞰的に把握できます。
詳細については、[Resources (リソース)] セクションにある、Jira でディスカバリーとデリバリーを関連付ける方法についてのウェビナーをご覧ください。
覚えておいていただきたいのは、期待されている成果をソリューションがすぐに実現できる可能性は非常に低いということです。それを期待するのではなく、早い段階で頻繁に顧客に向けてリリースし、十分な成果が得られるまで反復します。そこで学んだ内容を基に、顧客との会話から得た洞察をアイデアに反映し続けます。成果の測定方法は、アイデアの種類 (新機能や成長イニシアチブなど) によって異なります。メンバーにこのことを周知し、計画でイテレーションを行えるようにしておきましょう。
開発の実践
Jira Product Discovery を開発するときや、この製品に重要な新機能を追加するとき、私たちは、お客様のグループを少しずつ大きくしながらテストと検証を実施しました。このプロセスは、数週間で済んだケースもあれば、数か月かかったケースもあります。
顧客を 0 社から 10 社へ 価値の証明 | 探索フェーズでは、事前に選んだ少数のお客様を対象にイテレーションを行いました。私たちはこれらのお客様と緊密に協力し、一緒になってソリューションを構想しました。このソリューションなら目下の問題を解決できるという確認をお客様からもらえるまで、私たちは反復を続けました。 この段階で、ソリューションの価値を証明できましたが、まだ完成にはほど遠く、特殊ケースも考慮できていません。 |
顧客を 10 社から 100 社へ 機能の完成 | その後、ソリューションにアクセスできるお客様を徐々に増やしていきました。このプロセスは、当初は想定していなかったものも含むさまざまなシナリオの発見に役立ちました。私たちは、ソリューションを使用するアクティブな顧客が 100 社になるまでイテレーションを続けました。 通常、この段階でソリューションの機能は完成しています。しかし、ユーザーがすべての機能を見つけられる状態になっているとは限らず、セルフサービスにも対応していません。たとえば、ユーザーは機能の使い方を理解するために動画のチュートリアルを必要とするかもしれません。 |
顧客を 100 社から 1000 社へ セルフサービス対応 | その後、ソリューションにアクセスできるお客様を 1000 社まで増やしていきました。そして製品分析、サポート チケット、インバウンド フィードバックを利用して機能の利用回数を調査しました。調査結果に基づいて、UX の改善やバグの修正を行いました。利用回数が少なすぎて有用といえない場合は、その機能の見つけやすさを確認しました。 この段階で、機能はセルフサービスで利用できる状態でなければなりません。つまり、見つけやすく、UX は良好で、ドキュメントも整備されている必要があります。 |
一般提供 本番運用対応 | ここでようやく、サポート イネーブルメント、セールス イネーブルメント、運用ダッシュボード、パフォーマンスとスケーラビリティの改善の準備が整いました。 この段階で、ソリューションは本番運用に対応できている必要があります。 |
このようなソリューションを開発する際、アトラシアンでは通常、「ライブ機能ドキュメント」という専用の Confluence ページを使ってソリューションを構想します。これはごくシンプルなページで、チームで集まったとき、現在のイテレーションのスコープについて話し合うために利用します。簡単にリリースできる機能とそうでない機能についての情報が増えるのに合わせ、頻繁にドキュメントを更新していきます。この作業では、個別のタスクではなく、製品エクスペリエンスに焦点を当てますが、製品担当者から設計担当者、エンジニアまで、すべての関係者がここで足並みを揃える必要があります。
影響
製品モデルでは、すべてが成果で始まり、成果で終わります。チームは、成果が得られるようにアイデアの優先順位を判断し、デリバリーの後も、その成果の達成に向けて進捗状況を追跡し続けます。これにより、目標や戦略に最新情報が反映され、優先すべき次の行動を判断できます。
ソリューションをリリースしても、それで「終わり」ではありません。新たに機能をリリースすれば、それがすぐに製品の一部となります。ユーザーにとっての価値を維持し、人々が混乱したり使いにくいと感じたりすることのないよう、継続的に改善していく必要があります。顧客が何を求めているのか、新機能についてどんな意見を持っているのか、それがサポート チケットを通じてどのくらいの頻度で言及されているかを必ず記録しておきましょう。
実際の影響
Jira Product Discovery チームでは、これを行うために月次および四半期ごとのレビューを行い、達成した影響と当初の目標を比較しています。成果に満足してほとんど変更しないこともあれば、ロードマップをリセットして何か違うことを試す場合もあります。
使用する手法を 1 つ紹介しましょう。ソリューションをリリースした後、それに対応する改善アイデアを創出し、次のようなインサイトを収集します。
ユーザーからのインバウンド フィードバック
フィードバック、調査、インタビューにおいて、その機能が構築された目的である問題を解決しているかどうかを示すシグナル
ソリューションが実際に使用されているかどうかを把握するための製品アナリティクスの利用状況データ。使用されていない場合は、見つけやすさに関する課題があるか、計画していた機能に対する期待が薄れている可能性があります。
このデータを定期的に確認し、各チームが機能の改善に予算を割り当てます。新しいアイデアと既存のアイデアに対する改善の両方が、各チームのロードマップに示されます。
アイデアの進捗
Jira Product Discovery には、アイデアに関するデリバリー チケットの進捗を示す一連のフィールドがあります。ただし、これが必ずしも関係者に進捗を伝える最良の方法であるとは限りません。エピックのタスクが 60% 完了したのか、80% 完了したのかは、チームの実際の進捗状況を示すものではありません。
関係者と進捗を共有するには、より影響力の強い方法があります。それぞれのアイデアを (フィールドを使用して) 順調、リスクあり、逸脱としてマークし、(アイデアの説明に) コメントを入力します。これは非常にシンプルなコラボレーションの基本ですが、関係者と支援が必要な箇所を共有するには非常に効果的です。
Atlas の顧客であれば、このアプローチにはすでに慣れているでしょう。「リソース」セクションで、Jira Product Discovery のアイデアを Atlas のプロジェクトに関連付ける方法のビデオをご覧ください。これにより、提供された Jira チケットの進捗をパーセンテージとして測定する以下のビューよりも、より適切で正確なストーリーがわかります。
次のステップ
構想、検証を経てソリューションのデリバリーに至るための手段としてアイデアを使用することで、製品チームは、メンバーを組織化して成果に集中させることができます。
このハンドブックの後半では、製品バックログを次の目的で使用する方法について詳しく説明します。
アイデアを検証するために、フィードバック チャンネルを設定してインサイトを収集する
影響を与える可能性のあるアイデアを優先する
チームと関係者が心から協力できるロードマップを作成する
Jira Product Discovery やその他の製品を使用して、Jira Product Discovery チームでこれを行う方法の例を示します。