Roadmapping

This material has been crafted with care by me, Suzanne Abate, Product Coach and Host of the 100 PM Podcast, and my longtime friend and closest collaborator Andrew “The Tech Guy” Bodis, Co-Founder and Head of Technology Services at TDF.

Before diving in, we invite you to connect with us on LinkedIn so that you can make this experience more interactive and more personal. Please say hi and let us know what you’re hoping to get out of these lessons.

Connect with Suzanne

Connect with Andrew

The era of separating traditional industries from the technology industry is over.

Our competitors, employees, and – most importantly – our customers are all using sophisticated software every day and demanding higher and higher quality user experiences.

This leads today’s businesses to a single, urgent objective:

We must not only adopt (and continuously adopt) innovative software and technology internally, we must transform (and continuously transform) the way we design, build and deliver technology solutions to our customers in order to meet the ever-changing expectations of today’s markets.

If your business sells or licenses software as a primary source of revenue, or relies on third party software or custom solutions to automate and optimize business workflows, it’s critical for leadership to understand and adopt effective product planning and delivery processes.

Product planning activities are directly informed by business strategy and goals, and provide direction for which work should be prioritized, why that work is needed, and some high-level details on how the work should be delivered.

The essential product planning activities we’ll cover in this series are:

Roadmapping
Feature Briefs
Release Plans

Delivery processes are the tools and procedures used by engineers, designers, and product managers in order to effectively and efficiently execute planned product work.

The essential delivery processes we’ll cover in this series are:

Epics & User Stories
Sprint Planning & Backlog Reviews
Code Base Management and Deployments

These lessons provide practical steps for getting started and best practices for implementation, developed from over twelve years of providing technology training and coaching for businesses who want to deliver better.

If you’d like to learn more about how TDF got started and how we’ve evolved through the years, check out our transformation story.

Getting Started with Product Planning

It’s dangerous to assume that assembling a team of engineers, designers, and product managers, however expert, will result in that team knowing exactly what to build or what to build next.

That’s because the technology products they’re building, whether customer-facing or internal, are in service to the business mission, and the mission is a descendent of the big vision.

Teams look to leaders to establish and champion the vision and values of the company, and to regularly communicate the business goals that inform which work should be prioritized, why that work is needed, and high-level details on how the work should be delivered.

Product planning activities rely that your business or product vision is established and well understood internally. If you’re not quite there, that’s the absolute best place to start.

There are three essential, recurrent product planning activities that continuously support your company’s vision:

Roadmapping – setting the vision and direction for how your product will develop over time
Feature Briefs – relating product and feature specifications to strategic objectives
Release Plans – using story maps to collaboratively plan whole products and features

In this lesson and the next two that follow, we’ll dive into the purpose of each product planning activity and how they inform each other, as well as provide specific steps for leading these activities with your own teams.

Lesson 1: Roadmapping

Why do we need a product roadmap?

A good product roadmap is a polestar for product teams. It keeps everyone connected to the vision and longer-term objectives, and helps prevent individual contributors from getting lost in the day-to-day and disconnecting from what matters most.

When talking about roadmapping we’re actually talking about two things:

The process of deciding what should go onto the roadmap and in what order, and
The roadmap itself (what the document should look like, what information should be included, and how it should be accessed)

The Product Roadmapping Process

While the roadmapping process is typically led by department or business leaders, a roadmap dictated by leadership is a bad roadmap.

Good roadmaps are informed by data and prioritized by leadership.

The steps in the product roadmapping process are:

Collect inputs
Establish objectives (or themes)
Link outcomes to objectives
Identify and prioritize projects

1. Collecting Inputs

The roadmapping process starts by collecting inputs from various sources.

Customer, shareholder, and employee feedback are all inputs, but so are competition, market trends, and key performance metrics such as revenue (is it up or is it down?), retention (are people using your product or service? how happy or frustrated are they?), and referral (is customer satisfaction enabling organic, low-cost growth opportunities?).

Information is coming at us constantly, and as we gather it, it forms the foundation for our plan of action, which is what the roadmap really is.

Winning organizations treat input collection as an always-on operation, leveraging multiple channels from Slack, to satisfaction surveys, to behavioral data analysis.

The inputs that inform your current roadmap are those inputs that have been collected since the last roadmapping “session.”

A note on roadmap iteration frequency:

Different organizations iterate on their product roadmap at different intervals. Some teams might update their roadmap quarterly or every couple of weeks. Early-stage startups experimenting their way to product-market fit typically don’t even roadmap beyond six months into the future.

By contrast, enterprise organizations, robotics, and automative manufacturers may be working with five or seven year-long roadmaps.

Whatever the frequency, however adaptive the team, the contents of a roadmap are highly subject to change, but the process remains relatively constant.

2. Establishing Objectives

Objectives are broad, ambitious goals that motivate contributors and inform meaningful discussions about what kinds of projects or product releases might actually realize those goals.

Objectives may be set at the company level, at the department-level, or even for specific products and features.

Establishing a few clear objectives may seem like a hard task with so many sources of input, but in reality, certain patterns or themes tend to emerge quite clearly from the analysis of the inputs you’ve collected.

We think objectives should be stated succinctly (short) and actionably (using verbs), so that they are easy to remember and imply the desired outcome.

Try this:

Think of some of the things you want to accomplish with your business, department, or team next year. Write down a sentence for each goal.

Now edit each sentence down to a verb that communicates the desired action, and the noun that best describes what you want to act on.

Example: “Increase” + “Revenue” = Increase Revenue

