What are outcome-based roadmaps?

Can you think of a time when you were given a long list of requirements with a ridiculous deadline?

Have you sat through countless hours of stakeholder meetings where they told you to make the button bigger?

If you answered yes to either of those questions, you might be a product designer.

For most designers in the field, the traditional non-design organizational structure can be challenging. Product decisions are made behind closed doors from an infinity pool of recycled ideas, far away from the people using the product.

Without a crystal ball to predict the future, the chance of getting product design decisions right is nearly impossible. You and your team spend hours debating the value of the feature, go through endless rounds of changes, only for the product to never see the light of day. This is usually the sad story of how requirements can kill a product—and team morale.

And it’s why we’ve implemented outcome-based roadmaps for product design and development.

What’s an outcome-based roadmap?

Traditional roadmaps follow a waterfall/Scrum-fall approach, with a list of features relying on a strict delivery timeline, often mapped a year into the future. None of which help us understand why we need particular features, or, how to prioritize one over the other.

I call this madness the storm.

This is a weather system we’re all too familiar with, where feature requirements change and scope creep is common. The designer (us) experiences whiplash from (seemingly) subjective decision making. I’ve found the best way to weather a storm is to find a storm shelter—like the outcomes-based roadmap.

At Pivotal, we use these to communicate a high-level strategy describing the outcomes we want to achieve, as opposed to outputs. The focus shifts from outputs to outcomes and protects us from the aforementioned dangers of a more traditional approach.

• Outcome: The way a thing turns out; a consequence.
• Output: The amount of something produced by a person, machine, or industry.

Outcome-based roadmaps provide:

• Visibility while enabling the team to prioritize and plan based on value
• Clarity and alignment between sponsors, stakeholders and the product team
• Autonomy and empowerment for product teams to solve problems, rather than implement solutions
• Space for user feedback in the product development process, with time allotted for learning and implementing changes

By centering the product design conversation around outcomes, we become feature-agnostic and enable our team to use their expertise to explore the solutions that solve the unique needs of users.

We optimize for learning and allow the team to use their expertise which provides a sense of purpose and leads to a better product.

How to get started with outcome-based roadmaps

Let’s go through the four foundation stages of developing outcome-based roadmaps, starting with the long-term planning (in years!) and gradually moving to short-term (weeks). It is important to note that your whole team needs to be involved in this process, along with stakeholders—but don’t worry, the process shouldn’t take longer than half a day.

Step 1. Understand the vision

The first thing you need to do when creating your outcome-based roadmap is to understand the vision. Your vision is your ultimate north star.

Use InVision Freehand to plan your outcome-based roadmaps.

For inspiration, this is Amazon’s vision:

“Our vision is to be Earth’s most customer-centric company; to build a place where people can come to find and discover anything they might want to buy online.”

In the above example, you can see that it is clear why (build a place where people can come to find and discover anything they might want to buy online) and what (be Earth’s most customer-centric company). You can think of vision as your long term plan. Something that would take decades to achieve.

Step 2. Strategy

Once we are clear about the vision, we need to figure out:

• What do we need to do to realize the vision?
• What might be some challenges that we need to overcome?
• What initiatives will allow us to solve for those challenges?

These answers are our strategy and will answer the inevitable questions about your target users and their biggest problems.

Step 3. Roadmap

Now we’re ready to create a roadmap. This is not a hard promise or release plan, but rather a high-level strategy for achievable outcomes.

For example, if you ask your team to build a ladder, they will build you a ladder. Wooden ladder, metal ladder, short, tall…but if you ask your team to reach something on the top shelf, they can explore ideas and find the best way to solve the problem at hand.

Your roadmap can include things like:

• Research-based feature ideas
• Feature improvements
• Performance and code quality improvements

Tip: you can organize your outcomes into these sections:

• Present, within the next three months
• Near future, 3-6 months
• Long-term, 6+ months

Step 4. Backlog

Next, you will need a backlog.

This is an area that most designers leave for product managers to deal with.—but without feedback from designers and the user, it’s just another list.

The magic happens when PM and design work hand-in-hand to create an action plan for moving the product forward to achieve business outcomes and satisfying customer needs.

The outcome of the outcome-based roadmap

The roadmap is guided by one of Pivotal’s core values: Do what works.

We remind client teams that change can be slow, but small steps can have a significant impact over time. To learn more about some of the other ways we approach Agile UCD to help our customers build high functioning cross-functional teams, you can download our Design Field Guide.

The guide explains the unique product design principles we’ve refined over the years to transform enterprise teams. It’s not an instruction manual; rather, our goal is to share how we think with the greater design and technology community.

Download our design guide

Feature image by Aly Blenkin.