A good product roadmap is not just a Gantt chart that shows when a particular feature is going to be released.
Roadmaps serve a number of important purposes:
- They enable the planning of the engineering delivery process on a more granular level, including capacity planning
- They provide predictability to the rest of the company, in particular sales and marketing ("When can we promote and sell X?"), customer success ("From when on do we need to support X?") and finance ("When can we expect revenue from X?").
- Roadmaps provide insights into dependencies inside engineering, but also in relationship to other departments and even external partners
Roadmap planning horizons
Strategic priorities
This level has a time horizon of 2-3 years. It covers major deliverables, such as an entirely new product family.
For early-stage startups that focus on one single product, this level refers to the primary functionality clusters that you want to deliver in this planning horizon.
Initiatives
Product initiatives typically have a time horizon of about one year. They describe major chunks of functionality that should be delivered within this horizon.
It is important to identify dependencies between different initiatives early. If initiative B can't start before initiative A is delivered, this has to be planned for.
Initiatives should be planned based on their business value (how much do they contribute towards solving the customer problem and/or generating revenue for the startup?) as well as expected effort.
Example:
Quarterly Goals
Planning specific high-level deliverables on a quarterly basis about one year in advance is useful to align the organization towards specific outputs.
It is important to communicate to everybody in the company (and outside parties such as the board of directors or key customers) that the planning gets more probabilistic the further out it is in time. For example, the roadmap items for the immediate next quarter should have a high degree of certainty, while the items four quarters out are assumptions based on today's information and will likely change.
Example:
Sprint Planning
Typical sprint lengths of 2-3 weeks are still best practice in the industry. The engineering team should be fully in charge of shaping these sprints and deciding which outputs they can deliver to move the product forward to the overall goal.
Who should do the planning?
- The overall plan should be owned by the VP of Product, Chief Product Officer or similar function
- The owner should solicit frequent input from the rest of the organization to shape this plan towards the need of the business.
- Product management plays a key role in breaking out high-level goals into more detailed chunks.
- Engineering should be involved early on in the planning process to provide feedback on effort and feasibility and also provide input on technically required work packages (such as reducing technical debt or building out infrastructure).