How to Break Down Any Metric with What-Questions

Home » Python » How to Break Down Any Metric with What-Questions

When a metric shows up on a dashboard, it often looks like the ultimate truth, a clean number that seems objective and unquestionable. But under that shiny surface there are modelling choices, data filters, data warehouses and lakes, definitions, time windows and assumptions that can completely change what that number really means. If we just stare at the value and move on, we are basically betting our decisions on a black box we don’t fully understand.

A much more robust approach is to learn how to break down any metric by systematically asking what-questions: what exactly is being counted, what is left out, what transformations are applied, what scenarios are considered, what stakeholders care about that metric and what “success” means for them. This way of thinking connects areas that at first glance seem far apart: business intelligence and AI agents, cybersecurity and data integrity, strategic execution, value-based goal decomposition, and even something as “mathy” as prime factorisation.

Why every metric needs to be decomposed with what-questions

Metrics create a powerful illusion of certainty. A conversion rate of 3.7%, a success rate of strategy execution, a “preparedness score” for cyber risk, an energy-cost indicator or even a number like 24 in a maths exercise all look definitive. But each one hides decisions such as:

• What population is included and what is excluded.
• What events are counted as successes, failures, threats or incidents.
• What time period is being measured and why that window.
• What transformations (aggregations, averages, normalisations) have been applied.
• What assumptions about stakeholders and value are built into the formula.

If you cannot answer detailed what-questions about a metric, you should not bet important decisions on it. The number may still be useful, but it is not yet trustworthy. Decomposition is the process of opening the black box and turning an opaque indicator into something transparent and actionable.

In data-rich environments, doing this manually for every metric quickly becomes unsustainable. That is where business intelligence platforms (for example, Power BI integrated with custom applications) and local AI agents become crucial: they help trace lineage, surface hidden filters, detect anomalies and bias, and even suggest better ways to define and track what really matters for the business.

The core habit: asking systematic what-questions

Decomposing any metric starts with a disciplined battery of what-questions. Instead of asking “Is 80% good or bad?”, you ask things like:

• What is being counted exactly? (events, users, sessions, transactions, incidents…)
• What is the unit of measurement? (percent, absolute count, dollars, kWh, days…)
• What is included and what is explicitly excluded from this count?
• What time frame does it cover and why that window was chosen.
• What transformations happened from raw data to dashboard (joins, filters, segmentations, thresholds).
• What stakeholder considers this metric valuable and what outcome it represents for them.
• What assumptions about risk, value, behaviour or environment are embedded in the calculation.

This simple habit instantly separates signal from noise. Many “key” metrics turn out to be partial views, misaligned with business objectives or simply legacy artefacts that survive because nobody questioned them. Others become clearer, better defined and easier to improve once the underlying what-structure is explicit.

Modern BI stacks make this what-analysis drastically easier. With well-designed data models and tools for lineage and auditing, you can click on a metric and see what tables, filters and calculations sit behind it. AI agents can then scan for inconsistencies (for example, a definition of “customer” that is different in two dashboards) and flag potential misalignment with the intended business meaning, often using real-time data analysis to detect anomalies.

From dashboards to decisions: BI, AI and custom software

Visualisation alone is not enough; understanding is the end goal. A glossy dashboard in Power BI or any other tool can look impressive and still mislead everyone in the room if the underlying questions of what are not clear. That is why mature organisations move beyond front-end charts and invest in automation and MLOps practices:

• Well-governed data models where every key metric has a documented definition and clear lineage.
• Automatic checks for anomalies, outliers and suspicious jumps, often powered by AI.
• Custom integrations between BI tools and bespoke systems, so metrics are calculated close to where processes actually happen.
• Cybersecurity layers that protect the integrity and confidentiality of data throughout its life cycle.

Combining cloud platforms like AWS and Azure with tailored software unlocks a powerful ecosystem. You can design pipelines where each metric is linked to its data source, transformation steps and stakeholder, and where what-questions can be answered on demand: what query generated this KPI, what filters were active, what model predicted this forecast, what training data powered that model, what threshold triggered this alert. These architectures should also help regain control of APIs and integrations.

