Elevate Your Product with Metrics: A Quick Guide for Aspiring Leaders

In this follow-up post for metrics, we’ll share some insights for the junior Product Managers or Tech Leaders who want to make a bigger impact through their products using metrics and story-telling.

We’ll specifically look at a method of defining the basic metrics for a product in a way that is easily communicated and reported to the rest of the teams.

Metrics you’ll need for your product or project

Metrics can assist you in telling a story about your product or project. Using the correct metrics and storytelling you can follow your project’s story from an abstract layer down to the nitty-gritty details.

Metrics fall into three levels in terms of complexity and coverage of your product or project which are High, Medium, and Detailed-level metrics.

High-level metrics

These metrics cover the biggest scope of your product or project and should be few in terms of number, up to 6. Identifying and explaining these metrics to people is usually hard. But once you manage to define and share them, suddenly it all makes sense; People get it and see their value in describing the whole product 🙂.

Some examples of high-level metrics are:

• ARR (Annual Recurring Revenue) that is affecting everything inside a product.
• MAU (Monthly Active Users) which again showcases activity and engagement with the whole product

You should also check out some more product-specific metrics that are unique for each company. These are the hardest metrics to define — usually referred to as North Star metrics. Check out some North Star metrics for AirBnb, Uber, Slack, and more companies in this post.

Medium-level metrics

These metrics cover a part of your whole product or project. While being abstract, these metrics’ impact is easier to explain as they usually refer to a big part of a feature or functionality. These metrics are good for making decisions around prioritization and roadmap, as you can easily compare feature X to feature Y.

Some examples of medium-level metrics can be:

• Measuring engagement on Feature X by combining smaller interactions related to the feature.
• Measuring the number or percentage of users that have activated Feature Y.

Detailed-level metrics

These are metrics talking about a very specific small part of a functionality and its performance. Detailed metrics are good for identifying improvement areas and small UX issues within a feature. They tend to be highly actionable as their value is pretty clear, so many people will have an improvement idea to share! Most likely you already have some detailed metrics about a small part of your project, e.g. “Clicks on button Y”

Combining all levels

All levels of metrics are closely related. A high-level metric consists of a few medium-level metrics, which in turn contain many detailed metrics.

In terms of affected teams, high-level metrics affect your entire project or product and many actions can grow out of them spanning multiple teams and people. Medium-level metrics affect a smaller part of your project having a smaller yet highly relevant impact on the entire product. Finally, detailed metrics affect a small part of your project and require fewer people to take action.

Affected teams reflect the internal impact of a metric and not the external impact of an action taken! The most characteristic example of a small action having a huge impact is the million-dollar button.

Good metrics and where to find them

Getting into the specifics of good metrics is a big process, involving more than system thinking and methods but also intuition. As covered in a previous post, questions are the best place to start your good metrics exploration, following the characteristics of a good metric being measurable, impactful, actionable, readable, and relevant!

To answer these questions you can use your sense of the project or product at hand, but also employ the power of other people! If we are talking about a product that more people are using, having interviews and discussions makes the exploration faster and way more accurate — talking about user interviews, user research, customer calls, discovery calls, discussions with internal stakeholders, etc. The more people you involve in the process the more educated your final metric definition.

Talking with people you will see some repeating patterns and mentions of specific areas of your product. These are your triggers to dive deeper with more questions that will help you identify the right metrics.

The pragmatic way to start your exploration is from the lowest level, the detailed metrics. These are the easiest to define as they are visible in your project. Leveraging the more concrete metrics can lead to a smooth way of defining the most important high metrics. Setting detailed metrics and reviewing the measurements will raise some more questions to help you with the medium-level metrics; one level up.

Moving to medium-level metrics, you are looking to group detailed metrics into an abstraction layer. If talking about a digital product a good guideline is to group detailed metrics by screen they are visible and try to define medium-level metrics for that screen. Another way to group detailed metrics is by project functionality or product offering, e.g. “the registration flow”, or “the onboarding experience”.

