Focus your roadmaps on outcomes, not outputs
![Focus your roadmaps on outcomes, not outputs](https://www.productboard.com/wp-content/uploads/2020/04/roadmap-cover-1.png)
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.