AI for business adds an extra dimension: patterns and predictions. Once the basics of data quality and traceability are in place, AI can enrich your what-questions with forward-looking insights: what customers are likely to churn, what projects are likely to overrun, what cost items are trending up, what threat scenarios are gaining probability. The questions stay rooted in what, but the answers now incorporate trends and probabilities rather than just static snapshots; adopting AIOps practices can operationalise these insights.

All of this only works if the organisation also invests in clear definitions and shared language. Data engineering, AI, BI, cybersecurity and business owners must agree on what “revenue”, “threat”, “ready”, “success” or “value” mean in each context. Without that, the tech stack simply automates confusion.

Why strategies fail: messy objectives and misleading success metrics

There is a popular claim online that between 63% and 87% of strategies fail. These eye-catching numbers come from old studies where companies reported disappointment with financial outcomes or under-delivery against strategic promises. When you look closely, the data is patchy and the conclusions exaggerated: we simply do not have a precise, scientifically solid failure rate for strategy execution.

What we do know is that many organisations are unhappy with how their strategies translate into results. A big chunk of that dissatisfaction has been traced back to poorly formulated objectives and to metrics that focus narrowly on financial numbers, while ignoring stakeholder value and clarity of intent. In some surveys, around half of reported “failures” are blamed directly on vague or ambiguous goals.

Badly described strategies are also extremely hard to communicate. Research linked to the Balanced Scorecard framework suggests that in many companies up to 95% of employees cannot state or do not understand the strategy. If people do not know what they are aiming for, it is almost impossible to define good metrics, never mind decomposing them with what-questions.

Strategy frameworks such as the Balanced Scorecard help to structure thinking around three big building blocks:

• Ends: goals, objectives, desired outcomes.
• Means: initiatives, projects, action plans.
• Quantifications: metrics, KPIs and indicators.

The quality of strategic execution depends on how clearly you can separate and then reconnect those three blocks. Ends say what value you want to create for stakeholders, means describe how you will try to do it, and metrics quantify how well you are doing. When objectives are fuzzy, or when means are baked into the wording of the goals, decomposition becomes a mess and metrics drift away from real value.

Value-based decomposition of ambiguous objectives

To fix ambiguous strategies, you need to decompose them around one central idea: value for stakeholders. Instead of treating objectives as slogans, you break them into smaller, independent sub-objectives that are each tied to a concrete stakeholder and a clear notion of value that can be quantified.

One practical definition of strategy decomposition is this: breaking down high-level, fuzzy objectives into small, independent sub-goals that are explicitly measured by the value they create for specific stakeholders. This is not a mechanical exercise; it is half analytical, half creative, much like the balance between planning and genuine strategic thinking that Henry Mintzberg described.

To prepare for value-based decomposition, three steps are essential:

• Separate ends, means and metrics so you are not mixing aspirations, actions and measurements in one sentence.
• Understand stakeholders and their needs (customers, employees, management, regulators, partners, etc.).
• Simplify language and define terms so everyone shares the same understanding of key concepts.

Consider a typical messy strategic objective: “Leverage technical expertise to improve the organisation’s preparedness for high-priority threats by 20% within 1 year.” At first glance, it sounds serious and measurable. Under decomposition, you discover that it actually bundles together:

• The end: improving organisational preparedness for threats.
• A target: 20% improvement.
• A time frame: within one year.
• A means: leveraging technical expertise (one possible approach among many).

This is problematic for several reasons. The 20% is usually an aspiration, not grounded in analysis of what is feasible or valuable for stakeholders. The one-year window is often driven by budget cycles, not by risk dynamics. The inclusion of the means (“leverage technical expertise”) inside the objective closes off alternative, potentially better approaches.

A cleaner objective after decomposition might be simply: “Improve the organisation’s preparedness for threats.” The what-questions then become: what does “preparedness” mean, what types of threats matter, what stakeholders care most, what metrics can we use to quantify preparedness, and what sub-objectives are needed to move those metrics.

Clarifying stakeholders, terms and language

Once you strip the fluff out of high-level objectives, the next step is to be precise about who and what we are talking about. For our preparedness example, the relevant stakeholders could include (and be measured using data analysis with SQL):

• Leadership team, worried about strategic and financial impact.
• Employees, such as IT, HR, legal teams and new hires exposed to new work models.
• Customers, exposed to service disruptions or data breaches.
• Regulators, focused on compliance and risk management.