High-level metrics are harder to define, so safe for last in your exploration. These metrics are really important to your product affecting almost everything and everyone involved. Include as many people as possible in these metrics definitions. Approach candidate metrics with questions of disbelief that will prove the metrics wrong. You want to make sure that you are measuring the right stuff when it comes to that big of an impact!

Converting metrics to goals in real life

Converting metrics to goals is mostly about the high and medium-level metrics, as those are the most impactful to your whole product. The more certain you feel about your high and medium-level metrics the better equipped you’ll be to decide which metrics should be converted to goals. On certain occasions, you’ll have strong hints on converting specific detailed-level metrics into goals. Most of the time these metrics are relevant to the whole business, e.g. if your product is a social platform the invite button is of strong importance for the whole business.

To turn metrics into goals you need to add the time parameter in the equation. So instead of measuring the number of clicks on a button, you now measure the number of clicks on a button for a specific period, e.g. a month.

Introducing the time parameter, you are making your metrics more actionable; e.g. “Hey, in November we got 3,000 clicks on the button but in December only 2,000 clicks! What did we change? What did we introduce? We need to change it back!”

To turn that metric into a goal you need to set a target value. In real life, you start with limited data on setting that goal; so the way to move forward is by setting an arbitrary goal based on the information you already have at hand. E.g. “We know that we have almost 2,000 clicks on that button per month. Considering our audience and planned work, I feel confident setting a goal to double that number by the end of this year”

As shared in the previous post about metrics, the safest period to measure your goal is within a month. Regardless of the metric this goal affects, a month is a safe period to check the impact of an action you or another team member has done. If you introduce a functionality that you expect to have an impact on a goal you have set, give a space of one or two months of adoption time before measuring!

It’s critical to be 100% certain about setting a goal on the right metric, rather than setting an accurate goal on day one. Measuring and targeting the correct metric ensures that you will move in the right direction no matter how ad hoc your target goal is! After two or three months of monitoring your goals, you can revise the targets to be more realistic.

Building your dashboard and funnel

With a goal and set of metrics defined you are now ready to start building the story around your measurements. The story is better communicated via an interface for your metrics. This interface should guide the reader — you included — into understanding the metrics displayed and their relations.

The most important interface should include your high-level metrics in a way that they form a story. The best way to represent a relation between metrics is through a funnel, where each step is a deeper dive into a more defined action.

As an example for a digital product, an interface on High-level metrics should include the hypothetical steps of a story that:

• Starts from awareness: “What’s this digital service?”
• Goes through test out: “Let’s jump in to see what’s this!”
• Right in the aha moment: “Wow! I can see the value!”
• Ends in an acquisition: “Take my money!”

These steps are progressively talking about more defined action forming a funnel. Another characteristic of this High-level funnel is that it is easily understandable, you don’t need to know details about the digital product.

Diving one step deeper, into medium-level metrics, you can build a separate interface to explore each of the in-between steps of the high-level funnel, or to explore the intricacies of a specific story of your project that still drive your high-level metrics.

Following the same example of the digital product, let’s see a hypothetical funnel for the in-between steps between testing out and the aha moment:

• People understand that they can test out the service: “Oh! There is a trial available that I can play with!”
• People join the trial and find their way around the service: “OK, I can understand what’s going on here. Let’s explore some more…”
• People are urged to use parts of the service: “Hmm, let me add this input that’s relevant to me”
• People reach the aha moment translated to their data: “Wow! This is an important value for me!”

You noticed that we are still in the same story adding more details and more technical stuff, like “input”, “trial”, and “my data”. There can be multiple interfaces for the medium-level metrics and funnels, each covering a specific aspect of the bigger story. Please try to keep it lean and manageable by identifying and monitoring the most important parts first!

Finally, we can jump on the detailed level interface to represent specific functions that affect each step of the previous funnel. Here we’ll add all the metrics that reflect very specific and vertical actions.

In the above example, such an interface for the step of understanding that there is a trial for the digital product could include:

