Blog
    PRODUCT MANAGEMENT

7 Best Practices For Strategic and Tactical Product Roadmaps

product roadmaps

For those thinking that a roadmap is the key to product success, I have news for you.

In his recent talk, Marty Cagan, founder of the Silicon Valley Product Group, listed roadmaps as the number one reason why product teams fail.

He pointed out that at least half of the items on a typical roadmap won’t work with customers and that even for those that do, it may take several iterations before they generate revenue. It is often because many confuse roadmaps for their organization’s vision.

As Jeff Bezos says:

“Be stubborn about your vision but flexible with the details.”

Roadmap is the detail, not the vision. Roadmap is a commitment. And once you make that commitment, you’re sort of locked to deliver, even though you know half the things are not going to work.

A roadmap is a commitment that locks you into delivering things that won’t work, like a date with a Tinder match who looks nothing like their profile picture. This becomes especially problematic in larger organizations, where multiple business owners are fighting for their share in the roadmap.

The result is often a big negotiated mess.

So, what do you do in such a situation? And where do you even begin?

How do you develop a product strategy roadmap that avoids these pitfalls?

Let’s dive in and learn how to balance direction with flexibility.

7 Best practices while drafting product roadmaps

Before we jump onto the best practices, let’s take a moment to acknowledge that roadmaps serve two critical functions that cannot be ignored:

  • Firstly, they allow management to prioritize the most valuable business items, ensuring that teams are focused on the right tasks.
  • Secondly, since companies need to make commitments based on timelines, roadmaps provide a clear way to track progress on those commitments.

Therefore, any best practices around roadmaps must be able to fulfill these requirements just as well, if not better.

Drive Continuous Discovery and Delivery with Clear OKRs

Discovery and Delivery: product roadmaps

General George Patton once said, “Don’t tell people what to do; tell them what needs to be accomplished, and you’ll be amazed at the results.”

However, traditional roadmaps do just that – they dictate a list of features or projects that someone thinks will solve a problem without necessarily understanding or articulating the problem itself. This old command-and-control model no longer works in modern product teams, where teams need context and a deep understanding of the company’s overall goals (and direction) to contribute effectively.

To provide this necessary context, tech companies can utilize two distinct components:

  • Product vision that describes the organization’s holistic view of what it aims to accomplish
  • Business objectives that describe the specific, prioritized objectives for each product team.

An effective way to manage these objectives is through the OKR system (Objectives and Key Results). This approach involves telling teams what needs to be accomplished and how results will be measured rather than telling them how to solve the problem. The “how” part is for the teams to figure out.

Prioritize Outcome Over Output

Josh Seiden, a product consultant, author, and speaker in his talk with Mind The Product discusses the importance of focusing on outcomes rather than outputs while strategizing product roadmaps..

On being asked about the definition of the outcome, Josh says:

Outcome can be defined as a change in human behavior that drives business results.

Outcomes are the desired result or impact of a product, while outputs are the features or deliverables produced by the product team. Seiden argues that too often product teams focus on delivering outputs rather than achieving outcomes, which can result in wasted effort and failed products.

“I think it’s a natural tendency,” he says.

While working on a new project, most developers usually start with the feature (output). That’s how their brains work — it’s forced habit. They think about a concrete feature and then work backward. It seems like an easier way to manage things. And even most product ecosystems reinforce this idea. Here’s a more comprehensive differentiation of both.

Outcome Over Output

Instead, Josh proposes to focus on defining the problem and the user behavior around the problem and what you can do to change this behavior to drive desired results.

Let’s say you are working on a mobile app for a fitness tracking company. You could focus on delivering outputs such as adding new features like calorie tracking, a social feed, or push notifications to remind users to exercise. While these features might seem impressive, they may not necessarily achieve the desired outcomes.

Instead, you could focus on understanding the user’s behavior and problems. You may find that users are not engaging with the app consistently because they find it difficult to track their progress. In this case, the desired outcome is to improve user engagement and increase the number of users who consistently track their fitness progress.

To achieve this outcome, you could simplify the user interface, introduce personalized workout plans, and create progress visualizations that motivate users to stay on track. These changes may not be as flashy as new features, but they can have a significant impact on business results.

Avoiding Roadmap Clutter: Embrace a More Flexible Framework

The eternal struggle of theme-based vs. time-based roadmaps is very real. It’s like the product management equivalent of the chicken and the egg. But when it comes to putting timelines on roadmaps, most product managers disagree, and it makes sense.

Time-based roadmaps are about as flexible as a brick wall.

