The Skill Gap Hiding Behind Power BI Adoption

Key Takeaways

• Greater Data Access: Power BI made data accessible to more people
• Data Fluency Required: Knowing how to build a report is different from understanding the data it shows
• Ask Deeper Questions: Four types of questions to ask of your data, depending on the scenario
• Three Skills, Not One: Proficiency, literacy, and reasoning are different skills
• Training Builds Data Fluency: Using Power BI daily won't teach the skill; training does

Monday morning, a manager pulls up three dashboards for a check-in, and none of them agree. A year ago, there was an analyst down the hall to sort it out. Now the manager must work out the discrepancy alone, and decide what it means before the meeting starts.

Power BI handed reporting directly to people who'd never built a report before. Marketing coordinators build their own campaign views, while account managers track pipelines without waiting on anyone else. A manager checking dashboards must read them correctly, taught or not.

What matters is what a person does once the numbers are in front of them: which question to ask next, and what the answer could change about their decisions.

Four questions sit underneath the numbers: what happened, why it happened, what's likely to happen next, and what to do about it. Many people get comfortable at the first one and stop there. What separates a team that reacts from one that gets ahead is whether all four get asked.

Every Role Is a Data Role

Not long ago, building a dashboard meant filing a request with the data team and waiting for them to create it. Power BI now handles natural-language queries and automated visualizations that used to require a specialist, with Copilot pushing that even further. Building a report takes a few clicks instead of waiting on a request in a queue.

Here's how data analysis changed:

• Then: an analyst builds the report, a manager reads the conclusion and makes a decision
• Now: a manager explores the data, filters it, notices what's off, decides if it matters, and explains the finding to someone else

This shift in who performs the data analysis put report-building directly into the hands of the people who need the answers, and ownership of the thinking moved with it. Where a wrong conclusion used to be an analyst's problem to catch, a manager reading the dashboard today gets the chance to catch it first, explain it, and act on it before anyone else does.

A coordinator catches a stalled metric before a manager asks about it. Somewhere else, an account manager flags a slipping deal before it ever reaches a pipeline review. The tool made both possible.

It wasn't only an ownership handoff. Data fragmentation and competition added additional pressures. Teams pull from multiple platforms instead of one source of truth, and waiting on someone else to build a report slows decisions down when speed matters most.

These pressures sped up a shift that was already underway. More people started working directly with the data, beyond analysts alone. Business intelligence shifted from a specialized function to a baseline skill, for managers and the people who report to them alike.

All of this adds up to one conclusion. People need to ask deeper questions of a dashboard's data to turn numbers into good decisions.

The Four Questions Your Team Should Be Able to Answer

To reach the best decisions, teams need to ask more than surface-level questions. Many teams ask only one when they pull up a report to see what happened, because nobody showed them they should ask deeper questions. Dashboards show descriptive data; the story behind it takes more digging.

Diagnostic, predictive, and prescriptive questions make up the remaining three layers. A team that only ever answers the first question is working with a quarter of what the data can tell them.

Descriptive (What Happened?)

It's the easiest layer to reach since dashboards tend to reveal it first. It's concrete and easy to agree on, which makes it feel like an answer, even though it's a surface-level observation. What to do with that number is a separate question entirely.

Example: Sales dropped 12% last month.

Diagnostic (Why It Happened?)

Diagnostic separates correlation from explanation, the main driver behind a repeated number. Sales dropping the same month a competitor launched a promotion doesn't mean the promotion caused it. Isolating the underlying driver takes the kind of segment-by-segment filtering that belongs to a Power BI report, distinct from a dashboard's summary view.

Example: A key account delayed a renewal.

