プロダクトマネジメントの優先順位付けフレームワークの究極ガイド
この記事は、以下サイトの機械翻訳です。
何を作るか（あるいは次に何を作るか）を決めることは、プロダクトマネージャーの仕事の中で最も重要な部分の一つです。インパクトを与えるチャンスは何度もありません。だからこそ、賢く選択して、チャンスを最大限に生かすことが重要なのです。
プロダクトの優先順位を決めるには、さまざまな要素を考慮する必要があります。しかし、何よりもまず、お客様の真の問題を解決することを優先しなければなりません。多くの企業では、このプロダクト開発の基本方針が守られていません。おそらく、価値よりも革新性を優先しているからでしょう。私たちは皆、自分たちが最先端の先駆者であると他人に思われたいと思っていますが、市場が求めているのは必ずしもそうではありません。
市場が求めているのは、すでに機能しているものを適度に改良することだったりします。究極のゲームチェンジャーを追い求めるのではなく、フリクションポイントを取り除き、物事を少しでも簡単にすることに優先的にリソースを使ったほうがいいのです。
プロダクトマネージャーのための優先順位付けガイド」をダウンロード→
バージョン1.0のプロダクトで何を優先させるか？
プロダクトの初期バージョンに必要なものを絞り込むのは、なかなか難しいものです。振り返るべき実績もなければ、現役のユーザーに話を聞くこともできないので、どんなデータであっても意見に支配されてしまう余地があります。
派手さで人々を驚かせるか？より多くの人にアピールするために機能を詰め込むのか。それとも、ひとつのことを確実に実行するのか。
MVP（Minimum Viable Product）は、ユーザーの真の問題を解決するものでなければなりません。それができなければ、わざわざ作る意味がありません。そのためには、その目的を達成するために必要な機能のサブセットを見つけなければなりません。このプロセスでは、その問題を解決していることを確認するために、可能な限り潜在的なユーザーを調査し、理解する必要があります。お客様を喜ばせることができれば大きなボーナスとなりますが、問題を解決せずにお客様を長く喜ばせることはかなり難しいのです。
Product-Market Fit Bookをダウンロード→
もし、優先順位が高すぎると感じたら、物事を縮小する必要があります。最小限の労力で本質的な問題を解決しようとするだけです。 一度に多くのことをやろうとすると、顧客、チーム、ステークホルダーに悪影響を及ぼします。
だからこそ、レーザーのように一つのことをうまくやることに集中し、ロードマップを使って将来的にそれをどのように発展させていくのかを示すのです。これは、MVPに含まれていないものを「足りない」と思っている人にアピールすると同時に、初期プロダクトの評判に基づいて具体化できる初期のプロダクトビジョンを示すことになります。
フィードバックとプロダクトの真のニーズのバランスをとるには
お客様、パートナー、利害関係者、アドバイザーからの意見は貴重なものです。プロダクトマネージャーは、人々が何を評価し、何を嫌がり、何を求めているのかを知ることができます。しかし、これらの情報はすべて、大目に見ておく必要があります。
幼児に「何が欲しい？」と聞くことを想像してみてください。それは、彼らが必要としているものと同じものでしょうか？もちろん、そうではありません。同じように、お客様も自分の欲しいものを正確に表現する方法を知らないことがあります。
お客様は問題を抱えているので、その解決策をすぐに教えてくれます。しかし、お客様は限られた視点からしか物事を見ておらず、荷物や好み、少ないサンプル数の経験をテーブルに持ち込んでいます。プロダクトにはたくさんのお客様がいるのが理想ですから、プロダクトはたくさんの人のニーズに応えるソリューションを生み出す必要があります。だからこそ、優先順位付けのための消極的なアプローチは、物事を選ぶのに間違った方法なのです。
フィードバックに価値がないわけではありませんが、それは指示的なものではなく、情報的なものであるべきです。優先順位付けは、プロダクト戦略を実行するための積極的な行動に根差したものでなければなりません。机の上に出てきたものにいつも反応していては、火消しのための散漫なアプローチになってしまいます。これでは、合意されたビジョンに向かってプロダクトを前進させることができません。お客様の声をプロダクトのロードマップに反映させる方法については、以下のウェビナーでご紹介しています。
幸いなことに、優先順位付けのフレームワークやアプローチには様々なものがあり、戦略的な思考によって船を導くことができます。合意されたルールと目的を守ることで、プロダクトチームは個々の機能の良し悪しを議論するのではなく、より広い戦略的な文脈の中で物事を考えることができるのです。
よりよいプロダクトマネージャーになるための37のフレームワーク
プロダクトマネージャー（PM）は、次に何に取り組むべきかをどのように決めていますか？そもそも、ある取り組みが推進する価値があるかどうか、どうやって判断するのでしょうか？ほとんどの場合、誰もあなたに計画書を渡してはくれません。だからこそ、仕事に優先順位をつけ、クロスファンクショナルチームのワークフローを最適化し、会社の時間と予算に見合う取り組みかどうかを迅速に評価するノウハウを身につける必要があるのです。
私たちは、このようなニーズに応えるために、実績のあるプロダクトマネジメントのフレームワークをまとめました。
優先順位付けフレームワーク
1. 価値と複雑さの比較
価値対複雑性のフレームワークは、プロダクトチームがロードマップ上で優先すべきイニシアチブ（機能、バグ修正など）を決定する客観的な方法を提供します。チームは、各アクションがプロダクトにもたらす価値と実装の難易度に応じてスコアを付けます。
価値 vs. 複雑さのフレームワークは、ここに示すような優先順位付けマトリクスに基づいて構築されます。
2. 利益 対 コスト（加重スコアリング）
プロダクトマネジャーは、優先順位付けのフレームワークである加重採点を用いて、コストとベネフィットの共通基準に基づいてイニシアティブをランク付けします。チームは基準ごとにスコアを作成します。"例えば、利益の項目では「収益の増加」、コストの項目では「導入努力」といった具合です。チームは、他の基準よりも重要であると判断した基準に対して、より高い総合スコアを設定することができます。
このスクリーンショットは、あるチームが6つのスコアリング基準（3つの利益、3つのコスト）を用いて、競合する7つのプロダクトイニシアチブの相対的な戦略的価値をランク付けした例です。
3. 狩野モデル
狩野モデルは、プロダクトチームが、どの機能が最も顧客を喜ばせる可能性が高いかに基づいて、作業の優先順位を決めるのに役立ちます。チームは、お客様に喜んでいただける可能性と実装コストに基づいて、各取り組みをランク付けします。その後、喜ばれる可能性が高く、コストが低いと評価された機能に優先順位をつけます。
4. Buy-a-Feature
Buy-a-Feature優先順位付けフレームワークは、プロダクトやその他のイニシアチブの作業に優先順位を付ける楽しい方法を提供します。このモデルは、リストにある競合するアクションのそれぞれに価格を設定し、参加者のグループに仮想的な金額を渡して、最も作ってほしい機能を買ってもらうというものです。
5. オポチュニティー・スコアリング
オポチュニティー・スコアリングは、プロダクトチームが、お客様がプロダクトに必要な機能でありながら、どの機能が残念だと感じているかを判断するのに役立ちます。プロダクトチームは、顧客にいくつかのプロダクト機能の重要性をランク付けしてもらい、次にそれぞれの機能にどれだけ満足しているかを評価します。重要度は高いが満足度が低い機能は、それを改善するために必要な開発作業に対する高い投資収益率を実現するチャンスである。
6. 親和性グルーピング
親和性グルーピングは、優先順位付けのための非公式で協力的なフレームワークとして設計されています。各参加者は、プロダクトを改善するためのアイデアを考え出し、ノートカードやホワイトボードに書き出します。その後、参加者はこれらの機会を重要なテーマ（親和性グループ）に整理し、各グループの下でそれぞれの可能性にどのように優先順位をつけるかを投票します。
7. ストーリーマッピング
ストーリーマッピングのフレームワークは、プロダクトマネージャーに、それぞれのユーザーストーリーがプロダクト体験全体にどのように貢献しているかを視覚的かつ全体的に把握させるものです。チームは大きなボードや壁を使って、ユーザーとプロダクトとのインタラクションの視覚的なウォークスルーを作成し、まず重要なステップを特定し、その下に個々のストーリーを追加していきます。このマップが完成すると、チームはユーザーエクスペリエンスを論理的に把握することができ、どのストーリーが優先度が高く、どのストーリーが低いのかを判断することができます。
8. アイゼンハワー・マトリクス
アイゼンハワー・マトリクスは、チームの優先順位付け、生産性、意思決定の改善に役立つ。ドワイト・アイゼンハワー大統領が使用した方法にちなんで名付けられたこのフレームワークでは、4つの正方形を2つずつ重ねて描きます。X軸には「緊急」と「非緊急」、Y軸には「重要」と「非重要」を設定します。このフレームワークでは、「重要」「緊急」から「重要でない」「緊急でない」までの4つの可能性があります。この4つのボックスにリストアップされた施策を配置すれば、左上の象限である「重要・緊急」にどれを優先して取り組むべきかがわかります。
9. ICEスコアリング
ICEスコアリングモデルを使用すると、プロダクトマネージャーは、影響力、信頼性、容易性という3つの基準に基づいてそれぞれのスコアを割り当てることで、競合するイニシアティブを素早く評価することができます。ICEスコアリングは、プロダクトチームがどのプロジェクトに取り組むべきかを迅速に決定し、できるだけ早く作業を開始できるようにするためのものです。しかし、加重採点のような他のフレームワークほど厳密ではありません。
10. インパクトマッピング
インパクトマッピングによる優先順位付けのフレームワークでは、プロダクトマネージャーは、まずハイレベルな戦略目標に焦点を当てます。そして、そこから外に向かって、関連するアクター（ユーザー自身を含む）を決定し、各アクターがどのようにゴールに貢献できるか、成功したときの最終的なアウトプットは何かを決定します。
11. MoSCoW分析
MoSCoW優先順位付けフレームワークは、チームの要件管理に役立ち、特定のリリースにおけるイニシアチブの重要性をステークホルダーに理解してもらうために一般的に使用されます。イニシアチブを4つのカテゴリーにグループ化し、頭文字を構成する。Mは「must-have」項目、Sは「should-haves」、Cは「could-haves」（またはnice-to-haveイニシアチブ）、Wは優先度が低いとされる「will not have」項目を表す。
12. RICEスコアリング
RICEスコアリングフレームワークは、プロダクトロードマップ上のアイテムを「リーチ」「インパクト」「信頼性」「労力」の4つの基準で採点することで、プロダクトチームがアイテムに優先順位をつけるのに役立ちます。チームが4つの基準ですべての項目のスコアを合計すると、各項目のスコアが1つになり、プロダクトや組織にとっての相対的な価値を評価することができます。
アジャイルプロダクトマネジメントフレームワーク
13. クリスタルアジャイルフレームワーク
ソフトウェア開発のためのアジャイルマニフェストから生まれたクリスタルアジャイルフレームワークメソッドは、人間中心のアジャイルフレームワークである。つまり、チームが自由にワークフローを開発・改善できるように設計されている。このフレームワークは、各チームがそのニーズや状況に合った適切な方法論を見つけることを可能にしますが、一方で、混乱や、スコープクリープを引き起こす可能性もあります。
14. ディシプリンド・アジャイル
ディシプリンド・アジャイル（DA）は、個人やチームが好みのワークフロー方法を見つけることができるという点で、クリスタル・メソッドと似ている。しかし、ScrumやKanbanなどの他の方法論からベストプラクティスを引用して、これらのチームがどのように作業すべきかについて、いくつかの軽いガイダンスを提供している。
15. デュアルトラックアジャイル（Dual-Track Agile）
デュアルトラックアジャイルアプローチでは、クロスファンクショナルチームが作業をディスカバリーとデリバリーの2つのカテゴリーに分けます。ディスカバリートラックでは、有効なプロダクトアイデアを素早く生み出すことに焦点を当てます。デリバリーは、これらのアイデアを市場で通用するプロダクトにすることに焦点を当てます。
16. 動的システム開発手法（DSDM）
DSDM（Dynamic Systems Development Method）は、プロジェクトの構想から完成までのライフサイクルが、ビジネスにどのような影響を与えるかを評価する手法です。このフレームワークでは、「フィージビリティ・ビジネススタディ」「機能モデル・プロトタイプの反復」「デザイン・ビルドの反復」「インプリメンテーション」の4つの基準で各プロジェクトを評価します。DSDMモデルでは、「すべてのプロジェクトは、明確に定義された戦略目標に沿ったものでなければならず、ビジネスに真の利益を早期に提供することに焦点を当てなければならない」としている。
17.エクストリーム・プログラミング（XP）
最も人気のあるアジャイルフレームワークの1つであるエクストリームプログラミングは、ソフトウェア企業が動的に変化する要求に効果的に対処できるように設計されています。このフレームワークは、ソフトウェア企業がダイナミックに変化する要求に効果的に対応するために設計されています。このフレームワークでは、少人数の開発チームを編成し、自動化されたユニットテストや機能テストを活用します。なお、エクストリーム・プログラミングを使用する際には、開発者がマネージャーや顧客と密接に連携する必要があることを念頭に置いておく必要があります。
18. 機能駆動型開発(FDD)
機能駆動型開発は、大企業を中心に採用されているアジャイルフレームワークですが、その理由は、トップダウンの意思決定フレームワークであり、担当者の階層化が必要だからです。FDDモデルでは、チームの作業を機能の進捗に合わせて整理します。このフレームワークでは、ユーザーストーリーも含まれます。
19. リーンソフトウェア開発
元々はトヨタ生産方式（このフレームワークを開発した会社の名前）と呼ばれていたが、プロダクトに必要なもの以外を開発から排除することに重点を置いたソフトウェア開発モデル。また、MVP（Minimum Viable Product）戦略と呼ばれることもある。これは、チームの目標がユーザーに必要最低限のプロダクトを提供し、そのフィードバックを利用してプロダクトを改善することであるため。
20. ラピッドアプリケーション開発
RAD（Rapid Application Development）アジャイルフレームワークは、ソフトウェアプロダクトのプロトタイプを迅速に作成し、市場にリリースしてフィードバックを得るために使用されます。チームは、このフィードバックをもとにプロダクトを改良し、新しいバージョンをリリースして、このサイクルを続けます。RAD フレームワークは、要件計画、ユーザー設計、迅速な構築、カットオーバーの各ステージで構成されています。
21. スケールドアジャイルフレームワーク(SAFE)
大企業で広く使われている手法であるスケールドアジャイルフレームワーク（SAFe）は、大企業がアジャイルチームの規模を拡大する際に直面する共通の課題から守るために設計されている。このトップダウンの意思決定フレームワークは、開発の3つの側面（チーム、プログラム、ポートフォリオ）に焦点を当てている。
無料のテンプレートを使って独自のアジャイルロードマップを作成する→
UX/デザインフレームワーク
UXチームやデザインチームがフレームワークを使ってどのように優先順位をつけているかを知っておくことも有効です。
22. デザイン思考
デザイン思考とは、ユーザーの視点で物事を捉え、イノベーションを起こすためのフレームワークです。このフレームワークを開発したと言われているIDEO社は、デザイン思考はプロダクトを作るための人間中心のアプローチであると述べています。
23. CIRCLES
CIRCLESメソッドは、プロダクト設計のフレームワークで、特定の道筋をたどり、正しい質問に答えることで、設計すべきものとその理由を完全に理解することを目的としています。このプロセスの段階は、頭文字をとったものです。状況を把握する。（Comprehend the situation.）顧客を特定する。（Identify the customer.）顧客のニーズを報告する。（Report the customer’s needs.）優先順位を決める。（Cut through prioritization.）解決策をリストアップする。（List solutions.）トレードオフを評価する。（Evaluate trade-offs.）提言を要約する。（Summarize your recommendation.）
24. ユーザーは酔っぱらっている
UXやウェブデザインにおいて、このフレームワークはシンプルな質問をします。あなたのサイトやアプリは、酔っぱらった人でも使えるほど簡単で直感的ですか？
25. KEYデザインプロセス
UXPlanetの説明によると、KEYデザインプロセスは、デザイナーが自分の仕事を管理するための2つの部分からなる戦略です。その2つの部分とは、オポチュニティセグメントとソリューションセグメントです。この適応可能なガイドラインの目的は、デザイナーが開発に移る前に、文脈を考慮し、ユーザーを理解し、理論を検証することを継続的に思い出させることである。
26. ケネディの原則
ジョン・F・ケネディ大統領が1961年に発表した就任演説の中で最も有名な一節に由来するデザイン原則。"Ask not what your country can do for you -ask what you can do for your country." ケネディデザインの原則は、ユーザーがあなたのために何ができるかではなく、あなたがユーザーのために何ができるかを問うことです。つまり、ユーザーの時間と忍耐力には限りがあるので、アプリが自動化できる作業をユーザーにさせて、そのどちらも無駄にしないようにするということです。例えば、最初にユーザーの米国の郵便番号を尋ね、次に別のフィールドで居住地の州を入力するように求めるフォームを設計することができます。あなたのコードは、ユーザーのために2番目のタスクを実行する必要があります。
その他のプロダクト管理フレームワーク
27. DACI
DACIは、4つの役割をカバーすることから名付けられた意思決定フレームワークです。ドライバー（意思決定を推進する人）、承認者（意思決定を行う人）、コントリビューター（プロジェクトに協力する人）、インフォームド（プロジェクトによって仕事に影響を受ける可能性のある人）があります。
28. GISTプランニング
プロダクト計画フレームワークであるGISTは、管理者のオーバーヘッドを減らし、開発スピードを上げ、成功するプロダクトを提供するために設計されています。GISTという名前は、このアプローチの重要な柱であるゴール、アイデア、ステップ・プロジェクト、タスクを表しています。
29. ジョブ理論(JTBD)
デザイン思考と同様に、チームの焦点をプロダクトから顧客に移すことを目的としたフレームワーク。このアプローチにより、プロダクトチームは、顧客がプロダクトやサービスを購入する際に何をしたいのかを知ることができ、企業はそのニーズを満たすために開発に集中することができます。
30. 品質機能展開
品質機能展開（QFD）は、プロダクトの開発と生産のために50年前に普及した方法論です。お客様の声に耳を傾け、その声をチームの計画に取り入れることを中心にアプローチを構築する。QFDのフレームワークは、お客様の要望、ニーズ、期待をプロダクト開発のための技術的要件に変換します。プロダクトのライフサイクルを通して、生産の各段階にお客様の声を取り入れることです。
31. SWOT分析
SWOT分析とは、新プロダクトの開発や新市場への参入など、戦略的な取り組みを開始するかどうかを判断するための計画・意思決定フレームワークである。SWOT分析では、プロジェクトを強み（Strength）、弱み（Weakness）、機会（Opportunities）、脅威（Threats）の4つの要素に分けて分析します。チームは、これらの基準に基づいてプロジェクトの価値とリスクを評価し、プロジェクトを進めるかどうかを決定します。
SWOTマトリクスは、下図のようなシンプルな2×2のグリッドで構成されます。強み」「弱み」「機会」「脅威」と書かれたボックスが必要です。
32. 古典派経済学
古典経済学は、アダム・スミスなどの思想家によって有名になった学派です。アダム・スミスは、自由市場を主張し、合理的なアクターが自分の利益のために働くことで、すべての人がより高いレベルの繁栄を得られると考えました。プロダクト管理に古典派経済学のアプローチをとる場合、これらの広範なマクロ経済学の原則を市場に適用します。顧客が合理的に行動し、購入するプロダクトを選ぶ際には、合理的な判断を下すことを前提とします。
33. 行動経済学
プロダクト管理における行動経済学のフレームワークでは、ユーザーベースを別の視点で捉えます。この考え方は、人々の感情に訴え、アンカリングなどの価格戦略を用いて、自社プロダクトの価格をより高く設定することを主張するアプローチです。古典派経済学のフレームワークとは異なり、このアプローチでは、人々を合理的なアクターとしてではなく、感情に左右されるアクターとして見ています。
34. HEARTフレームワーク
Googleは、UXの世界に定量的な指標を導入するためにHEARTフレームワークを開発した。この柔軟な手法により、デザイナーは5つの指標に基づいて、特定の機能またはユーザーエクスペリエンス全体を定量化することができます。5つの指標とは、ハピネス、エンゲージメント、アドプション、リテンション、タスクサクセスです。
このフレームワークの発端は、典型的なUXチームが、すべての利用可能なデータを実用的なインテリジェンスに変えることができなかったことでした。HEARTを使用することで、測定可能なユーザーエクスペリエンスの目標を定義し、データに基づいた意思決定を、通常は測定可能なデータに頼らずに設計を進めるプロダクト開発の分野にもたらすことができます。
しかし、「HEART」をUXに限定する理由はありません。プロダクトマネージャーは、同じ原則をプロダクトのあらゆる側面に適用することができます。HEARTは、他の多くのフレームワークがほとんどカバーしていない、顧客の喜びと満足について深く掘り下げています。
35. AARRR
AARRRは、スタートアップ企業のために設計された、若いビジネスの成長を支援するための5つのステップのフレームワークです。ベンチャーキャピタリストのDave McClureが開発したこのフレームワークは、McClureがすべてのスタートアップ企業が注力すべきと考える5つの主要指標の頭文字をとったものです。この5つの指標とは、アクイジション（獲得）、アクティベーション（ユーザーの最初のプロダクト体験を指す）、リテンション（維持）、リファラル（紹介）、レベニュー（収益）です。
36. 4つのD（Do's、Defer、Delegate、Dump)
4つのDは、時間管理のフレームワークです。何らかのタスクや義務に直面したときに、4つの選択肢があることを説明しています。その選択肢とは、「すぐに実行する」「後回しにする」「誰かに委任する」「そのタスクを完全に捨てる」というものです。
37. 逆算法（Amazonメソッド）
Amazonが開発したプロダクト開発のフレームワークで、プロダクトマネージャーは、新プロダクトの市場投入を知らせるプレスリリースを書くことから始めます。想定読者はエンドユーザーであり、リリースではユーザーの現在のニーズや問題点、他の選択肢では解決できなかった点、他が失敗したところでこの新プロダクトが成功する点などを説明する。プロダクトチームの思考を集中させ、そのプロダクトを作る価値があるかどうかを正直に評価させるための戦略である。
優先順位付けの際のバックログへの対処法
プロダクトのバックログは、時間が経つにつれ、管理しきれないほどの混乱状態に陥り、有用でよく整理されたアイデアの保管場所から、混沌とした貯蔵庫に変わってしまいます。バックログが実際の価値を維持するためには、優先順位付けが必要です。
バックログは、今すぐには処理したくないアイデアを放り込む暗いクローゼットではないはずです。バックログは、煩わしい営業上の要求や、あまりにも具体的な顧客の要望、無視された技術的負債などのガラクタ置き場になるべきではありません。
バックログは、うまく管理されていれば、インスピレーションの整然とした列になるはずです。バックログに保管されているアイテムに優先順位をつけることで、バックログはその目的を果たすことができます。しかし、そのためには、いくつかの規律と厳しい選択が必要です。
絶対に作られないものは、バックログに入れるべきではなく、ゴミ箱に入れるべきです。十分に重要なものであれば、将来的に評価し、それに応じて処理します。
また、すべてのバックログアイテムを同じように考えるべきではありません。もうすぐリリースされることが決まっているものと、何ヶ月も何年も日の目を見ないであろう「必要なもの」とは、別々に分類されるべきです。さらに、バックログを平均的で無駄のないものにしておけば、その内容を定期的に見直すこともそれほど負担にはなりません。
点数をつけるとロードマップが簡単になる理由
これまでに紹介した優先順位付けのフレームワークの多くは、スコアリングを重視しています。これらの数値は、何を優先すべきかを決定する際に役立つだけでなく、プロダクトロードマップの作成を迅速に行うことができます。
個々の項目をスコアリングする際には、複数のベクトル上で各項目の数値を定量化します。ただ単に優先順位をつけるのではなく、マトリクス形式で図示することで、全体的な優先順位を決めることができます。これらの情報があれば、ロードマップに優先度の高い項目が含まれていることを確認できるだけでなく、バランスをとることができます。
例えば、優先順位の高い上位3つの項目がすべて収益をもたらすものでありながら、お客様の喜びを向上させることにあまり貢献していない場合、その3つを最初に実行することは意味がないかもしれません。それよりも、現金をもたらす優先度の高い機能と、お客様の喜びを高める機能を追加してバランスを取ることが大切です。
例えば、No.1とNo.4のアイテムは、No.2とNo.3よりも先に実行されます。しかしそれは、お客様が興味のない項目に取り組む間、何ヶ月も待たされるのではなく、お客様がワクワクするようなものを安定的に提供するということでもあります。
プロダクトロードマップの無料ガイドをダウンロード→
目標に沿った優先順位付けプロセスの開発
もしあなたの組織が、objectives and key results（OKR）を定義しているなら、優先順位付けのプロセスでそれを活用することもできます。この人気の高いフレームワークは、グーグルから様々な業界の組織に広まっており、収益に焦点を当てることが好まれています。
それぞれの目的は、すでに本質的にエピックやロードマップのテーマとなっています。プロダクトが達成すべきことを簡潔に表現しています。それをロードマップの文脈で表現し、各ユーザーストーリーや開発項目を、組織が優先している測定可能な重要な結果に直接結びつけます。
OKRを出発点とすれば、ロードマップの構造は自ずと決まってきます。次に、前述のフレームワークのいずれかを使用して、プロダクトが目標とする重要な結果を達成するのに役立つ機能に優先順位を付けることができます。
どの優先順位付けフレームワークを使うかの選択方法
何十もの選択肢がある中で、プロダクトの優先順位付けフレームワークを選択することは、圧倒的に難しいと思われるかもしれません。確かに検討すべきことはたくさんあります。
しかし、これほど多くのフレームワークが存在するのは、企業の規模、プロダクトの成熟度、プロダクト開発組織の文化など、多くの組織が異なるニーズを持っているからです。最新のレポートでは、プロダクトマネージャーに最も支持された優先順位付けフレームワークを紹介しています。
新しいレポート「Product Managers in 2020」では、プロダクトマネージャーに関する洞察を得ることができます。
私たちは、より簡単に自分に合う人を見つけることができるようになりました。個人の好みと、組織のスタイルやニーズを組み合わせることで、簡単に絞り込みができます。
何よりも、たくさんの候補の中から、いくつかの候補を試してから、いつものプレイブックの一部にすることができるのです。
LINE公式アカウントから「海外プロダクトマネジメント情報を機械翻訳」の新着投稿を受け取る
Discussion