How To Translate "Business" Impact to a Product Roadmap (and vice versa)

What is Impact?

Impact is the tangible positive effect you create on the most important goals for the company. The goals will always differ based on the company, stage, focus, product, etc. For example, a startup will have different goals than a large company.

What is Impact in the context of product management?

The definition remains the same as above. But, it is limited to the actions or outcomes directly attributable to the product team.

How can product managers create Impact?

PMs create impact by doing the things that have the highest positive effect on the most important goals for the business.

That is a good "theoretical definition." But what does it translate to in the real world? 

To create Impact, PMs need to

1. Build only those solutions that contribute to the larger goals
2. Know how to measure the impact of the solutions
3. Know how to translate and aggregate the impact of each solution into the larger product and business goals.

I break this process into four steps to make it logical and doable. But please note that these are not linear steps. Think of this more as a cycle that is ever going. And the product team is involved in multiple steps at the same time.

With that said, let's jump into the four steps.

Step 1: Create or understand the business goal

To create impact, you need to have a goal in mind. Without a goal, there is no impact. In fact, "impact" does not make sense without a goal.

So, the first step is to create a goal if it does not exist or to know the goal if it already exists.

While doing this, start at the highest level. Understand the founder's or the CEO's goal for the company. It is essential to understand that goals are set at many organisational levels. Starting with any other goal than the one the CEO cares about will reduce the quantum of your impact.

Typically, the best deliverable to capture the goals at this stage is a formal document that everyone in the organisation can read and understand. It could be a presentation, word doc, or any other form the company thinks fits.

Side note: In most companies with a good culture, the leaders create multiple forums (like all-hands, town halls, etc.) where they share not only the goals but also the thinking and approach that helped them create them. The other advantage these forums provide is the opportunity for everyone in the organisation to ask questions about the goals.

Business goals (or the goals set at the highest level) are usually for long time horizons like 2-5 years. This ensures that the teams in the organisation have a coherent direction and enough time to create and execute plans that will impact the above mentioned goals.

Side note: the 2-5 year horizon is typical of mature companies. Startups or companies that have existed for less than five years might set business goals for shorter horizons.

To put the four-step process into context, let's translate this into a real-world example. Let's assume we're going through this process from the mindset of a new food delivery app (that provides the same service as Deliveroo, DoorDash, and Zomato). 

One of their business goals could be to" Increase revenue by acquiring new customers."

Step 2: Translate business goals into product strategy and goals

Once the business goals are set and shared with the organisation, each department head should translate them into a team strategy.

Head of marketing translates into the marketing strategy. Head of sales, sales strategy. Head of product, product strategy. Head of operations, operations strategy. And so on.

It is important to note that Step 1 provides a limited universe within which the department heads should operate. They use this limited universe as guidance and ensure they do not go outside. 

Not having a limited universe has two significant disadvantages:

1. The heads of departments have a vast playing field, and it might take longer to develop effective strategies for their team.
2. They might create a strategy that is not effective -- i.e. it does not contribute significantly to the business goals.

Continuing with the above example, the heads of different teams might create goals that look like this:

1. Product: Enhance the mobile app to make ordering food easier and more enjoyable for users.
2. Marketing: Increase digital marketing spend, leading to more app downloads, user engagement, and brand awareness.
3. Sales: Onboard increased number of restaurant partners on the platform.
4. Operations: Increase the number of delivery partners to ensure on-time delivery, even at increased levels. AND Increase the efficiency of customer support teams to handle the increased number of customer queries and complaints.
   

Side note: creating a strategy for a team is neither quick nor easy. It requires the heads of teams to be very knowledgeable and aware of their areas of ownership. It also requires a deep understanding of the users or customers they interact with. Finally, it requires expertise in their department's strengths and weaknesses. All this (and much more) goes into creating a sound strategy. 

