プロダクト ロードマップのプレゼンテーションで成功を収める 10 の方法

プロダクト ロードマップのプレゼンテーションは開発者とプロダクト マネージャーの双方にとって、いらいらさせる展開になる場合があります。片方はビジョンを描くことに懸命になり、もう片方は自分たちの作業に影響を及ぼすことになる未知の部分がわかるまで様子をうかがいます。

開発者として仕事をしていた頃、私はこの葛藤を感じ、プロダクトマネジメント担当が作成したロードマップを不満に思っている自分に気づくことがよくありました。その決定に完全には同意しておらず、多くの場合、計画会議の後「納得いかないが、これが上層部の考えなら仕方ない」という気持ちで会議室を出ました。もっと感情が高ぶっているときには、「自分たちで考えて、このロードマップを開発作業に合ったものにしなければだめだ」とさえ感じました。

問題は、私が NIH (Not Invented Here (ここで発明されたものではない) 症候群) にかかっていることだと反論されるかもしれません。その可能性もあります。開発者として、私は何を行うことが正しいかについて非常に強固な意見を持っていました。しかし、プロダクト マネージャーになった現在は、このすれ違いの原因を理解しており、どのような一般的知識によってプロダクト マネージャーがロードマップのプレゼンテーションでこのすれ違いを避け、成功を収められるかわかります。結局、技術チームが全体像に同意し、理解すれば、日常的な設計と実装の意思決定は適切な状況で行われ、プロダクト マネージャーは思い描いたとおりの製品を手にできます。

プロダクト ロードマップのプレゼンテーションでチームを味方につける、私のトップ 10 の方法をご紹介します。

「ビッグ データ分析」、「機械学習」、「モノのインターネット (IoT)」などの業界の流行語は、大まかなアンカー ポイントとしてビジネス部門の関係者の共感を得るかもしれませんが、技術チームにとっては、有用ですぐに実行可能な項目ではありません。技術者は、何を作成しようとしていて、それが現在の製品とどのような関係があり、どのように提供されるべきで、最終的に誰が、何の目的でそれを使用するのかということを正確に知る必要があります。

ハイレベルのテーマを設定することは、ロードマップとコンテキストを構成するには優れていますが、そこで終わってしまわずに、各ハイレベルの項目の背後にあるものについて明確な答えを用意しておくべきです。たとえば、テーマを「インテリジェント サービス」とした場合、このテーマを実現するために必要とされる、重要なイニシアチブとエピックに必ず細分化するようにします。

技術チームは、あなたがロードマップ上で何かを作成している理由の背景事情を知る必要があります。技術チームでなければ、「どうしてほしいか言ってくれれば、作りますよ」と言うでしょう。 しかし、技術者はあなたがある機能を要求する根拠を理解する必要があります。データに語らせるだけでなく、ユーザーの観点からも強力なストーリーを伝えてくだいさい。ペルソナを使用し、あなたが除外した代替案について、その理由と共に話します。チーム全体がロードマップを理解できるようにするには、「何を」と同じぐらい「なぜ」も重要です。

ある機能が十分に考え抜かれていないか現実的でないように思われるのに、まだロードマップ上にある場合、これは危険信号です。あなたが誰かに約束してしまったために技術チームが物を開発しなければならないという印象を与えないようにします。これは、お客様へのコミットメントの場合もあれば、「経営陣がそれを望んでいる」からという場合もあります。したがって、コミットメントはよく考えて行ってください。特定の変更を要求する強制的な働きかけがあなたの背後にあっても、必ず論理的根拠を理解して、チームに伝えるようにし、それを自分自身でも支持できるようにします。

ビジョンを持つのは素晴らしいことですが、達成できるという確信を全員が感じられれば、もっと良いです。綿密な計画である必要はありませんが、開発マネージャーがロードマップを見たとき、最初に目にするものが大きな障害であればどうなるでしょうか。たとえば、量が多く、フロントエンド中心の設計なのに、チームには設計者が一人しかおらず、その設計者はすでにここ数カ月フロントエンドのトピックにずっと取り組んでいる、といった場合です。プレゼンテーションの残り時間すべてを使って、ロードマップを巡って開発マネージャーと闘うことになるでしょう。

