Roadmaps – in the fast lane or stuck in a pothole?

I knew what I wanted to discuss as I started writing on the index card at the start of ProductCamp London: roadmaps – we’re all Product Managers after all, so roadmaps are what we do. Everyone has a roadmap right? Well yes, but it seemed almost too obvious or somehow banal to bring up – I mean, do dustmen talk about “how to empty bins” when they get together?

However, since moving to Just Eat my first priority has been to get my head around the roadmap and start pulling it into shape, so what better topic to choose than something that’s been at the front of my mind for a while now. Marker pen in hand, I thought about what to call my session that might generate a bit of interest: I know – “How do you create a good roadmap??” The double question marks were deliberate. In fact with hindsight I should probably have underlined the “you” just to make it doubly clear that this session would be an open forum for ideas.

I have my own opinion about what makes a good roadmap, but I wanted to spark some debate; firstly to share my own views, but also hopefully to glean one or two new pearls of wisdom from my peers. I should say first of all that I’m firmly from the Agile school of product development (and have been for many years now) so it was reassuringly pleasing to see that the vast majority of PMs in the room are also practising some form of Agile – something that wasn’t necessarily the case at the last ProductCamp back in June last year.

A product manager’s approach to product development is important in my view. Once you get into the Agile mindset then I believe it dramatically changes the way you think about a product roadmap and how to express it. Only a few years ago a roadmap in most software companies was akin to a high-level plan that listed features by major or minor release version, and dates by which the release would be “Generally Available”. Who still uses the acronym “GA” these days? I certainly haven’t heard it.

Nowadays in the Agile world a roadmap is basically a backlog of features – a prioritised wishlist really. The PM should put the features that deliver the highest return on investment at the top while those that have less of a business case should sink further down the list of priorities. Interestingly, only one person in the group of around forty product managers said he has a quantified business case for every feature on his roadmap.

Interestingly, only one person in the group of around forty product managers said he has a quantified business case for every feature on his roadmap.

More commonly, prioritisation methods tend to involve having a qualitative set of criteria against which features can be ranked or scored – for example: High for SEO benefit, Low for Increasing Conversion, Medium for Improving Customer Loyalty. A suggestion to plot the roadmap on two dimensions – time against certainty – received a warm ripple of oohs as mental notes were made to try this out back at the office.

There seemed to be a consensus view that most product managers maintain different versions of the roadmap for different groups of stakeholders. This doesn’t mean simply telling each audience whatever we think they want to hear, but rather different groups require different levels of detail. The tech team for example will need more detail than the CEO is interested in (or maybe vice-versa depending on your CEO and your tech team), while external audiences might require a more sanitised version to avoid potentially commercially sensitive information from leaking out. Despite these variations, it’s important to keep a consistent core that runs through all versions of the roadmap.

Many product managers in the group view their roadmap as a living document. Reassuringly, no-one had created a 12 month roadmap that was just stuck away in the drawer until next year. In fact, very few PMs even had a roadmap that looked a year or more into the future – implicit recognition no doubt of the lightning fast pace of change that occurs in our world of digital/ecommerce products. After all, who can honestly safely predict what the newest trend on the web will be in 12 months’ time?

Agreement is overrated

Towards the end of the session I broached the thorny subject of how to get agreement or buy-in of the roadmap. “Agreement is overrated” came the quick-witted response from Cathy Ma, which roused an immediate laugh from everyone in the room. This seemed to sum up perfectly the group’s feeling. Implicit in this throw-away line is the view that product managers need to be empowered to do what’s best for the product, and thereby the company. As product managers we sit in the crossfire between a lot of different parties in our organisations, and we are responsible for turning ideas into reality, so we’ll never please all the people all the time. There are ways of dealing with the people who shout loudest (or HiPPOs as Paul Lomax explained in a later session – Highest Paid Person’s Opinion).

It was an enlightening discussion and sadly time ran out on us, even though I’m sure many of us could have carried on talking for longer. What did I learn? Hmm, tricky one – I was certainly pleased to hear many of my own views about roadmaps reflected in the discussion. I suppose the most important thing to recognise though, is that everyone’s roadmap is unique to them and their company, and there’s definitely no one-size-fits-all approach to managing it. Ultimately, owning a roadmap means owning a product, and owning a product is a bit like having a baby: they keep growing and everyone else has a view on how to look after it. But at the end of the day the product manager is the “parent” who has to bring it into the world. That’s what keeps us ticking: seeing our products grow up and succeed.