Language simplification helps eliminate vague corporate speak. Words like “leverage” can usually be replaced with “use”; “technical expertise” should be defined (security skills, infrastructure know-how, compliance knowledge, etc.); “high-priority threats” require either a clear risk-rating scale or a precise list of threat types.

We then answer concrete what-questions about our key terms:

• What exactly do we mean by “preparedness” from each stakeholder’s point of view?
• What threats do we actually care about and how do we classify them?

One possible working definition of preparedness could be a set like: {threat analysis carried out, prevention plan in place, response plan documented, recovery plan tested}. Threats could be categorised as {climate-related, cybersecurity, social change (such as remote work), energy-related}. These definitions can be embedded directly into your strategy map or scorecard, or described more formally with planning notations like Planguage if you prefer rigorous specification.

After this clean-up, the original objective is reformulated to the simpler “Improve the organisation’s preparedness for threats”, with “preparedness” and “threats” clearly defined. From there you can begin to decompose the objective by stakeholder value, not by buzzwords.

Value-based decomposition vs process-based decomposition

Many organisations instinctively decompose objectives by process, not by value. Think of learning a foreign language in a traditional school system: you go through grammar chapters, vocabulary lists and structured exercises. The value to students (being able to handle real-life situations) is often only tested much later, in exams that do not fully reflect real conversation.

Value-based decomposition flips this logic. Instead of starting from processes (“study grammar, then vocabulary, then practice”), you start from the concrete situations that matter most to students: ordering food, handling travel issues, socialising, working in the language. Then you bring in grammar and vocabulary only as needed to support those value scenarios.

The same principle applies to business strategy. Decomposing by value means:

• Delivering value faster, because sub-objectives are tied to real stakeholder needs.
• Gaining better resource control, since budget and effort are aligned with specific value-creating initiatives.
• Shortening learning cycles, as each small sub-objective provides quick feedback on whether assumptions about value were right.

You stop decomposing when two conditions are met: you have reached the level of actionable tasks, and you can quantify the value for the relevant stakeholders with meaningful metrics. Before that, you keep breaking the high-level goal into smaller, independent pieces.

This line of thinking is visible even in highly complex engineering endeavours. When Elon Musk describes building a city on Mars, he decomposes the goal into smaller sub-goals: fastest path to a fully reusable rocket, then fastest path to orbit, then to reliable manufacturing, and so on. The Starship design itself splits a huge propulsion problem into many smaller engines instead of one giant one. The same logic should guide how you break down a vague “improve preparedness for threats” into workable chunks.

Concrete examples: decomposing preparedness into small, measurable sub-goals

Imagine you want to improve preparedness for social threats connected to remote work, including risks from compromised IDE extensions such as those described for developer environments; a focused security review and mitigation plan can be one branch of decomposition (compromised IDE extensions).

At this level, you can formulate more concrete risk and initiative statements. For example, one specific risk might be “legal risks of cross-border remote work”. A value-oriented initiative could be “update employment contracts to include an intellectual property transfer clause for remote employees in different jurisdictions”.

These initiatives are short-term, specific and deliverable. They do not solve all remote work risks at once but they do move the needle on a part of preparedness that legal teams and leadership actually care about. Note how the decomposition has transformed a vague aspiration into a tangible, testable step.

Decomposing by value also allows independent progress on different fronts. Another branch of the preparedness tree might focus on energy-related threats, such as volatile energy prices. A sub-objective there could be “preparedness for energy costs”, with a practical initiative like “develop a plan for installing photovoltaic capacity”.

As long as the sub-objectives are largely independent, different teams can work on them in parallel. HR and legal can handle contract changes for remote workers while facilities and finance explore solar feasibility, each guided by its own set of what-questions and metrics linked to stakeholder value.

Quantifying value: from high-level aims to concrete metrics

Decomposition is not complete until value can be measured in a meaningful way. That does not mean you need perfect metrics, but you do need indicators and to optimise queries for performance that capture what stakeholders actually care about, without being absurdly expensive to measure or impossible to interpret.

Take the earlier example of “preparedness for remote work”. For the leadership team, one meaningful outcome metric might be “time to full performance for new hires”, especially for those working remotely. A shorter ramp-up time signals that the organisation is better prepared to onboard and integrate remote talent.

For HR and new employees, more operational indicators could matter more. For instance:

