Why your roadmap might be strangling your product

Product roadmaps generally intended to give investors, stakeholders, suppliers and customers a sense of when features are intended to be delivered. It’s useful to have a sense of when things might land, so you can coordinate activities. At least, that’s the theory. But in practice, roadmaps very often cause misdirection and inhibit the ability of your team to make something truly valuable.

Predicting the moment a team of people will deliver a particular set of features is somewhere between very difficult and impossible. A few things to consider are the maturity of the team, how well they understand the needs of their users, the complexity of the domain and the usability of the existing code, among many other things.

As a team moves through the forming, storming and norming stages of group dynamics, you might eventually become highly productive, you hit your stride and your delivery patterns become increasingly predictable. I’ve worked in teams that have got to this stage and it’s a beautiful thing. But the vast majority of teams don’t get there. Or at least, they get there just as the funding runs out.

When you’re starting up, you’re going to have a lot of disruption on a team, new people working together, getting to know the product, differences of approach etc and to make predictions without at least 6–12 months of data means you might as well just generate random numbers for your estimates.

Despite the difficulty of predicting feature delivery, estimates are still used to create product roadmaps. Of course, roadmaps are supposed to be flexible. You can even get yourself a nice tool like aha.io to visualise the road ahead. Stakeholders, investors, suppliers and customers can all see clearly when something’s going to be finished so some other service can start, a launch can happen or someone can get their bonus because they’ve delivered when they said they’d deliver something. Other parts of the organisation can know when to expect something to be delivered. Visual roadmaps are great for making you feel powerful, you can move a block and within that one blocks are a hundred hours of cognitive load.

Once the roadmap’s in place and things are organised around it, it becomes increasingly difficult to change. Product teams get baked into a solution based on far-from-perfect information and assumptions. Then eventually, the roadmap is the deadline, rather than it moving along when new facts come to light.

Usually, roadmaps are put together by someone not actually working directly on the product itself, but hovering around the product in some way, documenting and cajoling, recording and reporting. Someone like a product owner or product manager. (Have you ever seen a designer or developer willingly make a roadmap?).

A roadmap becomes like a hymn sheet for the whole choir to sing from. Except, a couple of people still have the hymsheet from Q1 and a few people are on Q2 while the rest are on Q3. “You can see it in realtime on your tablet! Why have you printed it out?”, “Okay, what’s the wifi password?”, and still there’s a couple of people still using the PDFs from last year. Plus every time there’s a change, everyone needs to go back and change their mental model of the future. Nobody likes to do that because they’d they have to go through the thought whole process again. So the roadmap doesn’t change, because it’s just too much work to change, it’s just easier to leave it as it is.

At it’s core, a roadmap is a kind of promise of the future. But it’s got no real grounding in reality. When you start to put lots of numbers against the features and stack them up, it starts to look like proper statistical data, like crime rates, interest rates or population figures. Except they’re not, they are still just a pile of guesses.

Roadmaps give us a sense of security about the future, about what’s going to happen and when. But they shouldn’t, because they can’t. Modern organisations should be ready to change at any moment, but roadmaps make that super-difficult.

So what’s the alternative?

The alternative to having a roadmap is to not have a roadmap. Ditch the roadmaps and learn to love uncertainty. Uncertainty means you’re ready to switch path at any moment.

It’s not just you as an organisation that has to be okay with uncertainty, it’s investors and customers, distributors and agents. I’m not saying this is easy for established companies, but if you’re a new and young company, you don’t have to set those expectations.

Let go, kitty. Let’s stop trying to find solace in complex planning artefacts that are built on dodgy assumptions. Galvanize around a vision and how that vision is going to fulfil real customer needs and address real problems you’ve seen with your own eyes. Just don’t be explicit about exactly how that’s going to happen. Paint a fuzzy, faint but exciting, shared vision of what should be, just don’t be too specific about how and when it might happen.

Don’t make promises that can’t be kept, make the feature a reality and only then announce it. Schedule regular events to announce what’s being worked on and what’s the future vision. Make the current work-in-progress visible and work hard to make sure your customers needs are being met and do that in a focused way.

All these things sound good in principle, but it’s not easy to do it in practice. How might it be possible to create an organisation that avoids promising new features within a certain timeframe, and instead ships when ready? At Harley Davidson they have a thing called pull events. They happen about every 6 months. At these events, product teams put on a show for regional dealers to take a look at what’s coming up. It’s not only a chance for dealers to get an inside track on what’s in the pipeline, but for them to actually effect the product itself and get excited about the future. Dealers essentially ‘pull’ on products by simply getting enthusiastic about them. Product teams don’t push out products and components on an arbitrary chronological basis because of what’s been promised. The products are pulled because they are ready to go and they’re wanted.

Investors, stakeholders, customers and suppliers like to know when things are going to happen, of course. But instead of making promises based on when things are going to be pushed in the future, let stakeholders pull what they want when they want it and build the organisation around that.

Clearly this is a cultural, systematic, all-encompassing change for some organisations. But if your organisation isn’t embracing uncertainly like this, a small, better organisation will.

Roadmaps aren’t there to keep you competitive or keep the product quality as high as possible, they exist so people can be blamed, held to account and execs can feel they have a sense of control.