🗺️ Roadmapping - Part 6: Development roadmap
Development roadmaps get more granular about the construction timelines of the work that needs to be done. This is the how of your why.
Welcome to the second last post in our roadmapping series. Previously, we discussed the prioritization and planning processes, milestones, outcome-based roadmaps, and now, next, later roadmaps. Even after all of this, there is still much to discuss about road mapping; this is a topic we could discuss for many more months!
What is a development roadmap?
So, what is a development roadmap, and how does it differ from all these other roadmaps? You've developed the high-level roadmap regarding what you're working on and why; now it's time to dig into this quarter and plan all the development work that needs to happen. If you compare this to a Now, Next, Later roadmap, the Now column is your development roadmap.
Who is this roadmap for?
Unlike the other styles of roadmaps, the development roadmap is meant for the development team and teams working on the work. Development roadmaps get more granular about the construction timelines of the work that needs to be done. This is the how of your why.
How to build a development roadmap
There are many different ways to build a development roadmap, and depending on your team, much of this responsibility might fall on your engineering manager and engineering leads in combination with Product Management. This should not be your engineering team's first time seeing these goals and outcomes. Be sure to make it a collaborative process and seek input along the way, or you won’t be on good terms with your engineering teams when it comes to this step, and you’ll need to rely heavily on them to plan out and complete this work.
Development roadmaps or plans often include Infrastructure work, UX/UI, Feature development, Internal improvements, Integration, Security compliance, Data migrations and DevOps work. You name it. Anything your teams are working on can make it into this roadmap.
Timeline
Compared to your overall strategic roadmap, development roadmaps typically have shorter timelines. They might look ahead a month or two, and if you're using scrum, it would normally be indicated by sprints.
Do you need a development roadmap?
I think this is one of those things you can't really go without. Even if you don't intentionally build one, it will exist in some form, even if it's only focused on a concise timeframe, like a single sprint. At some point, even if you're working by yourself, you need to know details about what you're working on right now.
Other things to consider:
Keep this roadmap internal to your team: A lot is going on in this roadmap, and it will only be of value with a ton of extra context. Anyone without that context may misinterpret it as a release plan. It may also contain proprietary information.
This is not a release plan: Just because the development roadmap says the features will be ready at the end of the next sprint, this shouldn't be equated with a released feature.
Add as much detail as needed: Remember this roadmap's goal and who it's for. This roadmap can communicate priorities, dependencies, and goals to development team members.
Where should this roadmap live?: This could live in JIRA, ProductBoard, or some other tool. Having a roadmapping tool that can sync to a task-managing tool like JIRA is very helpful for keeping things up to date and communicating changes with stakeholders.
Audience: The intended audience for your development roadmap typically consists of the engineering team, design, QA, product operations, other internal product teams (for coordination purposes), dev ops, and IT.
Keeping it organized: Many teams find assigning epics and tasks to teams and owners very helpful. An Epic owner on the development team can help ensure things stay on track and that outcomes are met.
Frequency of updates: The development roadmap is monitored and updated more frequently than other roadmaps. This is the plan your development teams are working from, so as things change, it will need to be adjusted and referred to often, especially if housed in JIRA, as the work continues to be broken down and worked on.
Clear goals and outcomes: Like all other roadmaps, the development roadmap should have clear goals and outcomes. It should be understood why everything is on the development roadmap, and these items need to align with the overall quarterly plan and longer-term strategy.
To learn more about roadmaps, check out the rest of this roadmapping series.
Roadmapping Series
Part 1: A living document
Roadmaps aren’t intended to remain static. We’ll explore some ways to help keep your roadmap fluid and up-to-date as things change.
Part 2: Prioritization and planning process
How do you decide what gets put on your roadmap?
Part 3: Milestones
When should you add Milestones to your roadmap? What constitutes a milestone?
Part 4: Outcome-based roadmaps
This type of roadmap focuses on outcomes over features or solutions.
Part 5: Now, Next Later
Avoid concrete timeframes and focus on priorities.
Part 6: Development Roadmap - 👈
The roadmap you build for your dev team differs significantly from what you would create for your stakeholders and customers.
Part 7: Layering your roadmaps
How layering shows different levels of detail within your roadmap for various stakeholders and taking a simple approach to maintaining them.
Let me know if there's anything else about roadmaps you want to see expanded on, and I'll develop this series more if there's enough interest.