"Not everything that counts can be counted, and not everything that can be counted counts."​
– Einstein-ish wisdom, but also every data team, eventually

Why This Matters

Every impactful data initiative starts the same way:

With a business goal.

But here’s where things fall apart:

• You start building before the use case is fully defined.
• Or the use case is clear, but the technical translation is a mess.
• The result? Misaligned dashboards. Confusing metrics. Stakeholders losing trust. Engineers scratching their heads.

That’s why I created (and recently improved) one of my most-used tools: the KPI Dimension Map. 

Every time I create this map for a new data initiative, it serves two critical functions:

1. It helps teams anchor around a single, high-value use case tied to business outcomes.
2. It turns that use case into something actionable - so it can be modeled, implemented, and delivered by a data team.

In other words: it connects what matters with what gets built.

Quick Recap: What Is the KPI Dimension Map?

It’s a cross-tab matrix where:

• KPIs go on the vertical axis
• Dimensions go on the horizontal axis

But don’t be fooled by the simplicity. Behind that grid is a deeply strategic tool.

Unlike a KPI tree (which shows causal relationships between metrics), the KPI Dimension Map is used to:

• Define the deliverables of your data initiative
• Act as a blueprint for your technical data model
• Help you start with the outcome and build backwards

I’ve refined this framework over years of defining pragmatic, actionable data strategies. And now I’ve made three upgrades I think are worth sharing.

1. Split Every Metric into Its Building Blocks

Old version: one column that describes a metric (Column A in the KPI Dimension Map) 

New version: Each KPI is broken into:

• Measure: What are we counting?
• Dimension: How do we group or slice it?
• Filter: What constraints are applied?
• Metric: The final output. A combination of Measure + Dimension + Filter

For example:
​% Monthly Mentors with Calls rated 4 or above (in Row 80)

• Measure: Mentors
• Dimensions: Call Activities, Reviews
• Filter: Rating ≥ 4
• Metric: The final % figure

Why this matters: This structure mirrors how I build data models in the warehouse. 

• Measures, dimensions, filters → defined and ready in the objects layer
• Metrics → defined in data marts, closer to the business

It forces clarity and reusability.
It avoids metric soup.
It makes your technical layer scalable and modular

And the best thing: it allows you to easily decentralize the creation of data marts into business domains in more mature hub-and-spoke setups.

To use this, just add three new columns and break down metrics into measures, dimensions and filters.

2. Add Context on Influence: Input vs Output Metrics

One of the most powerful decisions we make during a KPI Dimension Map build is:
​Is this an input metric or an output metric?

That simple classification changes everything:

• Input = directly influenceable
  → e.g. “# of content pieces published”
• Output = only indirectly influenceable
  → e.g. “Click-through rate on content”

This gives you a strategic lens on how to design dashboards and prioritize work.

I typically aim for one input dashboard and one outcome dashboard per domain. No more dashboard sprawl. 

And this classification ensures that what you build supports actual decisions, not just measurement theatre.

3. Clarify the Time Relation of Every KPI

You’d be surprised how often this gets skipped and causes a lot of confusion.

Every metric exists in time. But which time?

Let’s take returns in e-commerce.

You can look at returns in the following ways:

• Transactional: Number of returns happening on a day, week, month
• Portfolio: Number of total returns that happened until end of month
• Cohorted: Number of returns cohorted on:
• The data of the related order
• The first order date of the customer who returned the item
• The date when the customer first created their account

Each tells a different story. And if you don’t define this field clearly, you’ll end up with five dashboards saying five different things - and zero trust.

The current version of the KPI Dimension Map has the Time View in column H. In the new version I add an additional column stating which point in time this refers to exactly (e.g. Return Date, Order Date, Customer First Order Date).

Why I’m Not Updating the Template (Yet)

These changes make the KPI Dimension Map more powerful - but also more complex.

Not every project needs all of them.

But if you're leading an outcome-driven data initiative, I want you to have them in your toolkit.

So you can take the original version of the KPI Dimension Map I used when I la unched my business (Data Action Mentor) and then add the new fields I just described wherever you see fit.

(And yes, the business model in this KPI Dimension Map template is outdated. But the framework? Still gold.)

TL;DR – What You Can Steal for Your Own Team

Here’s how I start every new data initiative with the KPI Dimension Map:

🎯 Anchor on a real use case​
→ Start with the business outcome, then define the metrics

🛠 Break each metric into measure + dimension + filter​
→ Makes your data model more reusable and easier to debug

📊 Label Metrics as input or output​
→ Keeps dashboard design laser-focused on action

🕰 Add a time relation field​
→ Avoid ambiguity, especially in cohort-based metrics

See you next week.

Cheers,
Sebastian

P.S. I teach this framework - and many others - in my masterclass on outcome-driven data strategy. This is where strategy meets implementati on and where firefighters turn into strategic partners.