The Art of the Strategic Product Roadmap

Personally I don’t like how linear this diagram is. I prefer to visualize design thinking as an extension of Lean:


Joe Van Os

3 years ago | 7 min read

Products live within markets that are constantly changing, making planning a difficult process. Something happens that the plan didn’t account for and we are suddenly fighting to survive.

I believe this constant change is the reason that people have become frustrated with roadmaps, and in some cases have even went so far as to declare the roadmap dead. But as they say: fail to plan, plan to fail.

For many product people, the roadmap is their first taste of business strategy. There are a few common blunders that rookie product managers fall victim to:

  1. The development backlog is not the roadmap. The roadmap is a visualization of the strategic product plan, which in turn drives the development backlog. Think of it this way, the roadmap is the ‘why’ and the ‘what’, the development backlog is the ‘how’.
  2. When people mistake the development backlog for the roadmap, development goals become internally focused. Focus shifts away from the user problems, and towards the technical aspects of building the solutions. How technically sound a feature is means nothing if the feature isn’t being used. Products are built for the user, not for us.
  3. Validation becomes an internal process that results from new features passing automated tests. External customer validation becomes an afterthought, resulting in features that don’t meet the customers needs. We’re left wondering why such a cool feature isn’t being used. Unless users are a part of the validation process, It’s impossible to know if functionality is valuable.

These problems stem from the roadmap being internally focused, driven by the product team’s beliefs. However value is created through solving the problems of customers.

A solid product strategy understands that the best way to maximize value and minimize risk is to focus externally, and stay as close to the customer as possible.

Solving Problems Creates Value

Great product teams understand value is created when a product is able to fix the problems of the user. However, in order for the product team to build a solution, they must first understand the problems the user is facing.

By focusing on the end user, the product will naturally become value driven. This allows the product team to understand the user’s largest pain points, and recognize when new problems arise.

Remain Focused

A good strategic plan creates focus for the product. It outlines specifically which market problems the product is designed to solve. Straying from the core focus of the product is typically a recipe for failure. A recent poll of Venture Capitalists listed lack of focus as the number one reason for startup failure.

Focus creates product depth, and product depth always trumps product width. A deep product may solve limited problems, but it does an excellent job at solving those problems.

Shallow products do a poor job at “solving” a number of problems, and are often filled with gaps and workarounds.

Each product has the same amount of features, but the deep product addresses more problems.
Each product has the same amount of features, but the deep product addresses more problems.

A strategic roadmap creates focus around the problems the product will solve, along with the high level goals for getting there. This in turn creates a clear vision and set of priorities, and allows teams to tie their work back into reaching these goals.

Without a strategic roadmap, teams can be working on something that adds zero value for the customer or the product, and not even realize it.

Relentlessly prioritize, find what’s important, say no to everything else.

Picking the Right Problems to Solve

Choosing which problems the product should solve requires a thorough understanding of the market and the user base. The best way to gain this understanding is through meeting with current or potential users.

For new products this is finding the product-market fit. This idea can be extended into mature products through the idea of feature-market fit. Product-market fit defines the problems that the product should solve, feature-market fit defines the depth the feature needs to be able to solve the problem.

Design thinking is a great framework for defining the problems that the end users are currently facing, which in turn uncovers value.

Design thinking is often portrayed with the following flow:

Personally I don’t like how linear this diagram is. I prefer to visualize design thinking as an extension of Lean:

Design thinking takes a customer-centric approach by focusing on the ‘measure’ component first. By starting the iterative loop with the customer, the most important market problems (ie. value) can be surfaced. Design thinking is also great for managing risk as it provides multiple levels of user validation. Each level of validation reduces the risk of building the wrong thing.

Step 1: Define the Problems

Fixing user problems creates value. It is best to validate problems through user feedback by starting the iterative loop with the measure (customer feedback) phase. This results in validated goals prior to development beginning, along with limiting the risk of problems being skewed by the team’s personal biases.