現実性について率直にチームと確認し、what-if シナリオを確認するようにしてください。あなたは全員のコミットメントを求める際に、「どのように達成できるか」という質問に対する回答と、明確な実行計画および簡潔な意見を持っている必要があります。

あなたがチームに求めるゴールに対して、製品およびチームのスキルの現状を心得ておく必要があります。新たな領域に進むのは素晴らしいことですが、チームに新しいスキルが必要になったり、既存のテクノロジーを捨て去る必要があるかもしれません。したがって、年内の達成目標に関する理想を掲げるだけではいけません。現実的に、それをどのように達成するかについて考えてください。人材の獲得には時間がかかります。新しいテクノロジーの導入も同様です。さらに、既存製品を中止するには明確なコミットメントと移行計画が必要です。

ビジネスケース？そうです。技術チームはビジネスケースに関心があります。上層部の経営陣ほどではないかもしれませんが、全体として開発チームは、あるものがそのビジネスになぜ関係しており、現実に成果が出るのかどうか、それはどのように測定されるのかに関心があります。技術チームの知識と経験を活用してください。誰もが全体としてのビジネスの成功に関心を持っているので、知識や経験から得た知恵はフィードバックまたは追加のアイデアの宝庫になる可能性があります。

また、ビジネスに対する影響が完全に明瞭で、その成果を目にすることができれば、意欲を高める大きな要因になり得ます。好結果につながることは、単に機能を作成して出荷する以上の満足感を与えます。

技術者は、誇りに思える、独自性を持った革新的な製品を作りたいと考えます。以前に聞いたことがあるようなよくある話では、やる気を失ってしまう可能性があります。しっかりと下調べをして、あなたが考えているとおり革新的な内容であることを確認してください。開発者の士気の低下は別にしても、革新的でなければビジネスに打撃を与えます。

そうは言っても、ロードマップでさえ、刺激的な新機能と技術的におもしろみのない、やらなければならない必須機能の間で常にバランスをとることになります。ありふれた作業でもロードマップで意欲を高められるように努力してみてください。

MVP (必要最小限の能力を備えた製品) を作成してから、バージョン 1 を作成する作業がありますが、ローンチ後にもあらゆることが生じます。たとえば、運用、保守、ユーザーからの機能リクエスト、継続的な改善、他製品の新しいバージョンや統合されるプラットフォームなどです。ローンチ後に課題と障害になりそうなものを素早く考えることによって、さほど労せずにこれらを明らかにできます。技術者は、こうした現実をあなたが無視しなかったことに感謝するでしょう。大ざっぱに見積もって、新機能の作成における初期の労力は、多くの場合、その存続期間全体を通して費やされる全労力のわずか 1/3 から 1/2 にすぎません。つまり、初期のビルドよりもリリース後のほうがコストがかかり、「短期で作成できる小規模なもの」は、結局は非常にコスト高になります。

見積もりは望ましいことです。指針になり、各特定の時点でプロダクトマネージャーが知っている限りのことに基づいて作成されます。しかし、見積もりのために行われた多くの想定は、実装が始まった後や、設計の改良後にかなり間違っていることが判明します。変更に柔軟に対応できるように、ロードマップを準備し、提示するようにしましょう。

ロードマップは指針を与えるためにあります。実行に向けた詳細な計画ではありません。ソフトウェアチームの全員がそのことを知っています。それ以上のものであるかのように売り込む必要はありません。あるトピックに関してまだすべての詳細を把握しているわけではないのなら、正直に話してください。把握していること、目的、未解決の問題、およびこれから取り組む必要がある最大のリスクについて共有しましょう。「何か」を見極めるために実験と追加の調査が必要な領域を示してください。そして、この実験期間について計画で説明することを忘れないようにしましょう。

チームが必要としているのは、明確な全体像を描きながら、現実を無視していないロードマップです。また、意欲を高め、刺激的で、次の 1 ～ 2 スプリントで実行すべきことをソフトウェアチーム全体が知るのに十分な詳細が記述されており、さらに、ビジネスに重大な影響を及ぼす素晴らしい結果を達成できるという自信を与えてくれるロードマップでなくてはなりません。

サポートが必要な場合は、Jira Software のロードマップ機能と Jira のプロダクト ロードマップ テンプレートをご確認ください。または、PM 向けに作られた Jira Product Discovery を無料でお試しください。