I love ideas that seem so obvious in retrospect. The Now/Next/Later roadmap is one of those: https://www.prodpad.com/blog/how-to-build-a-product-roadmap-everyone-understands/
The traditional roadmap is a group of chevrons or bars set out in quarters one or two years into the future. It says that: In Q1 we will deliver features A and B, in Q2 features C and D etc. Something like the following:
If you can plan this far ahead then, fantastic. But many of us need to be more nimble and to adjust priorities in the face of changing needs and opportunities in the marketplace. For us, this kind of roadmap is too rigid of a way to communicate future product development plans.
Its problems stem from the way it combines prioritisation and timelines into one view. It allows different stakeholders to have very different interpretations of what done looks like for any of these future developments. And it obscures whether we need to do any work now for something that it planned for 3 quarters away.
Now/Next/Later fixes an important part of this by separating out relative priorities from timelines. At Simfoni, implementing Now/Next/Later has helped me have these sorts of conversations:
- Which of the items in now is genuinely something we should be working on now in support of company OKRs? And is everything in now really well-defined enough for us to be working on it right now?
- For the stuff that isn’t in now, which pieces should be in next and which pieces should be in later?
- What requirements/analysis/user testing do we need to do now on items that are in next and later so that we can be ready to build them when the time comes?
I even love the language of Now/Next/Later. Now clearly means something we should be working on right now. The less you have in now the more focussed you can be and the sooner you can get something properly done. Next means we need to get ready for something that we will be working on shortly, so we better firm up exactly what we need to do. And later is altogether more speculative and might need some early stage proof of concept work but it’s not something we should be spending much time discussing at the moment.
How to then apply timelines to the results of the now/next/later work is another topic. But so far I am finding that it helps to make the problem space smaller: we should be able to have pretty firm time-boxed estimates for work in now, and then things will get less precise as we move out into next and later.
All credit to Janna Bastow who invented it, see https://www.prodpad.com/blog/the-birth-of-the-modern-roadmap/ for the history.