• Views for each page that explains the trial availability, to assist in measuring and comparing people reaching each page.
• Clicks in buttons that lead to “Start a trial”, to measure interest from each page and determine which page “converts” better.
• Number of exits from these pages that the visitor didn’t take any action, to check whether the audience seeing these pages was interested in a trial in the first place or not.

As you see, now we are very specific on metrics and numbers, yet telling the same story. These metrics do not necessarily form a funnel. Like in medium-level metrics, you can generate as many dashboards as needed, but still, keep it at several interfaces that you can follow and not get lost!

Building the right dashboards and connections between them act as tools that can help you and the team identify areas of improvement.

In the same example of digital product, let’s say you check the High-level funnel in December and you identify a drop in the test-out step. Then diving deeper into the medium-level funnels you see that the drop has to do with how people perceive the existence of a trial or not, while all the other funnel metrics remain the same. With this info, you can finally jump into the detailed level metrics and see which page stopped performing well or narrow down your search in pages you changed in November.

Reading the above paragraph, it’s clear that we are still telling a story. If you have set up your dashboards in the right way, it makes your story easier to communicate to the related people and teams, teams that need to take action to improve what you identified, or teams that you need to collaborate on finding an action plan.

Cadence of reporting, “How we doin’?” habit

We’re now entering the last part of this — long — post; wrapping it all together by sharing with more people. Metrics are as impactful, important, and valuable as you make it. The more people working on a product or project that see and understand these metrics, the better for everyone; You will need to build and repeat a consistent message!

“How we doin’?” :) Couldn’t skip this reference opportunity!

To get buy-in from everybody you will need to tell a consistent story, repeatedly, with additional reminders when needed. Let’s see each part separately

Telling a consistent story

Using the dashboards and funnels created, you need to build a single narrative/story that applies to your whole product.

The story around your top funnel is the most important one, as it includes all the smaller parts.

Stories of your medium-level funnels are next. These stories should bind the most relevant features of your product or project to the overarching top story.

There’s no need to dive deeper into a story about the detailed-level dashboards. These dashboards are just reference tools for your medium-level stories.

Tell that story repeatedly

With your stories set, you need to find a cadence of repeating the message. Building a habit around the message increases your chances of making the message stick and be adopted by more people.

A good cadence and message is to repeat the high-level story every month. A monthly update on the high-level metrics for a product is something that everyone is interested in.

Additionally, using the monthly update as a starting point, you can deep dive into the medium-level stories of interest. Interest is defined either by a significant drop or increase on the relevant medium-level metric during that month, or an important update on the relevant feature and functionality.

Explaining the details of a medium-level story will eventually lead the discussion to the nitty-gritty details of the specific detailed-level metrics responsible for the presented story of interest.

Additional reminders when needed

Reminders are changes in your product that directly affect the measured metrics. Some of these changes are:

• Roadmap update to add/remove a roadmap item, which is a trigger to share if this change was related to a specific metric measurement or is done to affect a metric.
• Achieving a milestone or a metric goal, to remind all involved people of the impact their work has in important measurements.
• The impact of a product update acts as a trigger to talk about the specific detailed-level metric this update affects. You can grab that opportunity to explain how this seemingly small change can affect your medium and high-level metrics.

Summary, and a quick reference card

This whole post is based on an analogy from nature on important metrics. The three levels of metrics form a tree and its branches:

• The trunk is your core, high-level, metrics that encompass the whole story.
• The big branches are your medium-level metrics, covering the major features and functionalities of your product.
• The smaller branches and leaves are your detailed-level metrics, talking about specific elements of the product.

Even the slightest change in a leaf propagates to the trunk. Similarly, the stronger the trunk the better it feeds all the branches and leaves. This analogy serves in two ways:

1. A small change in a detailed-level metric in a leaf reaches the trunk, affecting high-level metrics. So, don’t forget to make that connection when reflecting on a change in a metric.
2. As all parts of a tree are connected, don’t forget to share the whole story when explaining a noticed measurement on a high, medium, or detailed-level metric. Connect the story from “leaf” to “trunk” to level and people will get it!

Finally here’s a summary card for the three levels of metrics as a reference, enjoy!