Predictive (What's Likely to Happen Next?)

People often mistake this for certainty instead of probability. A forecast is an estimate built on how similar situations played out before, the same principle behind the time series and regression models used in business forecasting. Power BI's forecasting tools show a range of outcomes.

Example: The delay could push into next quarter without intervention.

Prescriptive (What to Do About It?)

Prescriptive is easy to misread as the software making the call. Power BI narrows the options down to better choices, with the decision still belonging to the person reading it.

Example: Reach out to the account now instead of waiting for the renewal date.

These four questions are useful no matter what data someone is looking at, from a campaign report to a pipeline forecast. Understanding how to apply them is an important next step.

The Four Questions in Practice

How many of the four questions get asked, and in what order, depends on the scenario. A single decision might only need diagnostic thinking; another might skip straight to prescriptive. In each example below, the person asking is outside a traditional analytics role, closer to the day-to-day realities the data reflects.

Marketing

A campaign coordinator notices cost per lead climbing week over week. At first glance, the obvious explanation is creative fatigue: the same ad has been running for a month, and audiences have tuned it out. That assumption would normally end things there, the kind of snap judgment that confirmation bias makes feel more certain than the data backs up.

Instead, the coordinator breaks the number down by channel first. Email and search are performing exactly as they were a month ago. Paid social is the only one that's slipped, enough to drag the overall average down with it. A fatigue problem would hit every channel at once.

A quick forecast shows where this is headed: if paid social keeps declining, overall cost per acquisition keeps climbing with it, driven by one channel and not the whole campaign.

Instead of pulling back spend everywhere, the coordinator reallocates budget away from paid social and into the two channels still working.

Sales

An account manager sees three deals stalled at the same stage. The easy explanation is that all three prospects have gone cold.

The account manager checks where each deal sits in the process instead of taking the stall at face value. All three are past the discovery and demo stages, but waiting on pricing approval. Paperwork is holding up all three deals.

Predictive data on similar stalls shows deals rarely close on their own once they've sat this long without movement. Left alone, inertia is what kills the deal.

The account manager escalates the pricing approvals directly and follows up with each account personally, closing the gap instead of waiting for it to close on its own.

Operations

A manager reviewing team utilization sees one person consistently overbooked while a teammate has open capacity. A quick interpretation is that the overbooked person works slower than everyone else.

Looking closer, the manager finds two recurring tasks on that person's schedule that don't appear on anyone else's, tasks nobody formally assigned.

The workload split is driving the imbalance. A faster worker in the same spot would still be overloaded.

Prescriptive output suggests redistributing those two tasks to the teammate with room. The decision comes down to which specific tasks move, to whom, and why the imbalance built up in the first place.

Each of these examples shows the benefit of asking a deeper question of the data instead of relying on the surface-level numbers a dashboard hands over first. Those questions were a judgment call made by the person reviewing the data.

Adoption Also Means Understanding Data

Before self-service tools, making judgment calls about the data belonged to the analyst who built the report and delivered the conclusions. Power BI moved that ability from specialized analysts into any job role.

Access is half of adoption. Understanding the data is the other half.

The Adoption Trap

This shift plays out the same way in various organizations: leadership buys the platform, adoption climbs, and dashboards multiply. That's real momentum. Organizations often miss the next step, the one that turns all those dashboards into better decisions.

A team can have twenty dashboards, updated daily, and still make the same calls it made before any of them existed. The platform delivered exactly what it promised: visibility. Visibility alone doesn't translate into better judgment. What usually blocks it is a mix of not knowing what a metric means, not seeing how it connects to the role, and not knowing what to do next, the three gaps that keep well-built dashboards from getting used.

Self-service tools already granted access. But a team still must build the skills to make that access meaningful, instead of assuming they'll develop on their own once a manager hands over a login or a team starts using a dashboard regularly.

Three Different Skills

Understanding the data breaks down into three distinct pieces mistakenly treated as one. The software can calculate a trend line, flag an anomaly, or forecast a range. Asking why the trend exists, or what to do differently because of it, is a skill that belongs to the person reading it.

It helps to look at each skill and what they require:

• Proficiency: knowing how to build a report
• Literacy: understanding what the numbers mean
• Reasoning: knowing what to ask next

Someone can have the first without the other two, which is how a team ends up with dashboards everywhere and no better decisions to show for it.

This is where a Power BI rollout has real room to grow. A team goes through training, comes out proficient, and starts building reports on schedule, real progress worth having.

Proficient use of a tool doesn't tell someone whether a spike in the data is meaningful or noise. Meetings start to look more analytical because there are more dashboards, and they'd get sharper still if people asked deeper questions of what's already there.

Data fluency is the differentiator. Two people can open the identical report: one closes the tab once the number loads, the other keeps asking questions until they land on a next step. That's a learnable skill, and one that pays off in every report your team touches.

Closing the Gap Between Having Data and Using It

What matters now is whether the teams using Power BI know what to do with what it shows them.

Closing this gap takes effort. Using a dashboard daily builds proficiency. Reasoning, the skill of knowing what a number means and what to do next comes from practice: pulling a total apart to see what's driving it, checking whether that holds up, and doing it again the next time a number needs a second look.

Building it requires training and repetition like any new skill, and it shows up through better questions that lead to better decisions.

A data-fluent team looks different day to day:

• Meetings: real questions instead of readouts
• Anomalies: investigated instead of shrugged off
• Metrics: shared definitions across departments, so conflicting dashboards become rare
• Trust: people trust the data because they understand it

New Horizons partners with organizations to build fluency in their teams: how to move from a number on a screen to a decision worth making.

Is your team asking all four questions, or only the first?

Talk with New Horizons about building data fluency in your team to turn dashboards into decisions.