Talk to users, find out which problems cause them the most pain. The more pain that a product can eliminate, the more valuable the user will find it. Working with customers to define problems, and in turn value, is the first level of user validation.

Step 2: Determine The Risks

Once problems are uncovered, they need to be prioritized in order of importance. The level of importance defined by the value it would deliver to the user, along with the risk involved with solving that problem.

Risk will be highly dependent on the product, their market, and their financial situation. A good starting point is by considering the following:

  • Feasibility — Like it or not, we all have a budget. Is the problem that you are looking to solve going to cost you a lot of money? Do you have that money? Would that money be better spent elsewhere?
  • Opportunity Costs — If the team is working on one feature, they won’t be able to work on other features.
  • Pivot in Strategy – A new goal, or an overall strategy pivot is high risk.
  • Product-Market or Feature-Market Fit — Are people going to use what is being built? If there is revenue goals attached, can you be sure that people will pay for the new feature?

These are the tough questions that need to be asked by the product team when vetting new goals or features.

Step 3: Solutions and Prototypes

Solutions to problems should be determined as close as possible to development, as the best solution to a problem may change over time.

Finding solutions to the customers problems should be an inclusive team activity as it allows for different perspectives to be brought into the picture. More perspectives further reduces the chance of a bias influencing the proposed solution.

Once the team decides on the best solutions, prototypes are created and tested with users as a second layer of user validation. Abstract ideas can be hard for users to grasp, prototypes show a more concrete version of the proposed solutions.

Fidelity (detail) level of the prototype is based on risk. Solutions with a high level of risk require better prototypes and more thorough testing. Solutions with a low level of risk require basic prototypes and minimal testing.

Prototypes are meant to be discardable. They are built specifically to be tested, so it is important to build the minimal version of the solution required to be effective during customer tests as this limits wasted time.

Step 4: Build Your Roadmap

Once the value and risk of each problem is evaluated, they can be prioritized based on the return on investment. Problems should be placed into one of the four categories below.

At this point the level of value should be defined through the customer feedback initiatives. The bigger the problem is for the customer, the higher the value is. Risk is determined by the feasibility, which is the overall cost.

Guidelines for how to handle the problem categories:

  • High-value / low risk: Add to the roadmap, this is low hanging fruit.
  • High-value / high-risk: items should be considered for the roadmap based on the appetite for risk. These items should be limited, as the more risk that is taken on, the higher chance of failure.
  • Low Value / low risk: These problems aren’t important. They will be the items that are constantly pushed back to later sprints. Leave them in consideration, but off the roadmap.
  • Low Value / high risk: Scrap it. These items lead you down rabbit holes, and often lead to a product plan being derailed.

When it comes to creating the roadmap itself, there are a few items to consider:

  • Keep roadmap items high level. Development requirements are meant for the development backlog, and they should be defined in a just-in-time fashion.
  • A baseline for determining when the problem is solved should be defined. What does the user need to adequately solve their problem? Functionality that falls above this baseline is a need to have, below the line functionality is a nice to have.
  • Focus on the core feature set. Don’t add additional feature sets (solve other large problems) until the core feature set reaches the baseline.
My prototype for a roadmap template
My prototype for a roadmap template

Just-In-Time Requirements

Once goals are ready to move from the roadmap to the development backlog, requirements are ready to be scoped. By scoping the development requirements as close as possible to the actual development, you can ensure that the development requirements match what the market is currently demanding.

Since the goals and features were properly validated during the roadmap process, the product and development team can work together to start building the requirements needed to solve the defined problems. If there happens to be additional user experience questions, keep the focus external, and get back on the phone with users.

Review, Rinse, and Repeat

The great part of using design thinking is that it often validates goals without a single piece of code being written. This means that everything the development team works on is valuable. It also adds an additional levels of validation that standard Lean does not have, keeping the product as close to the customer as possible.


Created by

Joe Van Os

Constantly discovering what it means to be a Product Manager, and passing on what I learn along the way.







Related Articles