May
18

A Case for Better Roadmaps

By on May 18, 2010

One of the most common tasks across all product management roles is to manage the product roadmap.  The roadmap has become so ubiquitous that customers and analysts have been trained to ask for it as a shortcut to understanding your commitment to a product.  A good roadmap is a useful product management tool: it informs the business, guides our tactics, and prevents us from getting distracted.  Unfortunately there are big problems with how roadmaps are built and communicated today.

RoadmapThe roadmaps I have seen (and built!) in my career fall into a few categories:

  • The Sunny-Side Up – hugely optimistic, contains the CTO’s and CEO’s wishlist for the next five years shown in the next three releases this year.  Everyone knows it has 0% chance of reality.
  • The Void – only covers the very next release, in the least amount of detail possible.
  • The Lewis & Clark – this roadmap covers the next 10 years.
  • The Houdini – items appear and disappear on this roadmap so frequently that only a select few are allowed to present it.
  • The Spinning Compass – your company doesn’t understand what it is good at or what it wants to be, so your roadmap wanders in the wilderness trying to drive a product in lieu of a company strategy.
  • The Card Deck – friend of the Houdini, the items don’t change but are constantly re-prioritized in a vain attempt at eeking out more efficiency.
  • The Zen Master – says everything while saying nothing, and contains only the highest level themes.  It can (and is) interpreted by Sales to mean anything they want.
  • The Nirvana – a clear, concise, stable roadmap that communicates the product strategy quickly and easily, and has prioritization driven by real market data.

Nirvana is hard to achieve.  In companies of all sizes, the various stakeholders in the product want to insert their own features: support wants better trouble tickets, sales wants better reporting, the architect wants to rebuild the platform, partners want an API, current customers want support for a new OS, prospective customers want Feature X.  Before you even get to requirements, a good product manager needs to balance all of these wants and make some trade-off decisions.  Some of these are very easy, and some are very difficult.  Depending on the political dynamics of your organization, it can be hard to push back on stakeholders who aren’t used to hearing “no,” even for the right reasons.  You need data on your side, and more importantly you need a structure and process to transform that data into decisions.

There are a million ways to turn the data you’ve gathered into information.  You can look at the number of requests for a given feature and weigh them against one another, or you can attempt to “carve out” percentages of your development bandwidth for bug fixes vs. new features vs. internal requests.  Measuring what you can do is tricky, because much of development is not fungible – you might have only one GUI resource but you have several backend developers.  Focusing on volume of requests risks servicing the squeaky wheels first, which trains your customer base that screaming louder gets your attention.  In short, you have two problems: filtering down a huge list of items you could work on to a manageable list, and then brutally prioritizing based on a set of criteria that works for your business.

Pragmatic MarketingAbout nine months ago, Pragmatic Marketing extended to me the opportunity to be an early adopter for a new training course they call Pragmatic Roadmapping (see disclosures below).  The course is a departure from Pragmatic Marketing’s normal in-person training classes and is offered online.  You get a PDF of the training materials and view a high-def video of Steve Johnson and Jim Foxworthy taking you through how to roadmap the Pragmatic Marketing way.  During the course, they describe a process to solve the various problems I outlined above, and get to a “Nirvana” state in your roadmap.  The training was good at explaining very clearly and with examples how to use their processes and tools to achieve your goals.  If you’ve been to a Pragmatic Marketing training it has the “feel” of a classroom session.  On the downside you only get a PDF, not a nice bound book like the in person training, and there’s no live Q&A, although you can email them.  You can also only view the video once, you can’t go back and re-watch a la YouTube.

As part of the class you learn their process for getting to what is important on your roamdap, and how to use two tools: the project evaluator and the strategy matrix.  It is hard to describe the tools without giving away the farm and drawing them for you here, but I can tell you that I put them into practice in my last planning cycle, and they work.  The project evaluator is a tool that helps you drastically cut down the number of projects that you are being asked to undertake by mapping who they are for and what they will do.  You’ll find that you can quickly eliminate two-thirds to three-quarters of the asks on your list.  After you narrow your list, you use the strategy matrix tool to prioritize what’s left based on some defensible criteria.  In the end, you can build out your roadmap into a much more usable document.  Beyond the document, you can show that your product strategy is sound and based on market-data and process-based decision making, not emotion or product de jour.

NirvanaIt’s not rocket science – in fact you probably already know in your gut what the roadmap needs to look like.  What the tools and training give you are a process and method to explain your decision making instead of saying “I think this is right” and getting ripped by your CEO who doesn’t understand why his/her pet feature didn’t make the cut.  The roadmap is really important, and it impacts everything downstream.  Before you write your first MRD you need to get a project onto the roadmap – if we can collectively raise our game in this area then we can cut out a lot of unnecessary product churn and lost opportunities by focusing on what matters.  I still recommend splitting your roadmap from your release plan, depending on the maturity of your processes and team.  Good luck, and happy roadmapping.

If you’ve got any questions about the training, feel free to email me.

Full Disclosure: Pragmatic Marketing allowed me to take their new Roadmapping class for $1 (normally $695).  I was not asked to write a blog post.  Pragmatic Marketing is a sponsor for ProductCamp Austin, an event that I organize.  I have brought Pragmatic Marketing training into several companies that I have worked for and sent many employees to their public training courses.   I consider several people who work at Pragmatic Marketing to be friends.

Comments

  1. Jeff says:

    Great post. It has amazed me over the years as I’ve moved from company to company how few organizations understand the importance of the product roadmap. Having mastery of this basic tool is a great way for a product manager to set themselves apart from the herd.

  2. Greg says:

    Hi There,
    I’m a relatively seasoned Product Manager, been following and enjoying your blog for a while now. Would love to enroll in some of these courses (like the Pragmatic Roadmapping), but unfortunately it’s not in the budget at the moment.
    Is there any chance of me getting a hook-up via begging, pleading, etc?

Leave a Reply