What is an important KPI that you see product teams completely missing?
Interestingly enough I see two trends in the types of KPIs product teams miss.
1) Aligning with the larger's organization or business goals - Ensuring that your product roadmap is actually impacting the success metrics (OKRs, KPIs) of the business itself is critical to knowing if you are investing in and prioritizing the right work.
2) Capturing "technical or engineering" metrics - Any work that your team spends time on should be impacting some metric. Even metrics that are technical (the most common one being latency) should be captured, reported on, and measured over time.
- In terms of KPI's shared between product and engineering, I would say "Effective Resource Utilization" can be missed primarily because it can be hard to track and measure across projects/teams.
- "Internal team satisfaction" is another one that PM's may not include but this is an extremely important metric that provides a good idea of the health of the team and organization. This should not be missed.
Many product organizations focus on delivery, Net Promoter Score, and user counts. One metric that I think is important to always consider is your availability and consistency of user experience in the performance of the application (latency). Using Error Budgets and thinking about uptime critically as a Product Manager helps put into tangible terms the cost to the user when your offering does not meet a performance or uptime standard. If you are offering mission-critical software, it is essential to be responsive and reliable. Lack of responsiveness and reliability can erode your base over time.
This is a good one. I think there are two that often get missed and largely it is because they are hard to measure and expensive to move.
- Product excellence. How do you measure customer delight in an impactful way? CSAT and NPS have lots of opportunities to be gamed and are frankly easily ignored. Some of the best products I've used focus on finding the right critical user journeys and continuously measure the success rates of those quantitatively and qualitatively
- Product health. Cold boot, warm boot, latency for critical actions, crashes, uptime. All of these things contribute to Product excellence but are much more directly measurable and can really sneak up on you
Oftentimes, I find that Product Management teams are focused on getting the product to market that they forget that their #1 job is building a business. As a business leader, you can't be simply focused on the "speeds & feeds" or what next feature needs to be on the roadmap. You really have to understand the product's core value proposition: why would a customer choose your product over the existing way the problem is being solved today? And from here, how do you plan to monetize and scale the solution?
Several PMs, like me, have engineering backgrounds. This is great because engineers are deep thinkers but the downside is our problem-solving nature can force us to forget the commercial side of our job. We're here to build products that generate revenue, retain cusotmers, and drive profitability. If we can't tie back to those things, we're missing a big part of the job.
This is a great question. In my opinion, a lot of product teams especially ones that are focussed on customer-facing products completely miss tracking product health KPIs like bugs in the product, product uptime, and product reliability to name a few. Most product teams miss them as this product health metric is not tied directly to any business objective and is considered an engineering vanity metric. The reality however is this KPI is really critical and can inform customer experience that can translate to customer satisfaction and retention.
This is not a single KPI, but often in the past, I've seen KPIs set that are not tied back in any way to broader business goals.
For example, if a product manager on my team came to me and said, "My KPI for this product launch is 30% adoption in the first month." My first question would be, "How does that relate to our broader business goals of increasing net retention or driving trial conversions?"
That KPI should only be measuring adoption if think it will directly impact one of those broader business goals and we have a way to measure it.
I have sometimes seen Product teams focus on impact instead of landed impact. And while there is a lot of nuance in that answer I think landed impact is often the most overlooked KPI or OKR or goal (however you like to call them).
Teams will goal on number of users or shipping a feature rather than goal on the impact enabled by those metric. Take your typical B2B SaaS for instance. 200 active users of a feature on day 1 is an ok measure of success. But what really matters is what those 200 active users have achieved with your product. Or what those 200 active users have led to in terms of business impact.
The visual below is a good illustration of what I mean:
There is not one, uniform KPI that I think product teams completely miss. What I see sometimes is the lack of a value thesis: product managers wave around metrics they want to collect, but they don't have a hypothesis about the target for that metric and on what timeline after feature delivery they expect to see that target achieved. Now, being mindful of Goodhart's Law, I usually tell PMs that I'm unlikely to hold them accountable to these targets if they have a good explanation for why they were off (assuming they didn't know those things a priori) but I want them to think through numerically what good looks like before they launch. I don't want or need exact numbers, but just a SWAG or order of magnitude is good enough.
With this framework in place, what I've found is that (a) PMs are likely to pick targets that are reasonable to hit and usually not sandbagging; (b) the selection of a target is incredibly motivating for an engineering team and also gives engineers a sense of how good a feature needs to be at launch.
The business KPI are extremely important, and often forgotten by product teams.
The purpose is not always to have as many users as possible, the purpose is before everything to make business impact. And hence this is what product teams should always have in mind.
What do the sales look like, how are they growing week after week, etc. are very important KPI for a product team.
I'll change the question slightly and answer more broadly:)
I have found that product management is good at defining "output metrics" for e.g. active customers, retention%, and revenue impact. The second set of metrics PMs love to talk about our funnel conversions. However, where the metrics need to get more solid are around engagement - what are the "input metrics" that give you confidence that your customers are engaging with the product and as you build new capabilities how do you make sure that you don't get lost in the noise.
For me, two main KPIs that should be the center of attention, time to value and product activation rate. It's shocking how many product teams obsess over metrics like churn, retention, or NPS while completely overlooking how long it takes for users to experience the core value of the product.
TTV mainly directly correlates with customer satisfaction and long-term loyalty. If your users don’t quickly experience value, they’re more likely to leave, no matter how great your onboarding is or how strong your features are.
I’ve seen companies invest heavily in sales and marketing, only to see user frustration boil over when it takes weeks to hit that "aha" moment.
So to have a high TTV, optimize onboarding, remove unnecessary friction, and give users a clear path to the value your product provides. Have a clear user mapping/journey plan that reflects and shortens the path to the value of your product.
Top Product Management Mentors
