Our #1 KPI in Product Management
Read on my website / Read time: 10 minutes
Thank you to our sponsors who keep this newsletter free for the reader:
Give Yourself The Information Advantage
Product Management requires having pulse on the market. Get the top stories that will impact the market each day before anyone else.
|
Expert ChatGPT Prompt Guide
Join 600,000+ people from companies like Apple, OpenAI, and NASA at the Rundown.ai to get free access to our expert ChatGPT prompt guide.
|
This week’s issue may take longer than 5 minutes to read. But it’s about an incredibly important topic. So I encourage you to take the time to read through it.
Let's get into it...
What's the #1 KPI for product management?
On a recent Zoom meetup, I heard 20 different responses.
User experience. User satisfaction. User delight. User flow. Engagement, Adoption. Usage. Reduce risk. Make sure engineering is working on the right things. Story points per sprint. Number of features released. "Being the glue." (Is that a KPI?) "Define the product strategy." (Is that a KPI?) And much longer winded responses.
For funsies, I asked Google. I got this:
ChatGPT feels differently:
And a search got me this:
Oh, dear lord...
No wonder product managers are confused.
No wonder folks outside of our field struggle to understand how exactly product management adds value.
And no wonder it's easy for the folks with budgetary authority to question, "Do we really need more product managers?"
It's not user satisfaction.
In late 2007, I led a digital product that had terrible user satisfaction.
I earned an audience with the executive committee and proposed a plan to improve the C-Sat score for some added investment.
My pitch was as you'd expect: A better user experience will boost adoption and usage. I cited research we had conducted that said 70% of users said they'd be more likely to do business with us for a better experience.
My proposal was approved! My project was prioritized and I got my resources. The team, motivated to make this better for our users, burned the midnight oil to execute the plan and launched a host of improvements.
And guess what? User satisfaction rocketed to over 90%!
My joy was short lived, however, because the following year my funding was slashed and resources diverted, leaving me with a skeleton crew.
The reason?
Here's what the CFO told me:
"Shardul, do you know why we decided to invest in this initiative in the first place? The whole point here was to help boost purchases and save money by providing a digital experience. But your users are <2% of our base. We're a $220M company. How can we continue to justify a $3M annual investment on such a small return?"
Our #1 KPI in product management is not the things we were told to track.
It's not on-time delivery, number of bugs quashed, features per cycle, sprint velocity, uptime, user satisfaction, or nebulous goals like "a great user experience" or "innovation success".
Those are interesting to track, but none of them is our primary metric.
Let's go back to what our primary job is in product management:
Our primary job in product management is to continuously deliver monetizable customer value.
I talked about this in the very first issue of this newsletter. It's not just about delivering customer value, but monetizable customer value.
That is, products, features, capabilities, services, etc. that our customers will profitably pay for and continue to profitably pay for. Whether directly or indirectly.
When we do this, we drive sustainable business growth.
So the question becomes how do we measure monetizable customer value? How do we measure business growth?
Two ways:
- Net revenue growth
- Margin velocity
Recall, these are aligned with what is top of mind for our CEO too.
And this gets us to our primary KPI for product management:
Our #1 KPI in product management is Return on Invested Capital (ROI).
In other words, we need to ensure the precious R&D resources the company is investing in (including our own salary, by the way) are providing the maximum return possible.
This applies for:
- Launching a new product - we're investing $X, how quickly can we get it to market and start making money?
- Supporting an existing product - we're spending $Y on this product, do we keep spending that or can we decrease it while generating the same revenue?
- Growing an existing product - given our spend of $Z on this product, what things should we do NOW that will maximize our chances of getting more revenue with the same spend?
- Upgrading or expanding a product - do we need to invest an additional $N on top of what we're already spending to get that new revenue?
So...
When we're torturing our prioritization spreadsheets with their glorious scorecard algorithms (Value * Weight * Confidence ➗ Effort)...
When we're sweating what to do now vs. next vs. later on the roadmap...
When we're trying to force-rank our backlog of 100 items...
When we're sitting in grooming and sprint planning meetings trying to identify story points and plan the next sprint...
When we're sweating delivery dates (October 31st? 17th? 1st?)...
What we are really doing is trying to maximize return on invested capital in our product.
This is the heart of how product management delivers value.
The problem is too many of us fail to tell the story of how we're impacting this ROI, because:
- We lack the language. We talk in terms of features, Jiras, velocity, releases, and "user value". But what does it all really mean?
- We don't know how our work impacts the business. (Have you asked?)
- We were never taught this.
- Not all of us have MBAs. (And we don't need it.)
- Even among those of us that do, we don't do a good job connecting our daily work to results that matter.
Yes - product leadership bears responsibility for ensuring every product manager on the team understands the impact they're making. If it's not happening in your company, you should ask questions.
(And if you're a product leader reading this, you better make sure your team has that context!)
But individual product managers bear responsibility too. As I've talked about before, it's incumbent on each of us to make the effort to understand the business of our product.
Understanding our influence on ROI is crucial to understanding how we add value as product management.
Let's nerd out on that a bit.
Return on Invested Capital can break down as follows:
Net Revenue Growth is about how fast our revenue is growing.
The quicker we can earn revenue, the quicker we can make a return on the money we've invested in our product.
Margin is an indicator of the gross profit a product will make after producing and delivering the product to the customer, not including sales, general operating expenses, interest, and taxes.
It's basically revenue minus the cost of goods sold or the cost of providing the service.
Velocity here means the speed at which that revenue and margin can be realized by the business.
So, basically, we want two things:
- Grow revenue fast - gain more customers than we lose, keep them buying, and get them to buy more.
- Get our product features out the door fast. The faster and cheaper we can develop them and get them into customers' hands, without sacrificing quality, the more profitable the product.
Product Management has a critical influence on the financial performance of the product. We have the ability and the responsibility to drive both revenue growth and margin velocity.
Fortunately, no matter our roles, we have many levers at our disposal to influence these!
Today, I'll talk about what these are for Net Revenue Growth. I'll cover Margin in next week's issue.
Net Revenue Growth
Net Revenue Growth can break down like so:
Any well run company should know where revenue is coming from.
How much is from new customers vs. existing ones, and how much customers spend with the company over time.
The specific financial and supporting metrics will depend on the specific business model. So be sure to spend some time to understand what these are for your business!
What this means for us as product managers.
Now, let me get something immediately out of the way.
Yes, revenue is a team sport. Product Management isn't solely responsible for it.
And, yes, some product managers are in roles that don't directly deliver revenue. I've been in those too and had product managers in those roles.
Even in those situations, our "product" needs to provide some form of measurable ROI and we, as product managers, MUST know how to drive it.
And Ima 'bout to present some serious arguments to convince you. 🙂
As a product manager, we may find ourselves in one of 6 roles:
- Driving direct financial impact.
- Moving a supporting metric.
- Managing a specific feature.
- Managing a non-revenue "product".
- Managing an internal "product".
- Managing a re-platforming effort.
I'll discuss how the product manager is able to influence net revenue growth and ROI in each of these roles. Skip directly to the one most relevant to your situation if you'd like.
1. A Product Manager Driving Direct Financial Impact:
This is the most straightforward one. Examples:
A product manager wholly responsible for the financial success of a product.
A product manager responsible for reducing churn for a monthly subscription SaaS product.
At an education payments company I worked at, one of my product managers was responsible for our tuition payments SaaS product. Tuition dollars transacted and share of the educational institution's tuition payments were key financial metrics she was responsible for.
At a large financial services company, one of my product managers launched an "auto pay" feature. $payment volume was the key financial metric, with conversions, enrollment, and usage important supporting metrics.
2. A Product Manager Moving a Supporting Metric:
Some product managers are not accountable for a top-line financial metric, but a supporting one. If you are in this situation, it's vital to understand how your activities help with the top-line objectives.
For example:
You are a product manager assigned to improve the onboarding success rate of new customers who signup via the website.
The question becomes: Why is that important?
Let's say the company has discovered that while existing customers are sticking, new customers are churning at a higher rate. An investigation has identified that the current onboarding experience isn't cutting it with new customers.
So, your work to improve onboarding success is related to reducing new customer churn. Reducing new customer churn will increase customer lifetime, which, in turn, helps net annual recurring revenue (ARR) growth.
Knowing this, would this change how you approach prioritizing product work? You bet it would.
Would it change how you talk about your impact in performance reviews and job interviews? 100%.
Old way (boring):
"The onboarding experience wasn't very good for our product. So I was responsible for improving it. We did some user research and found 70% of users didn't like. I wrote the requirements, worked with UX and engineering to design the new user experience, and blah, blah, blah. 80% of users liked the new experience."
New way (exciting):
"40% of new customers were churning on average within 32 days of signing up, costing us $500k in net new monthly recurring revenue. So I led an effort to improve the onboarding experience for new customers. After launch, we brought down churn to 5%, which resulted in X improvement in MRR."
Which one gets your attention?
3. A Product Manager Responsible for a Specific Feature:
Some product managers are responsible for a specific feature or set of features of a larger product.
For example: You're responsible for the playlist feature of a music streaming app.
Another example:
At one company, I assigned one of my product managers to lead the scheduling module of our enterprise SaaS platform. We found that customers hated it so much, we were at risk of losing their business.
Two customers were threatening to not renew their multi-year contracts. And we were losing RFPs.
$millions in potential lost revenue due to this one feature.
While my product manager could not be held accountable for contract renewals or winning RFPs, of course, she was accountable for critical supporting metrics: Customer Satisfaction, Task Completion Time, and Task Completion Rate.
She drove the roadmap for the necessary improvements. Six months later all three metrics had dramatically improved.
Ok, good job. But so what?
We checked in with the account teams. They endorsed that the improvements went a long way to those two customers renewing their contracts, worth over $300,000 in annual contract value (ACV).
We checked in with the sales team. Results?
- Our scheduling feature was eliminated as the #1 product-related Deal Loss Reason.
- 4% improvement in sales pipeline velocity as a result of being more competitive in RFPs and sales conversations.
- Overall improvement in sales qualified leads (SQLs).
That's impact.
So, how can a product manager talk about this?
Old way (boring):
"I managed our scheduling module. Customers were unhappy with the experience. Two customers were threatening to leave us and Sales was complaining too. I led the customer conversations to uncover the things they didn't like and identified the requirements for the improvements. Then I worked with the design and engineering to blah, blah, blah. In the end, the customers were very happy with the new experience."
Better way (interesting):
"I was assigned to lead our scheduling module. Two customers were unhappy with the experience and threatening to leave us, and Sales was complaining they had lost many RFPs. So I executed a roadmap to vastly improve the scheduling experience. Our goals were to improve customer satisfaction, task completion time, and task completion rate. And I'm happy to share we improved C-Sat by X, task completion time by Y, and task completion rate by Z. And it resulted in making those two customers happy and Sales said they weren't losing RFPs anymore.
Best way (exciting):
"I was assigned to lead our scheduling module. Two major logo clients worth over $300k in ACV were threatening not to renew their contracts without major improvements. And Sales reported that it was the #1 product-related Deal Loss Reason at the RFP stage representing $X million in pipeline value.
So I developed a strategy to vastly improve the scheduling experience. Our goals were to improve C-Sat, task completion time, and task completion rate. And I'm happy to share we improved C-Sat by X, task completion time by Y, and task completion rate by Z. We saved $300k in annual recurring revenue. And Sales told me it not only made us more competitive with RFPs, but they saw a 4% improvement in pipeline velocity and an overall improvement in SQLs.
Which product manager would you hire?
4. A Product Manager Leading a Non-Revenue "Product":
This is actually fairly straightforward too. Because the company has decided to invest in the "product" for some meaningful ROI that indirectly will protect or grow revenue and/or improve margins.
Example:
You are the product manager of a mobile app that allows an auto insurance company's customers to request roadside assistance and file claims.
Switching costs for auto insurance customers are low and claim processing is expensive (let alone paying the claims). So keeping customer satisfaction high while keeping processing costs low is a big win.
While your primary metrics will likely be task completion time, completion success rate, response rate, and overall satisfaction with the experience, ROI could be measured in terms of:
- Requests made via the mobile app vs the phone. An increase in the latter would be more expensive.
- Since you know what customers are paying for their insurance, it's feasible to put an economic value on a customer, and thus extrapolate to calculate the economic impact of customers leaving primarily because of a poor mobile app experience.
Old way (zzzz....):
"I improved user satisfaction of the claims filing experience on our mobile app. I did the user research, wrote the requirements, worked with engineering, provided updates, blah, blah, blah..."
New way (awake!)
"Our mobile app handled 60% of claims filed, but we wanted to see if we could do better. Every claim filed digitally vs. on the phone saved the company $X. Plus, we knew every 1-point increase in the customer's claim experience resulted in $Y in incremental economic value in terms of customers continuing to stay with us.
We set a goal to increase this to 75% by year's end. I led the development of the strategy and drove the execution of the roadmap, and by year's end, while we didn't quite hit our 75% mark - it was 70% - we still delivered $Z in cost savings and estimated our overall economic impact in terms of additional customer stickiness to be $N."
You tell me which is the more impressive product manager.
5. A Product Manager Leading an Internal "Product":
Some product managers lead solutions for the company's own users.
Even in this situation, it's important to recognize that the company has invested in the system for some measurable outcome. Know what that is, and you'll know how to drive impact.
For example: you're the product manager responsible for the system used by your company's field sales reps to input customer orders.
You discover that in addition to a need to improve the user experience, there are a number of other problems:
- Difficulty in data entry slowing order flow.
- Lack of follow-up reminders causing reps to forget to follow-up.
- Difficulty finding customer info, slowing opportunity follow-up.
- Difficulty for sales supervisors to get a bird's eye view of how each rep is performing, thus, hampering optimal territory assignment.
Each of these can be quantified and even assigned an economic value. For example, if we know the average value of each customer order is $X, then:
- Adding follow-up reminders could help reduce sales cycles by Y days, resulting in Y * $X acceleration in the sales pipeline.
- Sales supervisors say putting their best reps on the most ripe territories could improve win rate by Z%. That's Z * X in economic value that could justify providing them with that bird's eye view.
6. A Product Manager Leading a Re-platforming Effort.
DISCLAIMER: Re-platforming is a BIG topic in and of itself, so I'm going to keep this very brief here. (Maybe I'll cover re-platforming in a future issue.)
I'll cover this via an example.
An insurance company I consulted for wanted to modernize a key system used by their agents.
The main issues with the current system were:
- Frequent system outages and performance concerns.
- High user dissatisfaction.
- Disparate sub-systems making it difficult to deliver new capabilities.
- High cost of ownership of current environment.
Compare these two product manager narratives simply in terms of describing the problem space:
Old way (tech nerd...):
"There were frequent outages and performance problems. Poor documentation and the different sub-systems made it hard to develop new features. The web servicing environment was well beyond its useful lifespan and had a high cost of ownership. And users were really unhappy. So the goal was to build a new, more resilient infrastructure with a new tech stack that enabled new features to be delivered more efficiently and effectively, and deliver a more integrated and modern user experience."
New way (results nerd):
"The system had suffered 10 outages in the previous 6 months, 2 of which caused business to be down for an entire day. The total economic cost in terms of human power and lost business was $10M. And because it ran on multiple sub-systems, even changing a button would take 6 weeks to complete. That's $1M just to change a button! User satisfaction was at 10% and IT was spending $60M a year just to keep the thing afloat. Re-platforming was going to be a 12-month $30M investment, which sounded like a scary number, but with an anticipated $120M in savings over the next 3 years, it was totally worth it."
Which nerd would you continue the conversation with?
Summary
- Product Management has a critical influence on the financial performance of the product.
- #1 KPI in product management is Return on Invested Capital (ROI).
- In everything we do, what we are really doing is trying to maximize this impact.
- Understanding our influence on ROI is crucial to understanding how we add value as product management.
- We have the ability and the responsibility to drive both revenue growth and margin velocity. Even if we're not directly driving revenue, we have MANY levers at our disposal to influence these.
So the next time you're celebrating any of these:
- Increased sprint velocity or release cycles...
- Launched more features this quarter vs last...
- Increased bug resolution rate...
- Improved C-Sat / usage / engagement...
Ask yourself: So what? What is the net business outcome of these?
Your action steps this week.
Your task this week is to understand:
- Which of the 6 roles described above are you in?
- What are the key financial or economic metrics for your product?
- What are the important supporting metrics?
- How do the local level metrics you and your team track align with producing these outcomes?
- How are your activities contributing toward these?
That's it for today. (Whew!)
