Metrics for Internal Products

At my current day gig, I’m helping a group of people who have recently moved into product management roles get more familiar with product management ideas and practices.

In a series of weekly sessions, I offer a set of materials for the cohort to read, then we get together to discuss their impressions of the articles and how what they read might apply to their current work.

A recent session focused on goals and metrics. This was an important, and somewhat challenging topic for a few reasons. 

First, most of the people in the cohort are coming from project management backgrounds so they have little experience using outcome metrics to measure success and progress.

Second, almost all the products the group works on are internal products, so it's challenging to identify meaningful metrics.

Third, the company is jumping in with both feet to moving to product funding. Their interpretation of product funding means they fund products six months at a time and use a team's performance against metrics to make future funding decisions.

So as you may imagine, there was a lot of interest in identifying proper metrics for a product team. 

I figured that if that group had a lot of interest in the topic others would as well, so I decided to share some key points we talked about in the discussion and the resources we referred to.

Key Points

There is a lot of information out there about using metrics to measure the success and progress of product development efforts. I couldn’t hope to cover the entire topic, so I focused some key considerations on choosing metrics for an internal product.

Ideally, your metric should provide insight into how you’re helping solve customer problems in a way that works for your business. Where possible that means looking at metrics that are meaningful in a business sense and doesn’t simply measure features delivered or story points completed.

Adding complexity to that first thought, a company usually cares about things like revenue, margins, and customer acquisition, which they should. Unfortunately, a single team rarely works on something where they can directly impact metrics like those. They need to track metrics that are within their control and that they can measure frequently enough (daily or weekly) to get fast feedback on their efforts. The metrics, sometimes referred to as product metrics or proxy metrics act as leading indicators to the teams’ impact on broader business metrics such as revenue.

Buried in the above point is the annoying tendency for people in the product management community to use multiple different terms for the same concept. You’ll not get away from that, so make sure you can build agreement in your team and company about what words you use for those concepts.

While you want to use metrics to track the progress, you’re making to a particular outcome, you also want to monitor other metrics to make sure your actions don’t lead to unintended consequences. These health metrics provide guardrails that constrain your solution. For example, don’t take actions to attract new customers that result in losing existing customers.

Finally, when you decide on the metrics you’re going to use, make sure you have a good way to collect those metrics. You may find that some of the initial work you do on a new product is putting a mechanism in place to collect the metrics you need to keep track of.

Do you Like What You're Reading?

Subscribe to InsideProduct to get the newsletter before everyone else when it comes out every other week.

Goal and Metric Resources

Empower Product Teams with Product Outcomes, Not Business Outcomes

Good discovery starts with a clear desired outcome. A well-defined outcome provides a focal point for the product team and serves as a guiding light for their discovery efforts. It helps the team quickly identify and conserve their time and energy for the initiatives that matter most.

However, teams are often responsible for driving business outcomes instead of driving product outcomes. To clarify the difference between these two terms: A business outcome is a metric that moves the business forward, while a product outcome is a metric that helps us understand if the product is moving the business forward. Teresa Torres further explains the difference between the two and why product teams should focus on business metrics.

Metrics that matter to product managers

https://www.departmentofproduct.com/blog/metrics-matter-product-managers/

The inherent value of product metrics is in discovering little nuggets from the myriad of analytic data available about your product. To discover these nuggets, you need to ask interesting questions and know which metrics you should be measuring. Richard Holmes can’t ask interesting questions for you or your product and tell you which metrics matter most for your product or business model. But he can provide you with a useful list of metrics by product vertical which you can use for your product.

Are you tracking the right product metrics?

Metrics can be a minefield for the unwary—navigating your way to find the right metrics is one of the hardest parts of a product manager’s job. What do you need to know to make a go of it?

Finding the metrics that matter for your product.

Startup literature is full of ardent advice on how to measure activation, engagement and how users are interacting with your product. These concepts might help your business in the short term, but can leave you blinded by the very data you hoped would open your eyes in the long term. Kevin McNally and Nick Odlum explain how to go from plugging numbers into formulas to asking and answering key questions about your product and business in order to track and use the right metrics.

OKRs vs KPIs: what's the difference

OKRs have skyrocketed in popularity over the last five years. Yet, many still have questions about their true purpose is, especially when you compare them to other metric-based tools like KPIs. This post defines what KPIs and OKRs are and then looks at the differences between them.

Book Club Anyone?

During the month of May, I’ve returned to the in person speaking circuit after a nearly four year hiatus (for… reasons). 

Two weeks ago, I spoke at Building Business Capability (BBC) in Las Vegas. Last week I spoke at IBADD in Des Moines, Iowa.

There were a lot of common themes between the two conferences, no doubt helped because both are focused on business analysis, and because I gave the same talk at both conferences. 

One other completely unintended recurring theme was the idea of book clubs. At both conferences, an attendee came up and said that their company had used my latest book, How To Be An Agile Business Analyst, as the focus of a book club their team had organized.

I was honored that they used my book, but also surprised that two separate companies created book club discussions about the book. I guess I shouldn’t be too surprised since I did the same thing for a group of product owners at a local company a couple of years ago.

So I'm curious if this book club thing is a trend, or merely a coincidence. 

Has your team done a book club or talked about doing a book club focused on business analysis, product ownership, or product management? Let me know in the comments!