What is the purpose of the hierarchy of metrics?

When you have an idea for a feature, it is beneficial to “introduce” it to the hierarchy of metrics. This will help you understand which metric will be most directly affected by the feature.
The closer the metric is to the “top” of the metrics hierarchy (to the key metric of your product), the more likely it is that the feature will be successful.

Compilation algorithm

It can be helpful to visualize the algorithm using MindMap (e.g. MindMeister, Mind42, Miro) or on a sheet / flipchart
1. Determine the primary metric for your company (for example, “Revenue”).
2. Determine which key product metric of commits to the primary metric of your company (let’s say that this is also “Revenue”.)
3. Determine which 3–5 main metrics affect the key product metric the most (for example, let this be “Average purchase price”, “Purchase frequency”, “Number of users” and “% of Paying users”) — these will be level-I metrics.
4. For each of the level-I metrics, ask the question “What sub-metrics affect this metric the most?” (For example, “Average purchase price” is affected by “Average cost of goods” and “Average number of goods in a particular order”) — these will be the level-II metrics.
5. Now we take the level-II metrics and get to the level-III metrics and so on — in general, it’s reasonable to dig until level IV-V (depending on the size and complexity of your product) — keep digging until you reach a level that you consider reasonable (and there is the possibility of influencing metrics of the given level.)As a result, you should get something similar to this hierarchy:

Nuances and details

As a simple option to start — I would suggest that you use “Revenue” as the key product metric (if you don’t have any other input from the company’s leadership).· In the best-case, the list of sub-metrics should be compiled in such a way that only they can influence their “parent” metric — thus the “parent” metric is completely compiled of and depends on the sub-metrics.
Elements of the hierarchy should consist of precisely measurable metrics (as opposed to features).· The hierarchy is built from top to bottom (from the goals of the company to the metrics associated with individual features).
The hierarchy of metrics is usually compiled once and is seldom updated — only after massive changes (once a year, for example)
The hierarchy of metrics can contain elements that are logically interconnected and have mutual influence, but are in various separate branches. In such cases, they can be visually connected by a dotted line (in order to take this fact into account when making decisions). Also, a metric can affect several parent metrics — but in these cases the metric should still be assigned only to the parent metric on which it has the greatest influence.

What to do with all this next

Take your backlog and decompose the features from it into metrics derived from the metric hierarchy — the closer to the top the metric is, the more likely the feature will be successful (of course, there is still a certain “tackle” coefficient when influencing a metric — that is, if you greatly influence a level-IV metric, then this can more useful than a small change in a level-II metric)
Analyze the level-II and-III metrics; focus on them and hold a brainstorming session. Determine which new features can boost these focus metrics — then include the features in your product’s backlog.

Frequent errors

Goal setting: confirm that the metric you have chosen for the top of the hierarchy is truly the most important (hint — check with the company’s leadership + you can take the “Product revenue” metric by default). Do you really want “Order quantity” to increase more than anything else, and not “Total revenue” or “Ratio of revenue per user to attraction costs”?
Confirm that each element of the hierarchy is a measurable metric (you don’t need to add features to the hierarchy). Sometimes you may want to highlight a set of metrics (one of the branches) and highlight that a certain department is completely responsible for influencing it (for example, Marketing, Support, …) — it’s OK to do this with additional visual highlighting or highlight these elements with a certain color so that the hierarchy becomes easier to navigate.
Focus on the metrics, not the features: when you correlate the ideas of features and metrics, it’s worth writing features’ ideas next to (or in a comment) with the name of the metric that they affect, but not as a separate element of the hierarchy.
Make sure that the number of “vanilla metrics” in your hierarchy doesn’t overtake everything else — otherwise you run the risk of chasing them, and subsequently ignoring key product metrics.
It’s not recommended to directly link a sub-metric to several “parent” metrics — otherwise it will become difficult for you to make decisions. In extreme cases, designate one of the connections as primary, and mark the others with a dotted line. Of course, in is natural for some metrics to affect several others, but it’s important to be able to maintain focus and highlight which parent metric is most affected.

Answers to questions

On the slide that discusses the hierarchy of metrics, it was pointed out that features should be associated with a metric, and the closer this metric is to the primary one, the more important the feature is. Can you explain in more detail why this is so?
When constructing the hierarchy, the goal is to break up the metric into their sub-metrics. How, then, is it possible to influence a level-I metric without affecting any level-II metrics?

The nuance lies in the fact that a feature often affects several sub-metrics at once (for example, both the “Average number of products in the Cart” and “Average number of products marked as Favorite”) — then it will be incorrect to “connect” the feature to one of the sub-metrics and it’s necessary to stop on the “parent metric” — “Average number of products in the order”.More often than not, the closer a metric is to the key product metric, the more likely it is that the feature will be a “hit” (since each step from sub-metric to parent metric carries some chance of weakening the influence the metric on its parent and, accordingly, carries statistical losses). If we know for sure that when launching a certain feature, it will affect the top-level metric that we need –that’s great, since we don’t have to hope that “launching a feature will affect the level-IV metric, and that will then affect the level-III metric, and that will then finally will affect the level-II metric” (there is always a chance that at one of these stages there will be loss and the influence will not be as strong as expected).

Regarding fundamental features: If we take an example from the lecture on watching videos, it’s very difficult to say which metric the feature “video player implementation” will affect, because without it the entire hierarchy becoming meaningless.
The question is then; do we take such “obvious” tasks out of the brackets in this case? Do we divide features into mandatory and optional categories?
Yes, technical metrics should also be included in the hierarchy, as they directly affect the revenue of the product. For example, the metric “Duration of video viewing” is affected by the metric “% of videos without breaks in viewing” — and the feature “Quality of video player” will affect this technical metric.

I can’t wrap my head around it. I have an idea for a new product = an application for nursing mothers, where there is a log routines, articles, audio with white noise and all that. I allegedly conducted a survey (I will re-post it on the forums, because my understanding came after the meeting), allegedly confirmed that there is a problem.
Then I determined the first business goal — 200K active users. Then I tried to break it into metrics that can achieve it.
https://mm.tt/1353341843?t=4FWfHkjndvI identified the 3 key metrics and tried to think up so features within them. I even succeeded somewhat.BUT. I still don’t understand where the development of the application itself is planned. Or was I supposed to do it as I was building a hierarchy of metrics, and I didn’t correctly define the metrics that are required for a new application which would affect launch?

In this case, the following plan is possible:

Key Product Metric — Revenue.
Level-I metrics: “Number of active users”, “% of paying users”, “Revenue per user per month”.· “Number of active users” is then divided into level-II metrics such as “% of people onboarding” and “Retention” (which depends on the type of product, for example 7-day and 30-day.)
Under “% of paying users”, for example, the metric “How often a user sees an offer to purchase” can be defined.
“Revenue per user per month” can include metrics related to the cost and quantity of your services.
Marketing funnel metrics and acquisition costs can be placed (to simplify the architecture) into a separate funnel hierarchy (there the key metric will be the CAC, and how the sub-metrics will get separated across the different attraction channels, which will then be divided into sub-metrics of the cost of acquisition by channel and conversion to the installation / registration) — most likely the company leadership will ask you to maintain a balance of revenue and acceptable CAC.