I’ve built lots of product roadmaps. It’s not hard to build one, really. You start with a sense of where you want to go—mind you, visioning’s no small thing—and then you work backward. You keep asking, “Okay, what do we need to do, what do we need to have in place, before we can do this?” And you do that over and over again, working your way backwards until you get to where you are right now, right this minute. What you end up with is a logically unspooling progression of events and systems and business practices that together lead inexorably where you determined you wanted to go at the beginning of the process.
Simple, right? Of course it is. And that’s why product roadmaps have a tendency to go terribly wrong. Some of mine sure have.
What basic roadmapping doesn’t tend to consider is, what happens when something changes? Like, maybe the marketplace? Maybe a competitor has launched a new, disruptive product? Lots of roadmaps have milestones to check our progress against our goals, but too few have checkpoints to gather the kind of feedback that can ensure that assumptions we made at the beginning of our plan remain valid, that our KRIs and KPIs still make sense.
But let’s assume we’ve been cleverer than that, and we do have those checkpoints. We’re agile! We regularly review our priorities so we don’t get caught out unawares by changes in the marketplace. Go, us! Still, while we’re paddling like ducks and mindfully following our boxes and arrows to their conclusions, our stakeholders may be getting nervous. I mean, this is a long road, right? Sure, progress is steady… we’re demoing our work every sprint. But what do we really have to show for it? What have we done for our customer, lately?
A very clever roadmap, then, needs not only to consider the possibility of marketplace disruption and shifting priorities, but it also needs to assure every step in the product plan creates value—practical, visible, shippable, in your stakeholders’ faces and elevating the customer experience sort of value.
And that, my friends, is not so simple. It is, in fact, a completely different way of thinking and doing. It’s nothing less than the difference between having an agile software development team, and having an agile organization.