TLDR:  In this post, I suggest a different approach to the popular feature driven roadmap by introducing the value driven roadmap concept.

• Stop confusing your customers with a feature driven product roadmap. 
• User value focus is correlated with higher NPS and revenue growth.
• Value driven planning puts problems before features.
• A Value driven roadmap promotes a creator-driven culture.

Intro

A product roadmap is a visual representation of the product plan to accomplish the product/company vision. The vision is usually broken down into a detailed work plan with time based milestones of the upcoming 3-4 quarters, which by definition contradicts the main principles of being “agile”, since we don’t really know yet what will be innovated in the future.  Rather than sharing the feature timeline roadmap,  I suggest a different approach.  In this post, I suggest using a value driven roadmap.

Feature Driven Roadmap

Many product roadmaps today display features that are planned to be released in the future. If you google the term “product roadmap” you will find examples of roadmaps displaying a timeline of features. Among the features you may find names of planned features such as “3rd party integrations”, “Security 2.0”, Android app, etc.

When looking at a feature roadmap, several problems come into mind:

1. The names of features do not communicate the business value to the stakeholders.
2. We do not really know what will be developed two quarters from today. Features planned months ago may not be relevant in the future (e.g integrations with a startups that have been shut down).
3. Customers and sales may look at the release dates as a commitment rather than a high level plan.

To avoid all of these problematic aspects, I would like to introduce a different approach to roadmap planning called value driven roadmap.

 

Value Driven Roadmap

A Value Driven roadmap focuses on the value that a product is planned to provide in the future without any obligation to specific features.

As can be seen in the roadmap picture above, the theme of the version/release is around the business value provided.

In addition to the roadmap itself, the backlog should also be value driven. Each value element represents a scoring criteria with a value from 0-10.  The effort estimation is a fibonacci series based on the planning poker concept and the score is calculated as the total of all value elements minus the effort.

At this point, we’ll break down what value elements mean, and how exactly to estimate how much value a feature will provide.

 

User value focus is correlated with higher NPS and revenue growth

 

While the term “value” is quite vague, it can be broken down in a way that is easier to communicate to stakeholders and customers.  One way of breaking down “value” is described in an article posted on the the Harvard Business Review – “ The 30 Things Customers Really Value”.  

The article presents the findings of a research study on the relation between value elements and company performance.  The research included a survey of more than 10,000 U.S. consumers about their perceptions of nearly 50 U.S.-based companies. In their research, the team identified 30 “elements of value”— what they describe as: “fundamental attributes in their most essential and discrete forms.” These elements fall into four categories: functional, emotional, life changing, and social impact.

The research looked at the relationships among the different customer value rankings and each company’s Net Promoter Score (NPS)—a widely used metric for customer loyalty and advocacy—and the company’s recent revenue growth.

The findings from the research were:

1. The companies that performed well on multiple elements of value would have more loyal customers than the rest. Companies with high scores on four or more value elements from at least 50% of respondents had, on average, three times the NPS of companies with just one high score, and 20 times the NPS of companies with none.
2. Companies who scored high on four or more elements had recent revenue growth four times greater than that of companies with only one high score.

Although correlation is not causality, and one can argue the root cause for the success of the company, the article does provide a useful framework for breaking down user value into specific value elements. Planning your roadmap with a “Value 1st approach” helps communicating a clearer value proposition aligned with the product roadmap.

Value driven planning puts problems before features

 

When planning the product roadmap, there are too many unknowns in regards to the actual solutions that will be developed to solve a business problem. The solution may change due to increased competition, new technology, available resources, compliance and etc. While different solutions may vary significantly, the problems the customer faces are more stable and do not change overnight.

A good example from the B2B Saas industry is the problem of privacy. When working with enterprise customers, the expectation is to have a robust privacy solution for managing documents permissions.  As a product team, we might decide to address the problem of document privacy in the near future, but the solution might not be decided yet, due to the many ways to tackle privacy (could be organisation level setting, user setting, group policy and etc).

The product team should communicate to the different stakeholders that the issue of privacy and specifically document privacy will be addressed, but the solution has not been decided yet. That gives the development team flexibility and room for creativity when coming to solve the problem.

Some even argue that product roadmaps are counter effective if not used carefully. David Cancel, CEO of Drift and previous CPO of Hubspot wrote in his blog about roadmaps:

“Let’s say as part of a public roadmap we commit to creating a certain app or feature. Once stated, the completion of that app becomes the end-goal. The sales team previews it. The business readies for it. But then in talking with customers and testing, let’s say we discover that the app doesn’t solve the problem at all. “

I believe that as long as the roadmap is around features and not around business value, there is a higher likelihood for conflict and miscommunication with stakeholders.

Value driven roadmaps promote a creator-driven culture

 

In a feature driven culture, where Product managers provide a high level design of a feature , developers might feel like implementers rather than creators. In order to harness creativity, companies need to shift the focus to the problem and not the solution. When putting the problem before the product or the solution, a creator-driven culture can take place.

In a recent article on First Round Review  – The Rewards of Creator-Driven Cultures — And The Engineers That Can Deliver Them, Lou Montulli – Founder & CTO of JetInsight and one of the first engineers at Netscape, argues that software companies should “distribute the problem, not the product.”

To promote a culture of creation, developers should be encouraged to create rather than implement for the sake of both the product and themselves.

“The key is to start developers off with a part of the problem that the product addresses and not a part of the solution that will solve it. A leader of a creator-driven culture will continuously remind her engineers of the problem and bring them back to it over and over.”

Inviting the developers to participate in solving the problem rather than working in mini-waterfall sprints where the PM defines scope and breaks it down for developers, gives the developers more space for creativity.

Summary

The concept of  a Value driven roadmap is not new, it is just not as popular as the traditional features roadmap. Feature driven roadmaps are more prone to conflicts around commitments (“You said it’s coming in Q4!”) and business value (“What’s the business value of the feature?”). Transforming to value driven roadmaps is correlated to higher NPS and revenue growth and provides more space for creativity among the R&D teams who can focus on a problem rather than implementing a solution.

I’d be more than happy to hear what you think, and which practices work best in your company.

 

Related Posts: How to Build a Visionary Product Roadmap