“What are we doing next?”
“What is actual plan?”
“Why are we doing this now?”
ロードマップの僻地に迷い込むのは簡単で、これらはすべて、営業、エンジニアリング、カスタマー サクセス、マーケティングなど、製品マネージャーとして組織の誰からも聞く可能性のある質問です。 そして、そう、イライラさせられることもあるのです。 Braden Kowitz が指摘するように、これらの質問は大きな不安を引き起こす可能性があります。
先に進むための試行錯誤された、そして真の方法の 1 つは、製品計画を伝え、組織全体をその周りに配置する、製品ロードマップを作成することです。
しかし、難題は、しばしば、製品ビジョンに沿って会社を整え、各機能が必要とする詳細レベルを提供しつつ、より高いレベルの目標に接続するロードマップを構築することです。
しばしば、企業は製品ロードマップの構築について間違った方法をとります。 また、ロードマップを一度作成したら、二度と見ないか、ほとんど更新しない企業も見受けられます。
大半のロードマップは、構築するものの背後にある理由を見逃しており、単に機能に焦点を当てているだけで、製品戦略から切り離されており、明確な目標やテーマがありません。 ロードマップは常に最新であるべきで、保存ボタンを押した時点で古くなるような一回限りの文書ではありません。 そして、単なるアウトプットではなく、組織が達成したい成果を反映したものであるべきです。
製品ロードマップの重要な要素
製品ロードマップは、独自のニーズを持つさまざまなオーディエンスを含む誰もが理解できるように、製品戦略を明確にする必要があります。 具体的な話に入る前に、何があなたにとって有効であるかは、あなたやあなたの組織にとってユニークである可能性があることを思い出してください。
私たちは、製品ロードマップへの取り組み方を見直すことが困難であることを理解しています。
私は、ロードマップは意思決定手段ではなく、コミュニケーション手段であると考えています。 A lot of folks say their goal is to have a roadmap. And I say no, our goal is to have a good product strategy where we make hard choices and prioritize the right things. The roadmap is simply a reflection of this.” “
Rich MironovProduct consultant & thought leader
Timeline
You don’t need to list specific dates on your roadmap. But you do need a way to clearly outline and prioritize short-term features, medium-term features, and features you’re planning for in the long term.
Example timelines:
- Q1, Q2, Q3
- March, April, May
- Now, Next, Later
Features
What features are you releasing along the timeline above? You can categorize these based on what you’re looking to communicate and what tools you use for project management. これらは、構築中の機能として単純に記述することもできますし、広範な機能テーマからより具体的な下位機能への階層を作成することもできます。
例 (ハイレベルから詳細まで):
- 新しいユーザーのオンボーディング、チームのコラボレーション、ビデオ メッセージング
- ユーザー登録フローの作成、チーム メンバー間のファイルの共有、ビデオ通話の録音
- SSOの実装、Dropboxの統合、保存したビデオ ファイルの共有
目標
製品および機能で達成しようとするものはなんでしょう。 仕事をするために仕事をしているのではありません。 あなたのビジネスの針を動かしているのです。 目標 (または目的) は、製品がどこに向かっているのかを組織に知らせます。
例:
- チームのコミュニケーション プラットフォームを改善する
- ダッシュボード分析を開始する
- 月間アクティブ ユーザーを 5% 増やす
正しい対象者にロードマップを合わせる重要性
異なる種類のロードマップは異なる関係者と最もうまく機能するものです。
- 上級管理者や利害関係者に製品チームの作業の 1000 フィートのビューを提供するために、リリース計画ロードマップや目標タイムラインロードマップなどのリーダーシップ ロードマップを使用します。 これらのハイレベルなロードマップは、製品の方向性の簡単な要約を提供します。 ロードマップには、市場機会や損益の詳細などの情報を含めることができ、必要に応じてさらに深く掘り下げることができます。
- リリース計画やリリースタイムラインロードマップなどの企業ロードマップを使用して、営業やカスタマーサクセスなどの部門横断的なチームとより詳細な情報を共有することができます。 これらのロードマップにより、他のチームは見込み客や顧客に適切な期待を抱かせ、コメントや適切な顧客フィードバックに貢献することができます。
- 詳細を知りたい開発チームには、カンバン、スプリント計画、または詳細なタイムラインを持つ機能タイムラインロードマップなど、配信に焦点を当てたロードマップを使用します。 目的、開発のステータス/段階、製品の領域、およびサポートが必要な他の作業について伝える。 依存関係を活用し、リスクを把握する。
- リリース計画や今・次・後のロードマップなど、顧客に焦点を当てたロードマップを使用して、顧客が最も関心を寄せる機能に焦点を絞ったロードマップをカスタマイズする。 これらのロードマップは、営業、カスタマーサクセス、マーケティングなど、顧客と接する社内のオーディエンスに、製品の次の展開を伝えるものでもあります。
効果的な製品ロードマップの 7 つの例
製品ロードマップの一般的な種類をいくつか見て、どれが最も効果的かを判断するのに役立てましょう。 高レベルで、2 つの全体的なタイプ、すなわち、列とタイムラインのロードマップを区別することができ、関連する例を説明します。
1. リリース計画
リリース計画は、行うことを決定した作業をどのように提供するか、およびその作業を完了するときの時間枠についての実行レベルの計画です。 リリース計画は、上級管理職、利害関係者、部門横断チーム、さらには顧客に対して、今後の製品リリースのハイレベルな概要を伝えるものです。 時間的な制約がないものの、一定のスコープを持つマイルストーンの計画や、定期的なリリーススケジュールによる製品の新バージョン（モバイルアプリなど）に最適です。 これにより、特定のリリース日を約束することなく、他のチームに機能が間もなくリリースされることを知らせることができます。
2.スプリント計画
スプリント計画のロードマップは配信に焦点を当て、もちろんスプリント計画にも有用です。 製品チームは、スプリント計画を使用して、開発チームが常に最新で同期した状態になるように、今後の作業内容を調整します。 複数のスプリントにわたって納品計画を立て、各機能の作業と所有者を表示して、チームの作業負荷を監視することができます。 スイムレーンを使って、コンテキストやグループ分けを追加することもできます。 スプリント計画は、必要なだけ細かく設定することができます。
3. 今・次・後のロードマップ
今・次・後のロードマップでは、近い将来に重点を置いた広い時間枠で優先事項を伝達します。 今」の枠にある機能は、作業するにつれてより詳細になり、「後」の枠にある機能は、よりハイレベルになり、長期的な戦略を反映したものになります。 リリース日が変更される可能性のある、変化の激しい環境で活動するチームに最適で、特定の期限を約束することなく、包括的な計画を顧客に伝えることができます。 Now-next later ロードマップは、製品戦略および優先順位を大勢の聴衆 (例: All-Hands または Town Hall ミーティング) と共有するのに最適です
このビューは、迅速に行動する組織には最適ですが、厳密な優先順位付けプロセスによって物事を順調に進めたいと思うことでしょう。 さもなければ、「後」にあるものがいつまでもそこに留まり、長期的な戦略に一致しないアイデアが「今」または「次」のバケツに入る危険性があります。
4。 かんばんロードマップ
The Kanban roadmap is another delivery-focused roadmap for Development team.
カンバン ロードマップの最も大きな利点の 1 つは、製品チームが、正確な日付を約束することなく、近い将来の計画を伝えることができることです。
タイムラインロードマップ
製品マネージャーは、利害関係者や部門横断的なチームとの調整を確実にするために、最もよくタイムラインロードマップを使用します。 利害関係者は主要なイニシアチブの目標と期間を視覚的に確認でき、機能横断的なチームは明確なタイムラインで立ち上げ活動を簡単に編成できます。 ただし、厳しいスケジュールを設定すると、期待値が高くなる可能性があります。 計画を広く伝えるために、最適なタイムフレームを使用することを検討してください。 これは、毎月、四半期ごと、または、あなたのニーズや利害関係者のニーズにとって最適と思われる時間のバケットであってもかまいません。 機能タイムラインロードマップ
機能タイムラインロードマップは、個々の機能の時間枠を設定することができる出力駆動型のロードマップです。 タイムラインロードマップで機能を計画し、進捗を追跡することは、作業が期限または時間制限のあるマイルストーンに向かってどのように進行しているかを 1000 フィートの視点で把握したい場合に理想的です。 特定の期限やマイルストーンに対する機能の進捗を追跡し、具体的な日付で開発チームと社内の調整を行うことができます。 また、必要なときに、必要な場所にリソースを割り当てることができます。
6. 目的のタイムライン ロードマップ
大きな組織やより複雑な環境で作業する場合、上級管理者や関係者がより拡大したアプローチを望むときがあります。 目的のタイムライン ロードマップは、アウトプット主導型ではなく、結果主導型のロードマップの例です。 このロードマップは、製品の方向性について、組織全体が一致するように作られています。
目的のタイムラインロードマップは、今後 2、3 四半期の製品戦略と目標をチーム全体で伝えるのに適しています。
ビジネス レベルの目標を使用する場合、製品とビジネス戦略、および機能などの最終成果物の間に明確な接続を提供します。
次に取り組む目標を決定するとき、時間のマイルストーン (Gartner アナリスト ブリーフィング、業界会議、マーケティングの開始、戦略パートナーや主要顧客との約束など) から逆算して計画します。
7. リリース タイムライン ロードマップ
時間軸で目標を計画しているときは、ハイレベルのままにしておくことができます。 しかし、スプリントや立ち上げ活動の準備として、どの機能をいつ一緒にリリースするかを決定したいと思うでしょう。 リリースタイムラインロードマップを使用すると、営業やカスタマーサクセスなどの部門横断的なチームに対して、近い将来いつリリースに取り組むかを計画し、明確な時間枠で伝達することができます。 利害関係者は、次のアプリのバージョン、四半期ごとのリリース、毎月のバグ修正などで何が予定されているかを確認できます。
さらに、リリース タイムライン ロードマップは、重要な締切に対する進捗を追跡するための、メンテナンスの少ない戦術的ロードマップを作成するのに便利です。 アジャイル環境で作業している場合、先に挙げた理由から、4 ～ 6 週間以上前にリリースを計画することに抵抗があるかもしれません。
目的地に到達する
製品ロードマップは成功のために不可欠です。 ロードマップなしで優れた製品を作ることは、地図なしでドライブ旅行に行くようなものです。運が良ければ最終的に目的地に着くかもしれませんが、古びたモーテルで終わる可能性が高いでしょう。 運が良ければ目的地に着くかもしれませんが、おそらく古びたモーテルに泊まることになるでしょう。また、あなたが最初に計画した旅行がどのようなものかを知らない人たちに、何度も立ち止まって道を尋ねなければならないかもしれません。 ロードトリップとは異なり、製品ロードマップは目的地がすべてであり、旅ではないのです」
。