プロダクトマネジメントプロセスの主なステージ
この記事は、以下サイトの機械翻訳です。
素晴らしいアイデアだからといって、それが自動的に素晴らしいプロダクトになるとは限りません。そもそも、すべてのアイデアが素晴らしいわけではありません。このように、プロダクトマネジメントは、混沌とした状況に秩序をもたらし、最終的にはプロダクトを市場に送り出すための重要な役割を担っています。
プロダクトマネジメントのプロセスには、普遍的なプレイブックはありません。しかし、ほとんどの組織では、基本的な作業順序はほぼ同じです。プロダクトマネジメントプロセスは、複数のステークホルダーが参加し、複数の部門が協力して進めていく、長い道のりです。しかし、プロダクトマネジメントプロセスは物事の道しるべとなります。
この記事では、プロダクトマネジメントプロセスの7つの主要ステージを定義します。職場によって名称や内容は異なるかもしれませんが、ほぼすべてのプロダクトが同じような道のりを辿ります。
アイデアマネジメント
アイディアを出すことは、それほど難しいことではありません。ひらめきは誰にでもあります。また、ブレインストーミングや顧客インタビュー、競合他社の調査など、アイデアを引き出すための仕組みはいくらでもあります。
しかし、それらをすべて実行することはできないので、プロダクトマネジメントは、どのアイデアを優先的に採用するかを見極めなければなりません。そのためには、プロダクトマネジメントがアイデアの創出と整理を行う必要があります。
アイデアは、さまざまなチャネルを通じて継続的に発生します。できれば、それらを整理してタグ付けし、最終的に評価できるようにすることが重要です。多くの組織では、アイデアはプロダクトバックログに蓄積されます。プロダクトバックログは定期的に精査され、無意味になったものや重複しているものを一掃する一方で、将来的な検討のために存続可能な「キーパー」を検証します。
これらのアイデアを集め、集約し、保存するための透明性のあるシステムを維持するのは、プロダクトマネジメントの役目です。チームはまだこれらの可能性のある機能や強化について判断を下していないため、社内のステークホルダーやお客様、さらには役員や投資家など、提案をしてくれた人たちに、そのアイデアの状況を伝えなければなりません。
教育とプロセスの可視化は、強固な関係とオープンチャネルを維持するための鍵となります。これにより、ステークホルダーは、自分のアイデアだけが実現の可能性を秘めているわけではないことを理解することができます。
分類
アイデアを収集して分類したら、次は詳細を把握しましょう。これにより、プロダクトマネジメントプロセスにおいて重要となるいくつかの事柄を達成することができます。
プロダクト仕様書は、3つの重要な質問に答える、短くて技術的でない文書でなければなりません。
- 何を作ろうとしているのか、そしてその理由は？
- この新プロダクトは何を達成すべきか？
- 成功をどのように評価するか？
これらの質問に対して、チームは様々なステークホルダーの意見を取り入れながら共同で答えを出し、あらゆる角度から検討し、全員が何を考えているのかについて合意を得られるようにしなければなりません。可能な限り曖昧さを排除することで、後に優先順位をつけて実行する際に、何を検討しているかが明確になります。
プロダクト仕様書にどの程度の詳細を盛り込むかは、組織のプロダクト開発スタイルによって異なります。例えば、ウォーターフォール方式のように技術者がピクセル単位の詳細を求めている場合から、アジャイル方式のように開発チームが実装の詳細を決定する場合まで、様々なケースがあります。
プロダクト仕様
| 項目 | 説明 |
|---|---|
| プロダクト概要 | プロダクトのアイデア、最終プロダクトの概要、特徴、スケジュールなどを説明しています。また、「なぜ」そのプロダクトが作られるのかを説明します。回答 どのようなアイデアが提案されていますか？ |
| ビジネスケース | 会社にとってのメリット/デメリットを含む、プロダクトを作るためのビジネスケースを説明します。また、必要な予算やリソースを概説する。答え：どのようなものですか？ターゲットユーザーにとってのビジネスバリューや価値は何か？ |
| ユーザーストーリー | 望まれる機能を説明する、ユーザー視点の簡潔な要約（例：As a feature, I [goal] so that [benefit]]のように。答えです。ターゲットユーザーは何をしようとしているのか？ |
| ユーザーペルソナ | プロダクトのターゲットユーザーの関連する特性、ニーズ、目標を説明したもの 答え。誰のためのソリューションですか？ |
| ユーザーペルソナ | プロダクトの物理的なラフデザイン 通常、スケッチや技術的な図面から始まり、開発が進むにつれて進化していく。答えは？ソリューションはどのようなものか？ |
| 機能仕様 | プロダクトの機能やユーザーとの関わり方などを記載した文書。答えは？ソリューションの背後にある技術的な詳細は何ですか？ |
この段階でプロダクト要件を具体化するもう一つの目的は、あるアイテムやプロジェクトがどのくらいの規模の事業になるのかを把握することです。大まかな作業量がわかれば、プロダクトマネージャーは、所定の期間内に達成可能なものを現実的に考えて、プロダクトロードマップに反映させることができます。
プロダクト開発ロードマップチェックリストをダウンロードする➜
ロードマップ作成
ロードマップの作成は、優先順位付けよりもプロダクトマネジメントのプロセスの中で早い段階で行われることに驚かれるかもしれません。まだ優先順位がついていないのに、どの機能や強化を載せるかを決めることができるでしょうか？
優先順位付けの段階の前にロードマップを作成することで、プロダクトマネージャーは、機能Xと機能Yの議論から話をそらし、プロダクトビジョンを前進させるより高いレベルの目標、目的、テーマに話を移すことができます。これにより、個々の機能強化に集中するサイクルを断ち切り、ノーススターメトリクス、KPI、戦略目標に影響を与える意味のある成果を強調することができます。
また、どのハイレベルなテーマを異なる期間に取り組むべきかを選択することで、プロダクトチームは、数ヶ月、あるいは数年前に非常に具体的な約束をしてしまうのではなく、実際に導入する時に近い段階で、最大の効果と最高のROIをもたらす具体的な項目を正確に決定することができます。
その結果、一貫した戦略が維持され、ステークホルダーは、会社が守れない、あるいは守りたくない約束をすることなく、どの戦略分野に取り組んでいるかを確認することができます。また、より多くの情報を収集し、より多くの技術的進歩を遂げても、柔軟に対応することができます。
優先順位付け
次に、これらのバックログ項目のうち、どの項目をカットしてアイデア段階から前進させる価値があるかを決定します。ここでは、数ある優先順位付けフレームワークの中から、便利なものを選びます。
ファンの多いプロダクトツリーやRICEのようなスコアリングモデルを使っても、この演習では、プロダクトのビジョン、戦略、KPIにどのような影響を与えるかに基づいて、どの項目に最初に取り組むべきかを決定します。優先順位付けの作業には、必ず幅広いステークホルダーの参加を得て、複数の視点や意見を考慮に入れる必要があります。
どのような手法であっても、優先順位付けは、利害関係者が不満や要望を抱いている緊急性の高い問題と、プロダクトや会社の中長期的な戦略を実行するために不可欠な必須項目とのバランスをとる必要があります。
残念ながら、誰もが自分の望むものを手に入れられるとは限りません。これらの決定は、プロセス（そしてプロダクトマネージャーとしてのあなたの仕事）の中で最も精査される部分です。しかし、プロダクトにとって正しいことをするためには、プロダクトマネージャーは、お客様や営業担当者、さらには役員に対しても「ノー」と言わなければならないことがよくあります。
デリバリー
ロードマップと優先順位付けされたアイテムのセットができたら、いよいよ製造と出荷を開始します。この段階では、プロダクトマネジメントは一歩退き、エンジニアやプロジェクトマネージャーが主導権を握る中で、助言やコンサルティングの役割を果たすことが多くなります。
プロダクトをどのように出荷するかは、組織によって大きく異なります。極端な例としては、ウォーターフォールモデルがあります。これは、厳密にスクリプト化された詳細なプロジェクト計画を持ち、リリースはごくわずかで、機能の大きな塊が完成してテストされたときにのみ出荷されます。
アジャイル型の組織は、作業をより小さな塊に分割し、スプリントで可能な限り完成させます。これは、プロダクトの反復的な改善がより頻繁に行われることを意味します。しかし、特定の商品がいつ出荷されるのかを正確に知るという意味では、状況は少し予測不可能になります。
さらに、新機能やバグフィックスなどの変更が完了してテストされるとすぐに出荷する、継続的なデリバリーを採用している企業もあります。実際には、1日に複数回のリリースが行われることもあります。
これらの様々なデリバリーモデルには熱烈なファンがいますが、プロダクトの性質や構築するチームによっては、どのモデルにも良いケースがあります。どのようなデリバリー手法であっても、プロダクトマネジメントの役割は、構築されたものが市場やステークホルダーの要求や期待に確実に応えることです。プロダクトマネージャーは、プロジェクトの目的を達成するための作業を定義し、明確にし、検証しなければなりません。
分析と実験
プロダクトがリリースされると（あるいはコントロールされたベータ版としても）、プロダクト分析は、プロダクトが適切に計測されたときに得られるユーザーデータの洪水によって、学習のための新たな機会を提供します。これらの情報から、関連性、因果関係、相関関係のすべてを推測することができ、これは非常に有益です。
この段階でプロダクトマネジメントはいくつかの重要なことを行うことができます。まず、どの行動が会社が重視する主要な指標を動かしているかを知ることができます。例えば、コンバージョンを最重要視するのであれば、多くのユーザーが購入前に何をするのかを知ることができます。また、採用や頻繁な使用が目標であれば、それらのコホートに共通するものを探すことができます。
これらの情報に基づいて、チームは障壁を下げるための取り組みに優先順位をつけることができます。さらに、ソフトウェアやユーザーエクスペリエンスそのものを変えたり、教育、オンボーディング、アプリ内のメッセージングなどを通じて、ユーザーが「よく使う人」から「よく使う人」になるためのタスクを完了するよう促すことができます。
また、成功している顧客や利益を上げている顧客の特徴を把握することで、プロダクトの機能面だけでなく、営業やマーケティングの面でも、どのニッチ分野に投資すべきかがわかります。プロダクトチームは、この情報をもとに、ターゲットとなるペルソナを構築したり、磨きをかけたりして、同じような考えを持つ見込み客を探すことができます。
また、プロダクト分析を行うことで、プロダクトチームは実験を行うことができます。プロダクトチームは、ユーザーベースのさまざまなセグメントに対してあらゆる種類のシナリオをテストし、その効果を測定することができます。その結果をロードマップに反映させ、現在のユーザーエクスペリエンスを最適化することができます。分析に利用できる適切なデータと、それを実現するチームがあれば、実験と継続的な学習の文化が定着し、プロダクトを向上させることができます。
お客様の声
プロダクトが出荷されたということは、（願わくば）お客様からのフィードバックを収集し、募ることができるということでもあります。これは楽しみでもあり、恐怖でもあります。役に立つ提案や洞察の一方で、クレームや突飛な要求、そしてプロダクトがお客様の期待を裏切っていることに気づくこともよくあります。
プライドを捨て、外部の視点を受け入れるだけでなく、プロダクトマネージャーは、時間をかけて意見を提供してくれたお客様との関係を深めるために、フィードバックの収集と整理のための明確なプロセスを確立しなければなりません。これは偶然ではなく、このプロセスの始まりであるアイデアマネジメントに通じるものです。バージョン1.0」の後、プロダクトマネジメントは、他のどこよりも多くのアイデアをお客様から得ることになります。
お客様の声を集めるには、さまざまな方法があります。例えば、カスタマーサービスや営業チームとのやり取りの中から提案をする機会をアプリ内で提供するなど、受動的な方法もあります。しかし、プロダクトマネージャーは、このような意見を積極的に収集することもできますし、そうすべきです。
顧客フィードバックの機会としては、アンケート調査、顧客諮問委員会、フォーカスグループ、顧客インタビュー、ユーザビリティテストなどがあります。しかし、お客様が何を考えているのかを知るための、目立たない方法は他にもたくさんあります。
そして忘れてはならないのが、元顧客からのフィードバックです。ユーザーがプロダクトを手放す原因を分析することは、プロダクトを手放さない理由を探るよりも有益な場合があります。
あなたのマイレージは変わるかもしれません
上記のようなプロダクトマネジメントプロセスは理想的かもしれません。しかし、このように規定された道から外れてしまう理由もたくさんあります。ロードマップを作成したり、プロダクト仕様書の作成に時間をかけたりすることに自信を持つ前に、物事に優先順位をつける必要があるかもしれません。あるいは、最初にある程度の実験をしないと、チームが完成品の納品に向けて自信を持って進めることができないかもしれません。
しかし、たとえチームが異なる順番で完成させたとしても、それぞれのステージには相応の価値があるはずです。お客様に喜んでいただき、プロダクト戦略に沿ったプロダクトを市場に送り出すためには、どれも欠かせない要素なのです。
Twitter始めました🐣
LINEで「海外プロダクトマネジメント情報を機械翻訳」の新着投稿を受け取れます📬
Discussion