Roisi Proven, Director of Product Altmetric, says

So I hate timelines. Time-based roadmaps are a no-no, I love theme-based roadmaps. So each quarter, we have a theme, a goal that we want to improve the product within. And then there is a lot of freedom for the team to decide what the best solution for that theme is. And yeah, we have theme-based roadmaps, one per quarter. Timelines are mean.”

Besides, time-based roadmaps are not roadmaps, they’re release plans.

Lily Smith, Chief Product Officer at BBC Maestro sums it up quite accurately:

Roadmap has your kind of themes and objectives, and goals. And then if you need to have a plan with dates on it, it’s not a roadmap, it’s a release plan.

Theme-based roadmaps let you organize product initiatives around user needs and problem areas. It gives you the flexibility to adjust priorities and initiatives as needed, ensuring strategic alignment with the overall product vision and business objectives. It also helps product teams make better data-driven decisions about which initiatives to prioritize and invest in.

Most product managers prefer the now, next, and later frameworks to decide upon what themes to prioritize and what can be done later.

Avoiding Roadmap Clutter: Embrace a More Flexible Framework

Prioritize Your Initiatives from Top to Bottom

This is pretty simple.

Consider high-level initiatives (objectives, action plans, etc.) and break them down further. Break down these initiatives into smaller, more specific goals that can be assigned to different business units within the organization. This allows each unit to focus on a specific part of the overall strategy, while still working towards the same high-level initiatives.

The “Rock Pebble and Sand” framework is a great way to prioritize initiatives and goals based on their importance and urgency.

Rock Pebble Sand Framework - product roadmaps

This framework helps ensure that resources are focused on the most important goals first, while still making progress on smaller goals over time.

You can also create local versions of the strategy map to jot down all the granular information on it. Breaking down the high-level objectives into more manageable pieces makes it easy to track and measure too. Besides, it helps to ensure that everyone is working towards the same goals.

Integrate Design-Development Feasibility From Day One

Integrate Design-Development Feasibility From Day One

Early collaboration between design and development teams can help identify potential feasibility issues and provide opportunities for creative problem-solving. This can also help to ensure that the design and development teams are aligned on the product vision and business objectives, which can help reduce friction and increase productivity during the development process.

So, keep your roadmaps accessible to as many people as possible and invite questions and feedback. Keeping a channel open for communication helps create a realistic and achievable roadmap that is more likely to result in a successful product launch.

Maggie Crowley, VP and Head of Product at Charlie Health says that she uses roadmaps to bring engineering, product, and design teams on the same page about what we’re doing, why, and in what order will we be doing things.

“Include the engineers at the earliest opportunity. They know what is technologically feasible and what the most current technologies can do to solve your customers’ problems – SO TALK TO THEM.”

Stagnant Roadmaps = Stagnant Products: Keep Them Evolving

Your roadmaps are more than just a dusty relic. Keeping it flexible and evolving keeps everything running smoothly and prevents breakdowns.

Here’s a very interesting take on the same by Cassidy Fein, Senior Director of Product at Platform:

“We do a big kind of, you know, group therapy come together session where we figure out okay, what are cross dependencies? What can these look like? How do we sort of figure this out, given our current resources, and then that kind of all gets put together into one sort of magical document that we kind of call our roadmap? But that’s really what we’re doing for now, you know, talk to me in six months.”

Therefore, it is always beneficial to put emphasis on the fluid nature of roadmaps and see it as an ongoing and reflective process that requires continuous evaluation and adaptation. By recognizing that roadmaps are not set in stone, but rather a living document, you can be more flexible and agile in achieving your outcomes.

Speak Plainly on Your Roadmaps And Avoid Jargon

Using buzzwords and jargon might seem impressive, but they don’t actually contribute anything to a strategic discussion. Goals like “leverage business opportunities to satisfy customer demand” sound smart but don’t add any value to the discussion around strategy. Use language that is familiar and easily understood by everyone, without relying on jargon, or acronyms.

Final Thoughts

Roadmaps are more about where you’re trying to go than how you’re going to get there.

It’s really about strategy on a grander level and communication and alignment. It’s all about how you’ll take things from the executive planning level, all the way down to what you will be doing next week or this afternoon level.

The description of this journey itself may change. But that’s fine as long as everyone knows where you’re trying to reach and what you’re doing about it right now.

Recommended reads

Simplifying UX Design Metrics for Product Managers

Product Management & Product Design – What’s the Difference & How Do They Work Together?

6 Pieces of Advice to Help PMs Handle Team Burnout