So you’ve decided to build a metric tree…now what?
In Part 2, of our 4-part webinar series Driving Operational Clarity - The Metric Tree Masterclass, I was joined by Sara Sabzikari and Matthew Brandt as we built a metric tree together, live. As we go, we encounter some common challenges when building metric trees, including:
What steps to follow when building a metric tree
What to consider when decomposing metrics
How to work with stakeholders throughout the project
A typical metric tree project will follow the following stages:
Plan and Scope - decide who will be involved, where the tree should begin and end, the estimated timelines, and how often you want to meet as a project team
Draft metric definitions and connections - make the first draft of the tree with sticky notes, each of which describes a metric and its business logic. Review definitions and connections as a team.
Add the first draft of data - Begin to replace sticky notes with live data. Here is where you’ll likely face questions like which time frames to include, the specifics of the definitions, and how to display each metric to be most helpful.
Automate and Scale - create and test data models to improve performance
Roll out to the business - share the tree with the wider business, usually by introducing it at meetings; this includes documentation
Expansion plans - do you want to expand the tree? Build a new one for other departments.
The toughest part of building a metric tree is almost always defining the tree. Here are some pieces of advice on this step:
You should be prepared to spend a lot of time here working with stakeholders to get it right. Always start by laying out your tree with sticky notes, and getting alignment on definitions before doing any data development.
It’s helpful to consider what’s important to the business - e.g. do people think about revenue in terms of profit and costs, or by new, existing, and lost revenue? It helps to think of how the organization is broken down (e.g. are there teams for different metrics?)
Don’t do too much with any one metric - e.g. there is rarely a need to normalize a metric since each metric gets further decomposed. Normalization may be helpful when you have limited space to explain a metric, but with the tree, you should have space to show the complexity of each metric.
It’s best to take an iterative approach instead of a waterfall. Prototype your tree, and even the analysis and code driving each metric before productionalizing in whatever tool you use or even perfecting each visual.
When adding data to a tree, Sara suggests starting from the bottom and working your way up so it’s easier to see if things aren’t adding up. You can experiment with different approaches here of course.
Anticipate questions. As you build your tree and see a number falling dramatically, or something odd in the data, you should expect questions and either try to answer them, or add filters and tables to help understand those metrics better when you next meet.
As you go, jot down questions for the business like ‘Can someone become active twice?’ ‘Do we want a rolling timeframe or static?’ Make sure you cover these questions in the next meeting.
If this is a large metric tree, you can divide the tree into sub-sections, and even divide work among the team members.
