Roadmaps – in the fast lane or stuck in a pothole? "Product people - Product managers, product designers, UX designers, UX researchers, Business analysts, developers, makers & entrepreneurs 10 July 2012 True Agile, Paul Pechey, Product Roadmap, Mind the Product Mind the Product Ltd 1033 Product Management 4.132
· 5 minute read

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.

Comments 3

I think it’s important to see the roadmap as part of a whole – in order of increasing granularity you have the Product Vision. the Roadmap, and then your Backlog.

The vision is fluffy and shiny but provides an important direction for the business and more importantly defines where you’re not going. It acts as a litmus test for ideas that should only be developed into roadmap items if they fit the vision.

The roadmap is a high level, and constantly fluctuating, view of all the major themes you need to work on. At this level I do require a business case for each – but my business cases are pretty light touch and are focused on deriving relative priorities. Eg it is more important to know if feature A is going to deliver more new users than feature B than exactly how many users it will deliver. This relative prioritisation saves you from the onerous business case hell that can be full cost benefit analysis.

Finally a roadmap theme or project is broken down into epics and stories – these don’t need business cases per se but are prioritised on an ROI basis against the agreed goals of the theme/project (which are what got it on the roadmap in the first place).

But that’s just how I do it… And having said that I would like to see how a roadmap mapped against an uncertainty axis would look.

I agree that roadmap items frequently appear with little reason to back them up. This also highlights the problem with HiPPO’s. They usually want features based on their personal opinions or reasons and don’t always take the big picture into account. I think it’s important for us as product managers to require more concrete business reasons before adding an item to the roadmap. (or at least present some resistance)

Paul and the London ProductCamp crew – I wish I could have been there to join the discussion. This is a subject on which I’ve given a great deal of thought over the past several years because I noticed that everyone “rolls their own” when it comes to creating roadmaps and this seemed inefficient.

So I decided to polish up the process I’ve used successfully for the past few years and form a company around it. But I’m going to document and give away the process for free because I want people to use it. I’m just getting started but I would love feedback from any of you.

Moreover, you are spot on when it comes to the issue of uncertainty. That is the key to successful execution IMO.

I recently wrote a post on this exact issue – http://roadmapintegrity.com/2011/03/05/the-secret-sauce-managing-uncertainty-and-execution-risk/. Again, would love to get any comments.

Join the community

Sign up for free to share your thoughts

About the author