How to build an agile product roadmap
The roadmap is an essential part of a product manager’s toolbox. It shows the company the road ahead, it shows my manager whether I’m building the right thing and it shows other teams potential dependencies. The better a roadmap is defined, the clearer things are for everyone.
But how can a roadmap both plan for the future and stay agile? How do we compromise between business needs and the ability to build, test, iterate and stay lean?
What is a roadmap?
“A plan for the future, usually with a particular goal.”
The Oxford Learner’s Dictionary
At its simplest, a product roadmap is a chronological list of what you’re going to build next, with individual features listed in varying levels of detail. It looks similar to a Gantt chart, though in practice it is a much more flexible document, with fewer details.
So, the roadmap is a visualisation tool. Simple enough. The tricky part is working out how to define, prioritise and build the features that you’ve listed, which is why a roadmap cannot exist by itself. Three things are needed to build one: scope, complexity and priority.
How do you define a roadmap?
Scope
Defining scope is the core of a PMs job. User testing, user interviews, analytics, research, business vision and other tools help you to define the problem, explore solutions and back up your decision with data. If there is no measurable business or customer value, a good manager will rightly kill your feature. Good PMs and good managers don’t chase shiny, complex features, they focus on where the value lies.
The most common approach is to build an MVP and then follow up with further releases. However, never build an MVP that doesn’t provide value on its own. If priorities change you can be left with a product that doesn’t bring any value to the business or its customers.
Complexity
Estimating complexity is notoriously tricky. I learned very early in my career not to make promises based on my own assumptions. Ask your engineers: they are the technical specialists, they know best. Your job is to give them as much context as possible so that they can understand the problem, advise on the solution and define the architecture. They will often find use cases that you never considered.
Next up is sizing. It’s safe to assume that the bigger a project is, the more surprises you will receive. The complexity of user stories is estimated using the Fibonacci sequence because risk does not grow in parallel with size. The same method can be used to estimate project complexity, though the following factors should be taken into account:
- The project’s complexity
- The team’s knowledge of the codebase
- Technical debt
- Distractions
A good approach is to split the MVP into smaller pieces, estimate the size of each piece with engineers and repeat as necessary. Adding a margin of error to the total estimate will give you an idea of timeframe.
Priority
If you have scoped the project and estimated complexity properly, priority should be easy to decide. Ideally you will build the features that offer the highest business and customer value for the lowest effort first. But what happens when a high value feature is highly complex and has to be prioritised against a simple, easily-built lower value feature? Quick win or big win?
One method is to calculate the cost of delaying release, which works well to compare features that solve different problems. This technique can be used to evaluate a feature that decreases churn versus a feature that increases acquisition. If you have enough resources, you could also run two queues of work in parallel: one for large features and one for small. That way you can put, for instance, 20% of the team’s effort into small features or technical debt.
Regardless of how you tackle prioritisation, you have to do your homework. Don’t prioritise anything without scope and complexity.
… and here’s how you make it agile
So, you’ve done the hard work. You have your scope, complexity and priority. Surely now you just have to draw the roadmap and get on with it? Not really, no. If a roadmap is just a visualisation tool, it must adapt to the data, research and circumstances that it visualises. New features appear, customer desires change, technical debt is fixed and architecture is updated. Scope and complexity also change as projects progress. To be agile, your roadmap must evolve with your business and the needs of your customers.
But why do we even need a roadmap? Why spend so much time and effort on something that keeps changing? The answer is simple: because nobody wants to read a 30-page waterfall document, and 30-page documents are hard to update with the new research, testing results, hypotheses, scope, metrics etc. that your build-test-iterate model will bring.
A roadmap should be rigid enough to show a plan but flexible enough to respond to new developments. You don’t have to waste time going into detail for features that are months away, but you should be more precise about features that are coming soon. Offer just enough precision for each step of the journey.
Finally, remind your team and the business that the roadmap will change over time. It’s just a tool to visualise your work and communicate your plans. The roadmap is definitely a living document.
Towards financial services available to all
We’re working throughout the company to create faster, cheaper, and more available financial services all over the world, and here are some of the techniques that we’re utilizing. There’s still a long way ahead of us, and if you’d like to be part of that journey, check out our careers page.
