What Does a Roadmap Look Like?

What a good roadmap looks like?

A vast majority of roadmaps miss the why behind what they are building and just focus on features — they are disconnected from the product strategy and have no clear goals or themes. Instead, excellent roadmaps should be a product of collaboration and include the input of many stakeholders and cross-functional teams

How to get started
Building a roadmap is an art. Many variables with different dependencies cause cascading impacts. However, this process can help you get started,  your roadmap can be implemented, and can positively impact your organization.

1. Build your team to create the roadmap and ensure you have the right leadership and key stakeholders involved. These generally include process owners, data owners, technology owners, and HR leadership.
2. Rank your priorities for the strategic level of the roadmap. These may be individual solutions or a group of solutions that work together. The way the priorities is different for each organization. Most find a balance of strategic alignment, ROI, and customer impact works well. However, do no overlook visibility or political needs.
3. Once your priorities are set, start the program level of the roadmap. Understand that the strategic level roadmap may need to be tweaked based upcoming work.
4. Add in quick wins based on the strategic priorities – try to make these early and often to gain momentum.
5. Layer in foundational efforts to support the priorities.
6. Add in any internal or external constraints (quiet periods such as end of year or busy season, etc.), including other systems going live.
7. Evaluate technology roadmaps to see if some of your needs will be met with (realistic) future releases.
8. Identify solutions that can be done in parallel with current constraints or if some constraints are removed.
9. Identify all dependencies and do an initial draft for sequencing.
10. Identify resource constraints from the initial draft.
    Can the resources be changed? (Internal retraining or hires and outsourcing)
    Do a buy vs. build analysis if that is an option
11. Evaluate your organization’s ability to absorb the changes from the initial draft.
    Is your organization change-resistant?
    Is it better to have incremental change or will that feel like death by a thousand cuts?
    Is it better to roll out big changes with the appropriate support?
    Are there other changes that are happening in the organization simultaneously that would be beneficial or a distraction?
12. Revise roadmap based on constraint changes and change management input
    There are times when having more than one version of the roadmap with varying investments or different timelines can be useful.
    Ensure that any changes in constraints are validated with the appropriate stakeholders
13. Document the decisions that were made when you created the roadmap so that it is easier to communicate, and if (when) changes are needed  original logic can help guide the changes, and you aren’t recreating the wheel.
14. Build out the different views of the roadmap as needed – Strategic, Program, Working, Element, and Change Management.
15. Once your draft roadmap is set, socialize it with key stakeholders and influencers.