• 20 heures
  • Moyenne

Ce cours est visible gratuitement en ligne.

course.header.alt.is_video

course.header.alt.is_certifying

J'ai tout compris !

Mis à jour le 07/04/2020

Roadmap Element 2: Broad Timeframes

Broad Timeframes

As mentioned previously, every product manager should have two documents: a project plan and a roadmap. The goal of the project plan is to outlines dates, dependencies, and resources for the upcoming releases. The goal of the roadmap is to broadly show the current, short-term, and long-term priorities.

Because a roadmap often communicates the product strategy over a long term, this means that it often discusses product changes that might not be worked on for 12 or even 18 months. Such product improvements may be a key part of the product strategy.

However, changes in the business, competitive landscape or an understanding of what will satisfy customers may mean changing course. The product manager could indicate that he has some long-term goals in mind, but fast-forward twelve months the plan may have changed.

Drift CEO David Cancel explains this dilemma nicely (imagine he is talking to a customer or internal stakeholder):

Either I’m going to disappoint you by giving you exactly what we thought six months ahead of time was the best solution when it’s not, or by changing course and having lied to you.

The solution to this dilemma is two-fold:

  1. Rather than talking about features (specific solutions) in the roadmap, instead, focus on themes (areas of problem/opportunity) in the roadmap. For example, rather than mention a feature like "Email customers who abandon their shopping cart," you could mention a theme like "Reduce shopping cart abandon rate." You don't mention exactly how you might reduce this number, but you indicate that you will focus on the problem area.

  2. Rather than mention delivery dates, use broad timeframes. Instead of indicating a hard release date for a feature, divide the areas of focus into time frames such as Right Now / Near Future / Long-Term Future. In this way, the product manager is not pressured by promises to customers and internal stakeholders. Rather, she can deliver the best value within the relative timeframes as the team adapts and changes.

Examples of Broad Timeframes

ProdPad

ProdPad is a roadmapping software program for product managers. They use the following broad timeframes:

  1. Current

  2. Near Term

  3. Future

Broad Timeframes in the ProdPad roadmap
Broad Timeframes in the ProdPad roadmap

Twitter (Developer Roadmap)

Twitter uses the following broad timeframes in its public developer roadmap:

  1. Recently Hatched

  2. Incubating

  3. Nesting

This creative use of terminology in the timeframe labels indicates that everything is not written in stone.

Twitter
Broad Timeframes in the Twitter developer roadmap

Invision

Invision is a company that makes design and prototyping software.

They adopt an approach similar to ProdPad's, using the following labels:

  1. Current 

  2. Near Term

  3. Future

Broad Timeframes in the InVision roadmap
Broad timeframes in the InVision roadmap

GitHub

GitHub is a development platform that allows software developers to have common code repositories and to collaborate on software projects. GitHub's development roadmap uses the following labels as broad timefames:

  1. Near Term

  2. Medium Term

  3. Long Term

GitHub's broad timeframes
Broad timeframes in the Github roadmap

In each of the examples above, these four companies use broad timeframes with no specific dates mentioned. Yet it is possible to know what is next, what is after that, and what is in the future! Stakeholders in the organization can quickly see from the roadmap where the team currently has its energy focused, where it will soon have its energy focused, and where will be focused in the future!

Quarterly Roadmaps

Some product teams use quarterly roadmaps. A quarter is defined as a three-month period, so there are four quarters in a year: Q1 is from January to March, Q2 is from April to June, etc.

Using quarterly timelines can be more restrictive than broad timelines. If you commit to delivering a certain theme or feature in Q1, there may be an upset customer or stakeholder if that commitment is broken. For this reason, I advocate against using a quarterly timeframe for customer-facing (i.e., public) roadmaps.

If you are going to use a quarterly roadmap, consider including a disclaimer that indicates that the dates are not commitments.

A Quarterly Roadamp
A quarterly roadmap

Summary

Roadmaps work best when optimized for learning. When solving certain problems, the team will learn more about that problem along the way.  Therefore, it is better to share the broad timeframe of when you intend to tackle certain areas rather than specific deadlines.

The project plan is a document that communicates the future features and delivery dates of deliverables that are certain and committed. However, the roadmap communicates the product strategy and uses broad timeframes.

Additional Links

In the next chapter, we will look at how roadmaps are constructed using themes within each broad timeframe. Themes can be thought of as broad areas of customer need and are ideal ways to indicate future areas of focus.

Exemple de certificat de réussite
Exemple de certificat de réussite