Regardless of your company structure, goal-setting strategy, or philosophical stance, at some point, the work you do on your product needs to map back to revenue. The question is, as a product manager, how exactly do you map product revenue to the roadmap? How do you project and measure results based on that mapping? And should the results change depending on who you are talking with?

In this post, I’ll break down the basics of how to tie your roadmap back to revenue. I’ll also give some examples of what that might look like in the real world.

Before we begin, here are a few terms I’ll be using and a quick definition:

Revenue: Represented as MRR or ARR of r SaaS businesses

OKR: Objectives and Key Results

Roadmap: Visual representation of your product strategy

Roadmap View: A filtered view of your roadmap intended for a specific audience

Tying the Product Roadmap to Revenue

At their core, most prioritization frameworks present the pros and cons of working on a certain project. Sometimes, the “pros” directly tie to projected revenue. For example, you might use a Weighted Scoring model (benefit vs cost) where a benefit is the amount of annual recurring revenue you expect the initiative to generate. Other times, your prioritization framework will be one level removed from revenue. Instead, it might measure a feature’s impact on customer delight, for example, or account growth.

As a product manager, it’s important to make the connection between the work your team is doing on the product roadmap and business revenue. But you also know that not everything maps back perfectly.

Two Real-World Examples

Your company has revenue goals. You might also have company-wide (or possibly department-wide OKRs. You should definitely have a product roadmap, and if you’re using ProductPlan, you’ll have individual views for different audiences. And, since your product roadmap shouldn’t be empty, you’ll probably have different initiatives or features that you’re working on or planning to work on.

Not every roadmap initiative will have an immediate measurable impact on revenue, but the purpose of this structure is to connect the dots to the best of your ability.

Example 1 (a simple situation):

Your team is working on releasing a new checkout experience for your online store. You know the percent of users that drop-off during the checkout process, and you have a goal set for increasing the number of users who successfully complete their transaction. Moreover, since you also have historical data on the volume, you can extrapolate the estimated impact on revenue.

Let’s say your current checkout experience drives $1 million ARR, with an 80% completion rate. You expect your new checkout experience will increase the completion rate to 90% (a 12.5% lift), which should deliver an additional $125k in MRR to the business.

Example 2 (the real world):

Let’s say you are a SaaS roadmapping tool (like ProductPlan) and are working on a feature that allows users to create and use custom colors across their roadmap. You know this is will be a valuable feature to your users because you’ve seen the feedback from the NPS survey, you’ve talked with customers, you might have even received from feedback from trialers who didn’t buy because you didn’t have this functionality. However, you’re not sure how to quantify the impact of this feature. This concern is where OKRs come in.

If you’ve set product-wide OKRs (such as improve NPS score from 40 to 50 or reduce monthly revenue churn by 25%), all of the work that your product team is doing should roll up into one of these OKRs.

Let’s look at the example above. You had an OKR of, “increase the conversion rate for trial signups by 20%” and your team felt confident that the new custom colors feature would have a significant impact on that goal. With this information, you could extrapolate the value of that feature (pre-release) and measure the impact of that feature (post-release).

Tailor Your Tale

Depending on your company and team structure, the “revenue pressure” can come from many different directions. In the majority of cases, however, the executive team is the group of stakeholders most interested in how your product roadmap ties back to revenue.

It is important, therefore, to tailor your message depending on your audience. In a presentation to the executive team, you’ll want to bake revenue directly into the roadmap. One option to do this is to make sure it’s clear exactly how every initiative that is on your roadmap is measured and how it rolls up into your greater goal-setting framework.

At ProductPlan, the growth team that I lead has two main objectives. At the end of the day, every initiative on our roadmap should influence those two objectives. But every initiative includes a sub-goal and an estimation of the impact we expect it to have on our main objectives. This gives our executive team an easy way to understand the expected impact of everything our team is working on. It also, frankly, makes it much easier for me to justify the investment we are making.

Keep in mind that some audiences will care much less about the revenue impact of roadmap items. Creating a custom view of your roadmaps and hiding the details about revenue can be helpful when sharing your roadmap with certain audiences, such as Engineering or Design.

Takeaways: Crawl, Walk, Run

Tying your product roadmap back to revenue sounds easy in practice. It’s easy to talk about this theoretically, but much harder to put it to work in practice.

Many of the product teams I’ve spoken with have been successful in rolling out a goal-setting framework iteratively. Start with making sure your team is aligned around main KPIs that influence revenue. Then, start to tangibly estimate impact for every item that makes it on your roadmap. The more you build out the framework and understand how each initiative maps to your KPIs, the more confident you will feel tying your roadmap back to actual revenue.

Ready to feel confident tying your roadmap back to revenue?