What goes into a good roadmap?
A roadmap needs to answer a few key questions:
What are we doing?
Why are we doing it?
When are we doing it?
A team must rally and center around a roadmap, and stay focused on the work at hand. Referring back to the roadmap, a foundational piece of work, frames a program or project. Let me break down how I address the questions above in a typical roadmap in a typical redesign and replatforming effort.
Now, the end goal of this type of work is usually, “Move us off of our old platform and on to this new one that lets us do cool things.” There are activities and dependencies that need to happen to hit that goal in the “back of house” and “front of house”. In the back of house, it’s things like deciding on a technical platform after – again, AFTER – the business goals, KPIs, and metrics are identified. It also means evaluating the teams doing the work today, ensuring we have the skills and talent and processes to operationalize our design, content, and technical work. It also means inventorying and auditing what we’ve got from a content and experience perspective. These are all very, very important answers to “what are we doing” to set us up for success… so we call them out together.
Coming out of a discovery process, I’ve typically worked with BAs and the team to identify features and functionality that a project needs. That work gets mapped out in a spreadsheet, and – yes – is the backbone of requirements.
The why, as you can see, is intertwined with the above. Before we prioritize our work, we must have research and context to drive decision-making; we want to be able to say why we’re doing something with good data and evidence. My approach on this couples qualitative research on audiences and their needs with identification of all the things we could do from a feature perspective, balanced with an assessment on how difficult each item is and what it means to the business. That drives the working team to a shared understanding of: we’re creating [this] feature, which has [this] user value, which has [that] business value, and it’s [this] hard to do.
This is often where I trot out a foursquare to show the things that are easy with high value (rare, but it happens!) and the things that are hard with low value (always shows up).
That prioritization then informs the sequencing and the actual roadmap. It’s an evaluation of the team we have to do the work, the value of the work, and getting rough estimates on dependencies and levels of effort. For instance we shouldn’t migrate content before a new taxonomy is in place – although I’ve seen the opposite happen and it is dreadful – so the taxonomy creation needs to happen first. Some dependencies like that are clear and simply required. Others are thornier and require discussion and more collaboration. It can help the whole team see what’s ahead and how much work it will be.
The roadmap, at this point, clearly identifies how much time and effort things are going to take as a clear path forward. And, the farther out we go, the murkier it will be. That’s okay; in my own experience, things get weird after 12-18 months. But – critically – we will come back to it and revise it, because the roadmap is not a thing that just goes on a wall or in a deck and is done. It needs to be actively managed.
Starting with the key questions of what we’re doing, why we’re doing it, and when we’re doing it gives a team the power to be flexible in the future.