Externally-focused objectives drive outbound efforts. Some examples are “get funding!” or “keep employees!” or “grow referrals!”

Internally-focused themes drive operational behaviors. Some examples are “better production!” or, perhaps, “cheaper production!” or (our favorite) “improved process!”

Whereas the vision is highly unlikely to change from year to year, or even at all (if it’s big enough), objectives (or else the outcomes you’ve linked to those objectives) should change quarterly or annually.

3. Linking Outcomes to Objectives

Objectives form the bedrock of your roadmap, but on their own fall short in providing a measure of whether or not the objective was met.

Let us illustrate the problem using our example from above. How will we know when we’ve met our objective of increasing revenue? If we make just one more dollar than the year before? What about one million more dollars? Can we establish a quantifiable or qualifiable “finish line” that everyone can see?

This is where the OKR framework (developed by Andy Grove at Intel and popularized by his pupil, John Doerr, in the book Measure What Matters) can help.

OKR stands for Objectives + Key Results.

OKR is a syntax for goal setting that anchors broad, ambitious goals (objectives) to specific measurable outcomes (key results).

Here are some simple OKR examples to illustrate the concept:

Objective: Widen the appeal of the product!
Key Result: Increase new registrations by 10%

Objective: Create a best-in-class experience for our vendor partners!
Key Result: 50% adoption rate for online vendor orders

Objective: Become a better product manager!
Key Result: Attend 3 product management workshops in Q4

Try this:

Pick one of the objectives you created in the previous exercise.

Consider what specific result would satisfy that objective. For now, don’t worry about how that result will get measured, just write it down so it’s objectively clear.

Example: Increase Revenue by 10% from Previous Year

The guiding principle of OKRs is to prioritize outcomes (the creation of measurable business or customer value) over outputs (activities people do, stuff that gets built), and to make goal setting transparent and multilateral.

Linking outcomes to objectives also creates a useful frame for identifying the right projects to work on, which leads us to the last step in the roadmapping process.

4. Identifying and Prioritizing Projects

A roadmap is a bunch of leadership-approved projects, planned over a given period, informed by data, and oriented toward desired outcomes.

The ideas for projects can, and should, come from anywhere within the organization. This is another benefit of OKRs: they communicate what needs to be accomplished (in terms of measurable goals), but they give room for contributors to identify how to best accomplish those goals in terms of projects or initiatives and the specific details thereof.

How you choose to invite your teams into the process of identifying projects to work on is entirely up to you, but since most organizations don’t suffer from too few planned initiatives, what’s critical is establishing a process for prioritizing projects and further eliminating low impact ideas.

There are plenty of prioritization methods you can explore such as now-next-later, impact/effort matrix, or weighted scoring. Keep in mind that methods for prioritizing roadmap initiatives are different from methods that better serve project-level prioritization, such as Kano model, buy a feature, and MoSCoW.

In our opinion, it doesn’t really matter which framework you use for prioritization, so long as the decision-making process is transparent. What we’ve observed from working with dozens of teams through the years is that morale is as easily deflated by black box decision-making as it is by dictatorial rule, and good roadmaps are only as good as their buy-in.

Backlogs are not Roadmaps

Some organizations think they have a product roadmap but what they actually have is a product backlog (sometimes called an “opportunity backlog”).

A backlog is a list of feature ideas and experiments that are typically generated by product teams weekly, if not daily. While a backlog can inform roadmap planning (an input), it should not be confused with a roadmap, which is intentionally forward-looking and, as we’ve discussed, guided by themes and desired outcomes.

This is not to say that backlog items are not outcomes-driven (that will depend largely on how well your team understands and applies best practices for writing user stories, which we’ll cover in lesson four of this series), but it is to highlight that the decision to prioritize (i.e. invest in) backlog items is best made in the context of a broader goal setting or planning ritual such as roadmapping.

Presenting your Product Roadmap

Roadmaps are visual expressions of the projects you’ve prioritized.

One common failure of roadmapping is hyper-emphasis on creating the roadmap document rather than carefully adhering to the steps of the roadmap process we’ve outlined above.

Another common failure of roadmapping is storing the document away from where most people in the organization can actually see it.

So when it comes to documenting or presenting your product roadmap, make sure the following conditions are true:

Our roadmap is easily shareable
Our roadmap is easily edited
Our goals are communicated
Our timelines are approximate

As change is inevitable, removing obstacles to changing your roadmap by embracing cloud-based tools that make your roadmap easy to share, update, and access anywhere (like ProductPlan, Aha!, or Trello) is best practice. If you prefer “a good old Powerpoint,” use Microsoft 365 or Google Slides for the same reasons. As we’ll cover when we discuss code base management in lesson six, version control is a process unto itself and there’s no need to further complicate roadmapping with versioning.

The roadmap is also the worst possible data source from which to make time-specific commitments like, “Yes, go ahead and put in that media buy on September 5th,” or “Yes, go ahead and take out that loan in January,” or “Yes, go ahead and hire that whole new developer team in the first week of Q3.”

That’s because when we’re in the process of roadmapping, we’re at the furthest point from certainty—usually out in front of project details by several weeks or even by several months. For that reason, we want to keep timelines approximate.

Regardless of format, resist the temptation to use roadmaps for guaranteeing dates and deliverables, and instead use them to communicate direction.

—

Keep an eye on your inbox next week for Lesson 2: Feature Briefs

Not yet registered for this course? Sign up here

Want to learn more about Product Roadmapping? Watch Suzanne’s 60-minute class