• Adoption rate of strategy execution tools by new hires, %.
• Share of teams using outcome-based performance measures, %.

Each of these what-metrics is tied to a specific initiative or set of initiatives. The percentage of outcome-based performance measurement might be associated with something like “establish a single source of truth for project and strategy performance” and training managers to use it.

For “preparedness for energy costs”, a different metric set applies. After initial analysis, you might track:

• Current energy demand, in kWh.
• Expected energy output of a planned photovoltaic installation during winter months.
• Percentage of demand covered by PV capacity.
• Cost avoided, in monetary units, compared to baseline prices.

Sometimes the most practical indicator of value is a complexity comparison. Consider a homeowner deciding whether to install security cameras. They might not build a complete risk model, but they can still reason in what-terms: the complexity of installing cameras and occasionally checking alerts is lower than the complexity of hiring someone to physically monitor the property. When an extreme weather event actually hits, and the camera reveals furniture being blown onto a public road, the value of that decision suddenly becomes very tangible.

Using learning cycles to refine decomposed metrics and goals

Decomposition is not a one-time design task; it is part of an ongoing learning cycle. Once sub-objectives and metrics are in place, you monitor the gap between expected and actual results and refine both goals and measurements in light of evidence.

A practical learning loop around decomposed objectives often includes:

• Reviewing differences between expected and achieved outcomes for each sub-goal.
• Identifying root causes rather than stopping at surface explanations.
• Adjusting metrics if they are driving the wrong behaviour or not capturing stakeholder value.
• Adding new sub-objectives or branches when you discover previously hidden factors.
• Revisiting the top-level objective if evidence suggests it was framed around the wrong problem.

Throughout this cycle, the discipline of what-questions keeps you honest. What changed in the environment? What assumptions turned out to be wrong? What new data do we have? What part of the decomposed structure is no longer valid? By systematically asking and answering these questions, teams can avoid stubbornly clinging to an elegant but ineffective decomposition.

Software support can make this iterative refinement much more efficient. Tools like BSC Designer or similar strategy management platforms let you maintain a hierarchical tree of objectives, metrics, initiatives, risks and hypotheses. You can assign weights to sub-goals that represent their relative importance for stakeholders, and adjust those weights as you learn more from the data.

Practical tooling for goal and metric decomposition

Specialised software for strategy execution and scorecarding helps operationalise everything described so far. Instead of keeping your decomposition on slides or in spreadsheets, you maintain a live structure that connects objectives, stakeholders, metrics and initiatives.

Some practical features that support what-based decomposition include:

• Profiles or views that show only the essential columns for decomposition: objective names, indicators, initiatives, stakeholder fields, units of measure and weights.
• Fast creation of new objectives and sub-objectives (for example, keyboard shortcuts for adding items at the same or next level).
• Dedicated fields for initiatives, risks and hypotheses, with icons or markers to distinguish them.
• Commenting on each element to capture insights about assumptions, constraints or stakeholder feedback.
• Weight columns in a performance tab to represent the relative importance of sub-goals.

Weighting is especially useful when stakeholders have many competing needs but limited resources. After initial experimentation, you can assign intuitive or analytically derived weights to sub-objectives such as “preparedness for energy costs” versus “preparedness for limitations on energy usage”, reflecting their relative importance for leadership at that point in time.

Automation can also assist in prioritisation. Once you have value metrics and relative weights, simple prioritisation frameworks or more advanced optimisation models can help decide where to allocate budget and attention. Still, the quality of these decisions hinges on how well your decomposition reflects real stakeholder value and how rigorously you maintain your definitions and what-questions.

Across all of this, security cannot be an afterthought. As you collect, integrate and quantify sensitive information about operations, risks and performance, cybersecurity services must protect the integrity, availability and confidentiality of the data. If someone can tamper with underlying data or with the calculation logic, all your carefully decomposed metrics become unreliable.

Ultimately, the strength of any decision rests not on the visual shine of a dashboard, but on your ability to break every metric and every objective down into their essential components. When you can answer precise what-questions about definitions, inclusions, exclusions, transformations, stakeholders and assumptions, you transform numbers from decorative elements into trustworthy signals. If you cannot do that for a given indicator, that is not a reason to give up; it is your cue that the metric needs to be redefined, reconstructed or even discarded so it actually serves the real goals of your organisation.