Roadmap development #2

Submitted by Nicolabell on Thu, 03/07/2019 - 08:50

How to build a roadmap


I watched to help form a plan for building a roadmap.


This video answered one of the questions I’ve been struggling with, which is that for an Agile project, is a roadmap a sensible thing to build? During the Agile process things can change drastically, so it seems like looking so far in to the future is going against the Agile methodology. The answer is that it is good to have this long term product development plan despite the fact that during Agile working it could change, because it keeps everyone clear about the goals and strategy of the overall project, without setting things in stone. It may well change but having that clarity and focus from the start to bring the whole team together is absolutely essential.


I was also getting confused about the differences between a roadmap and a project plan, which I feel I have more clarity now. A roadmap should include milestones as new functionality or meaningful releases rather than detail - this breakdown of tasks goes in your backlog or project plan. The main aim of the roadmap is to align the team and facilitate coordination by allowing them to plan their own work around it. It should clearly articulate the business goals and strategy to deliver them.


No one product roadmap template works for all as they’re all going to be vastly different.




Add your milestones against release date or duration of the time developers will work on it. You will have to estimate the time it will take for this work but even though you can’t be absolutely certain about the timescales it will nevertheless help coordination among your teams /stakeholders anyway. Here’s a simple example of how to display this:


Area of work















Milestone Time Estimation


If you’re working in a team you will need to get everyone to work together to make estimation of how long each piece of work or sprint will take. You might find that some milestones can be lumped together in one sprint, or larger pieces of work might need breaking down into several smaller tasks. Make sure you’ve got the objective documented alongside it.


Prioritise these milestones - you might have several high priority milestones being worked on simultaneously by different teams, but in my case there is just one of me for my main project so the roadmap will look more waterfall like and sequential.

Proof of concept


At what point should you turn your project idea into a roadmap? The answer to this is when you know enough about your market and customers and that they’re active and engaged enough for putting your plan in to practice to not be built on assumptions. If you or a member of your team are still hypothisising about the goal and outcome of the project, you still need to be testing a bunch of development projects until those hypothese have been validated. Don’t start writing the roadmap until you have real data rather than assumption!


This is why it is a good idea to add a proof of concept to the roadmap to evidence that the concept is feasible; this could be findings from a pilot project or from ‘direct quantitative research’ (speaking directly to a number of your customer base until you can satisfactorily predict how others in that target audience are going to respond to certain questions about your product/their needs etc).


It is also good to know your customers inside out in order to be able to speak with confidence about them and know their needs / the problems that you could address with your project. Get to know them well.


There needs to be a rationale behind everything included in the roadmap - if you can’t give one, it shouldn’t be in there in the first place. If something is included purely on an intuition, it’s not


Your roadmap needs to be / include:


  1. Good product strategy
  2. Realistic
  3. Fully supported by you teams and clients/stakeholders


If one of these isn’t present’ it’s not likely to succeed. One of the main if not the aim of a project roadmap it so make sure everyone is onboard with it and feel that they own the project.


Also make sure it communicates:

  • What the project goals are
  • Who the customers are and their needs
  • What features are in existence already if any
  • What the competing products in the market are
  • Prioritised milestones with a rationale behind them


Rough draft / approval


Do a rough draft of the roadmap so that you can get everyone on board and aligned with it before it becomes a working document. You should meet with your teams working on the project and review their capacity (inCluding work outside of milestones like bug fixing/ testing), their alignment with the product strategy and what they feel should be different. It is a good idea to get any modifications made there and then so everyone is on board with them. If there isn’t a conclusion at the end of the meeting, reschedule and keep going until everyone is onboard with the plan.


Once everyone is happy with it, if you need to communicate it to a wider team you could create a presentation including:

  • Key elements and decisions
  • Roadmap objectives
  • Target audience
  • Competitive advantages.
  • Some slides about the rationale behind which parts of project focused on first


Other ideas for role out are:

Very short but inclusive meeting to go through it, with a Q&A at the end.




When there are changes due to budget, time, actions by a competitor etc, make sure to let everyone in the team know so that they feel they own those changes too. Make sure the status of the document is clear - if it’s still a draft, or has been amended significantly half way through the process, it should be really obvious!


Summary / steps:

  1. Write summary of proof of concept  and rationale behind strategy
  2. Outline timescales
  3. Outline and prioritise milestones
  4. Estimate duration and release dates of milestones. Break down large tasks in to smaller ones.
  5. Draft document
  6. Make sure all stakeholders are aligned with it / amend if not
  7. Make sure any updates are communicated and the status of the document is clear.


Idiot check:

  • Is this plan realistic?
  • Does it communicate the goals and rationale behind them?
  • Is everyone onboard?


Next - Building my project roadmap!