Focus your roadmaps on outcomes, not outputs

Written by Bruce McCarthy, author, speaker, founder at Product Culture, for our ebook, The Path to Product Excellence: Stories and Advice From the Field.

Product roadmaps have gotten a bad rap. Most of them deserve it.

Ask someone what a product roadmap is and 9 out of 10 times you’ll hear it’s a list of features and dates. And while many roadmaps do include this info, I think this answer misses the real point of having a roadmap. As my co-authors and I discuss in our recent book, Product Roadmaps Relaunched, a good roadmap is a strategic communications tool, a statement of intent and direction, and, done well, a way of rallying the whole organization around the key problems that must be solved to achieve your product vision.

A good roadmap is a strategic communications tool, a statement of intent and direction, and, done well, a way of rallying the whole organization around the key problems that must be solved to achieve your product vision.

Anthony Accardi, CTO of Rue Gilt Groupe, an online flash sale e-commerce platform, said it well: “An effective roadmap retains that context of ‘Here’s why we made these decisions, and here are the assumptions we’re making.’” And yet, most roadmaps leave all of that out in favor of minute details about features, bug fixes, schedules, and dependencies.

This style of roadmap is a legacy of the days of lengthy waterfall projects. In fact, the invention of the technology roadmap is usually credited to Motorola’s semiconductor unit in the 1980s. In today’s businesses, however, the pace of innovation has accelerated dramatically, and Gantt charts (invented in the 1890s) live about as long as a mayfly.

Features are outputs. They are the specific changes your team is making to your product or service in hopes that things will improve for your customers and your business. Improvement is the outcome derived from those outputs.

Outcomes are the driving reasons why you have a roadmap at all, so why not explain from the start what these desired outcomes are?

Outcomes are the driving reasons why you have a roadmap at all, so why not explain from the start what these desired outcomes are?

Let’s say you are thinking of revamping the screens that appear the first time a new user logs into your app. You could put “Redesign new user experience” on your roadmap, but why might you be working on that? Well, maybe you’ve gotten feedback that the landing page is confusing. And maybe you’ve discovered that 60% of first-time users never come back. So the real reason you are thinking of this project is to improve the odds you will retain these customers.

Now ask yourself, what if your redesign doesn’t work? What if the new screens are even more confusing? Or what if the greater obstacle to returning customers turns out to be related to login credentials, project creation, or pricing? Should you just ship your redesign, hope for the best, and move on? Of course not.

As an industry, we’ve learned to test our assumptions, to put something out there, measure usage, and tweak or pivot as necessary. And yet our roadmaps don’t reflect this lean approach to business. Most roadmaps assume we know what we will ship and when—and that it will work right the first time.

A better approach is to describe the customer or business problem we are trying to solve—the outcome—and leave the details of the features, functions, and fixes we plan to test—the outputs—to JIRA and Trello. Then you might add something to your roadmap like “Increase repeat usage by 20%.”

Contactually, a SaaS-based intelligent CRM for real estate professionals, created this roadmap focused entirely on the business outcomes they sought. And as you can see, the details on features and functions are kept quite minimal, even vague at times.

And Contactually is not alone. Elli Rego, Product Manager at Wodify, a gym management SaaS software platform, says “We accept that we don’t know which specific features we’re going to build, and we give the teams the freedom [to figure it out].”

The benefits of this approach are many. Making the desired outcomes clear frees your team to consider alternative solutions that may reach your objectives faster and easier, sometimes with no feature work at all. At Localytics, a mobile engagement platform company, they discovered that improved documentation was the fastest way to ensure more reliable onboarding of customers, so they scrapped more involved plans for redesigning their SDK.

Focusing on the “why” in your roadmap instead of the “what” communicates more clearly where you are headed, and what success looks like. It also means your roadmap changes less often. People complain about “roadmap churn,” but customer and business problems don’t actually change that much or that quickly. An outcome roadmap is more stable over time with only the tactics employed to reach those outcomes shifting as different approaches are tested.

Focusing on the “why” in your roadmap instead of the “what” communicates more clearly where you are headed, and what success looks like. It also means your roadmap changes less often.

If, like many, you’ve been tempted to abandon roadmapping as old-fashioned, consider a roadmap of outcomes as a way to communicate your product vision and the problems you think worth solving. This will help you gain buy-in and leverage the creative problem-solving energies of your team far better than a list of feature promises you likely can’t keep.

. . .

This post is an excerpt from our ebook, The Path to Product Excellence: Stories and Advice From the Field. Get your copy now for more valuable insights from product management thought leaders.