How to Define Metrics
for Internal Products
|
|
|
|
READING TIME
3 min & 37 sec
|
Dear es,
Most metrics examples focus on popular and external-facing products. Let's discuss how to define metrics for internal products.
I'm a fan of going back to the basics: Any metrics framework should help you measure value delivered to or changes created for whoever your audience is. And guess what? Even internal product teams have an audience: The fellow product, marketing, or sales teams their products serve.
Once that fundamental truth has sunk in, internal teams can also much easier understand that concepts like North Star Metrics or Lagging and Leading Indicators are contextual, not definitive. The Input Metric for one product's NSM could also be the (smaller-scale) NSM for another team. What's a leading indicator for one team can also be a lagging indicator for another team.
Let's assemble the pieces:
I once worked with a Product Manager who built a solution to enable internal product teams to ship their software. Zooming out, customer-related business metrics and user outcomes were tied to the shipped software, but these were multiple layers removed from this team's sphere of influence.
In our coaching Session, we sketched out a few potential metrics components for her work:
As a North Star Metric, you could set something like “The no. of bi-weekly well-packaged releases.” To quantify the NSM, one could use criteria like:
- A release that hasn't been rolled back within x days,
- that required less than x amount of DevOps activities by the product team,
- and that had x% automated test coverage
This NSM wouldn't directly contribute to external-facing business goals like ARR or Daily Active Users. However, enabling the efficient and reliable shipping of software has another business implication: It ensures that product teams have more capacity for impactful work. This means it can drive a product team's "Outcome ROI" and contribute to their velocity, which is very business-relevant since a product team is a company investment.
Working down from the NSM, the input metrics can be broken down further. The input metric “Share of Automated Test Coverage” changes due to metrics like:
- Automated Test Coverage among On-premise Teams
- Automated Test Coverage among Cloud Teams
- Automated Test Coverage among iOS Teams
- etc.
To use just this one example, driving “% Automated Test Coverage among Cloud Teams” could become a periodic strategic focus for this team. This would allow them to draw inspiration from that part of the metrics tree to set their OKRs.
Alternatively, the prioritization and Discovery of this team should be guided by questions like
- "What's the biggest blocker for product teams when it comes to shipping their software?"
- "What DevOps responsibilities take up the most time among product teams?"
- "What are the top 3 reasons why teams have to roll back a release?"
Exploring and answering these questions will provide them with more outcome-ish metrics they can connect to the overarching value they want to deliver.
HOW TO PUT THIS THEORY INTO PRACTICE
- Define your Strategic Audience. Even internal users can be segmented by department, behavior, technology usage, or regionality.
- What usage and business value are you creating? How does the behavior of your colleagues change as a result of using the most ideal version of your product? What does the company gain from this behavior change of teams using your product?
- Identify influenceable metrics through metrics trees and apply to look for IDLE attributes.
|
Did you enjoy this one or have feedback? Do reply. It's motivating. I'm not a robot; I read and respond to every subscriber email I get (just ask around). If these emails aren't for you anymore, you can unsubscribe here.
Thank you for Practicing Product,
Tim
PS: My valued peer and good friend Tamer opened enrollment for the Spring Cohort of this Product Management Essentials Course. It is designed for Junior/Mid-level Product Managers to master the most essential yet hardest skills in modern product management.
How to Dive Deeper into Product OKRs
A Practical Guide to Using OKRs in Product Management: This hands-on guide goes beyond the average "best practices" of OKR basics and instead focuses on the real challenges of Product Teams for using OKRs in addition to Product Discovery, Roadmaps, and Scrum.
|
|
Content I found Practical This Week |
How to measure a data platform?
There are naturally different ways to get data for metrics. The classic way would be searching source tables or existing metrics tables for metrics covered already. But I like to show an alternative way here. Not a big surprise to you if you have read other posts by me; I will do this by using event data. We will pick each metric and break down which entity + activity = event we would need to measure the metric and also look a tiny bit into which properties, aka dimensions, could also be helpful for us.
|
5 KPIs for internal product managers to track
Internal product managers don’t exist in isolation. They often work hand in hand with IT and business operations to ensure digital tools are providing the maximum possible value. Part of that effort involves reducing the amount of time spent manually providing support to employees. The best way for teams to drive support ticket deflection is by first measuring the baseline amount of ticket requests related to given apps or tools. After a set amount of time following the deployment of in-app support or resources, they can gauge the effectiveness of their intervention by comparing the new norm to the baseline.
|
OKRs for Platform Teams
What does that data help the product teams do? Give them the ability to make more objective, informed decisions about product development and change faster. What’s getting in the product teams’ way of making good decisions today? (In other words, what are they complaining about?) At our example event planner app company, let’s say it’s a lack of accurate data. If you made the issue better, what would the product teams be doing differently? Making decisions faster, making more accurate decisions (based on a set of predetermined criteria for accuracy), asking fewer clarifying questions about the data, needing to make fewer requests for new or re-run data sets
|
What did you think of this week's newsletter?
As a Product Management Coach, I guide Product Teams to measure the progress of their evidence-informed decisions.
I identify and share the patterns among better practices to connect the dots of Product Strategy, Product OKRs, and Product Discovery.
Enjoy the newsletter? Please forward it. It only takes 2 clicks. Coming up with this one took 2 hours. |
|