(I talk about product strategy in a lot of detail in my new course – Fundamentals of Product Management. If you want to see a real-world example of how product strategies are created, this course will be an excellent opportunity to learn. The course is available for $150, but if you're reading this, you can use the code JAPM25 for a 25% discount.)

In the case of product strategy, product leaders who are responsible for creating it are usually experts in their product areas. They understand the customers, competition, market, and industry very well. And take all of that into account while creating a sound strategy.

These leaders are also very close to the founders / CEO and, as a result, deeply understand the business goals. This enables them to translate the business strategy into a product strategy that is meaningful, accurate, and impactful.

Most product managers in medium-large companies are only involved in a limited capacity at this time. Leaders might reach out to them to understand on-the-ground realities to help create a more sound strategy.

This is where things get interesting. Most of the working group (PMs, engineers, designers) starts getting involved at this stage.

First, they all understand the larger focus areas and the product goals (laid out in step 2), so they have a concrete and well-defined starting point. 

Their ultimate goal is to identify the problems that, when solved, will have the most significant impact on the product goals.

The working group spends much time understanding the users, market, competition, and their strengths and weaknesses. They analyse data, do user research, evaluate the wins/fails from the previous year, and consult with internal and external experts. They do all this to identify the right and most important problems.

Side note: while the PM/product team owns this step, the roles of all those involved (PM, EM, designer) have significant overlaps. Everyone is working closely and playing to their strengths. Designers know the users. Engineers know the technology. The PM knows the market, competition, business, and much more. They all work closely to find the best problems to focus on because it is in all their best interests to do this right. If they fail at this step, they end up solving the wrong or low-impact problems. In either case, they're not creating the maximum possible impact they can.

Then, the product manager sequences the problems in order of impact. The problems that will create the largest impact should be on the top of the list and should be solved first. 

And that – the list of sequenced problems – becomes the roadmap for the year (or any cadence that the team chooses to use) (Here is a detailed guide on how to create and prioritise a roadmap)

It is also at this time that the product manager ensures that:

1. The impact of each problem in the list is measurable. PMs should think of metrics that would help them accurately measure the impact.
2. Solving the selected problems will actually contribute to the goals set in Step 2 (and hence create impact)
3. Everyone, including the leaders, has reviewed and agreed to the final list.

Now, let's get back to our example. These are some problems the team might think of based on their comprehensive and holistic understanding of goals, users, market, competition, and strengths and weaknesses.

• Problem 1: Users find it difficult to discover new restaurants and dishes they might like. xx% new users don't even get to a menu page
• Problem 2: many users do not understand the checkout process well, and xx% abandon their orders.
• Problem 3: Users are frustrated with inaccurate delivery estimates. xx% users have complained about the same

In the real world, this list of solutions will be much longer and will have some indication of when to focus on which problem. For example: Focus on #2 in Q1, #1 in Q2, and so on.

Step 4: Design and deliver the solution

This step is drastically different from all of the previous steps. Now is when the teams transition from planning to doing.

This step consists of two distinct phases: Solution Design and Solution Delivery.

Solution Design:

The working group gets together to brainstorm ideas to solve the agreed-upon problems. Then the PM prioritises the solutions based on high impact and low cost-to-build. Once prioritised, the working group details the solution to the extent possible. They could do this in many ways –  PRDs (product requirement documents), user stories, product designs, wireframes, and technical specifications.

In addition to the solution design, the PMs create clear success criteria for each solution. These are usually a list of metrics that help everyone confidently say whether the proposed solution worked or not.

While the PM is thinking about these metrics, she should ensure that these metrics do the following:

1. Are closely related to the "impact' metrics from step 3
2. Accurately and confidently measure the impact of the solution
3. Translate the impact to the larger goals from Step 2

Going back to our example:

• Solution to Problem 1: Implement a "Discover" section with personalised recommendations based on user preferences and past orders.
• Solution to Problem 2: Streamline the checkout process by allowing users to save payment information and offering one-click ordering.
• Solution to Problem 3: Integrate real-time GPS tracking for orders, providing users with accurate delivery estimates and updates.

Solutions Delivery

Once the detailed solution design is available, the teams start working on delivery. 

Delivery in this context refers to multiple steps:

1. Reviewing and agreeing on the requirements/solution design
2. Estimating the required bandwidth and time to build the solution
3. Creating acceptance criteria to decide if the solution does the intended job
4. Testing
5. Launching

At this stage, the goal is twofold:

1. Deliver the solution as per the agreed design
2. Deliver the solution as per the quality and timeliness standards agreed upon in the acceptance criteria
   

Side note: In this stage, the roles of the working group are much more precise than in the previous step, and there is less overlap in the responsibilities of all involved.

That concludes the entire process of going top-down and translating somewhat vague and open-ended business goals (increase revenue) into concrete solutions ("discover" section, improved checkout, real-time tracking)

Now, the only thing that needs to be done is to pass the correct information bottom-up so the leaders can objectively know the impact you created via the solutions.

To understand that, let's continue with our example, but this time we will start the process bottom-up, i.e., think of solutions first and then see how they relate to the business problem set during Step 1.

For simplicity, I will focus on the solution to problem 3

Solution: 

Integrate real-time GPS tracking for orders, providing users with accurate delivery estimates and updates.

Success metrics and criteria

• Metric: total no. of complaints about inaccurate delivery times
• Success criteria: reduce no. of complaints by xx%

Translation to Business Goals

Now, let us assume that the solution was a success. 

As a result, we saw the intended decrease of xx% in the no. of complaints. 

But let's remind ourselves the business goal is: "Increase revenue by acquiring new customers." 

A decrease in complaints is NOT the same thing as an "increase in revenue from new users."

This is where the product manager should translate her product metrics (no. of complaints) to the business metric (revenue from new customers)

There are a few things I would think of while doing this translation:

1. Decreased no. of complaints should make the customers happy, which should make them place more orders in the short and long term
2. Decreased no. of complaints should increase the effectiveness and efficiency of the customer support (CS) team, enabling them to handle more complaints and handle them better.

(These are just two examples. There could be many more)

As a next step, I'd create some math to make the above two points objective. I could look at older data and compare new users who had a complaint on their first order vs. those who had no and calculate each set's total revenue.

Similarly, I could estimate the number of orders the CS team can help complete with the extra time.

I would then sum these two numbers and use that number to relay the impact that new feature creates on the larger business goal.

Side note: PMs are, very often, in situations where the product metrics they use to measure the success of their solutions are not the same as the business metrics that leaders think about. The PMs should create basic mathematics (like the example above) to translate product metrics to business impact. It is important to note that this math does not need to be 100% accurate. It can be loose. As long as it is logical and agreeable to others, it works. (Here is another example of converting product metrics to business metrics)

That is it for this post. If you have questions, don't hesitate to write to me on sid@justanotherpm.com. If you want to learn more about creating impact and see how I do it in the real world, check out the Fundamentals of Product Management course.