An analytics team can build technically sound dashboards, develop sophisticated data models, and deliver projects against agreed timelines. Yet, when business leaders ask why profitability is declining, what is driving abnormal losses, or which operational decisions are affecting performance, the team may struggle to provide meaningful answers.

This raises an important question: Are we building analytics solutions, or are we helping businesses solve problems?

In my experience, one of the fundamental gaps in analytics delivery is not necessarily a lack of technical capability. It is the absence of business thinking in the way analytics professionals are hired, engagements are scoped, projects are delivered, and performance is measured.

We expect analysts to uncover insights, but we often hire them primarily for their technical skills. We expect them to understand business problems, but we give them tightly defined deliverables and time-bound development schedules. We expect them to create business value, but we evaluate their work largely on technical completeness.

We cannot continue operating this way and expect a different outcome.

When delivering the dashboard becomes the definition of success

Consider a familiar scenario.

A business stakeholder requests a dashboard containing an agreed set of KPIs. The analytics team gathers requirements, identifies the data sources, develops the solution, validates the numbers, and delivers the dashboard.

The KPIs are accurate. The visualisation is clean. The filters work. The deliverable meets the agreed requirements.

But what happens when the dashboard reveals that sales have increased while profitability has declined?

Does the analyst investigate the discrepancy, examine the underlying drivers, and help the business understand what might be going wrong? Or does the analyst present the numbers and leave the business user to uncover the insight?

Too often, the work stops at reporting.

The analyst considers the task complete because the agreed output has been delivered. The business user is left to interpret the numbers, connect the dots, and determine what deserves further investigation.

This creates a fundamental disconnect. The organisation has invested in analytics, but the responsibility for extracting meaning from the analysis remains largely with the people consuming the reports.

Beautiful dashboards and accurate reports are important. But they are not the ultimate objective.

The real value of analytics lies in helping the business understand what happened, investigate why it happened, and determine what deserves attention.

The problem starts before the project begins

Why do analytics professionals so often concentrate on technical delivery?

Part of the answer lies in how we hire.

Look at the typical job description for a data analyst or BI developer. It emphasises SQL, Python, Power BI, data modelling, cloud platforms, statistical techniques, and other technical competencies.

These skills matter. Without them, an analyst cannot build reliable analytical solutions.

But technical proficiency does not automatically translate into business understanding, commercial judgement, or the ability to investigate unfamiliar problems.

An analyst may know how to calculate a margin, build a profitability dashboard, and drill down into product performance without understanding how pricing decisions, customer segments, distribution incentives, and operating costs influence profitability.

The individual can execute the analysis but may not know which questions are worth asking in the first place.

We often assume that business understanding will develop naturally as people work on projects. In reality, analytics professionals may move between different industries, clients, and business processes, with delivery timelines leaving limited room to develop deeper context.

Unless the organisation deliberately creates opportunities to develop this capability, technical proficiency can grow while business reasoning remains underdeveloped.

We need to broaden our definition of a good analytics professional.

Alongside technical assessment, hiring processes should evaluate how candidates approach unfamiliar business problems. Give them a real-world scenario, ask them to investigate the underlying issues, and have them present their findings to a senior management or Board-level audience.

The objective is not to test how well they can build another dashboard. It is to understand how they think.

Can they identify the questions that matter? Can they distinguish an observation from a potential cause? Do they recognise what additional evidence is required? Can they explain the commercial significance of their findings clearly?

These capabilities should be assessed explicitly rather than left to chance.

Business thinking must be embedded in the original scope

Hiring the right people is only one part of the solution. Even capable analysts will struggle to deliver meaningful business insights if the engagement itself does not make room for them.

Many analytics engagements are structured around predefined deliverables, development milestones, timelines, acceptance criteria, and payment schedules.

These are necessary elements of project management. The problem arises when they become the entire definition of success.

If the scope specifies dashboards, reports, and analytical models but does not explicitly account for business discovery, diagnostic analysis, and insight-sharing, those activities can become secondary priorities. When delivery pressure increases, the team naturally focuses on the outputs against which it will be evaluated.

We then expect analysts to investigate business problems within a model that primarily rewards completing technical tasks.

I believe business thinking must be deeply embedded in the original engagement scope, not introduced later as an optional advisory service or undertaken only when time permits.

This means making room for activities such as:

• Understanding the client’s business model, commercial objectives, and operating processes.
• Identifying the risks and performance drivers associated with important business activities.
• Mapping operational activities to the KPIs that indicate business performance.
• Investigating unusual movements, performance gaps, and potential root causes.
• Communicating relevant findings to business stakeholders at regular intervals.
• Quantifying opportunities and establishing how the impact of recommendations can be evaluated.

These activities should be considered integral to the analytical engagement, alongside data engineering, modelling, dashboard development, testing, and deployment.

This does not mean every engagement needs an open-ended discovery phase or that every analytical finding must result in a business transformation. It means that the work required to understand the problem and derive value from the data must be planned, resourced, and priced from the beginning.

If we want analytics teams to think beyond the dashboard, we must create an engagement model that allows them to do so.

From reporting numbers to investigating business problems

Business thinking becomes visible in the questions an analyst asks and the depth to which they investigate an unexpected result.

Consider an insurance business where new policies sold have increased by 20%, while premium has grown by only 5%.

A reporting-oriented analyst might present both figures and highlight the difference.

A business-oriented analyst would recognise that the discrepancy warrants further investigation.

Assuming the figures cover comparable populations and periods, average premium per new policy has declined by approximately 12.5%. But that observation does not, by itself, explain why the decline occurred or whether it represents a problem.

The analyst needs to investigate further.

Which products contributed to the increase in policy volumes? Has the product mix shifted towards lower-premium policies? Have customer segments or distribution channels changed? Were there recent pricing decisions, sales incentives, or market expansion initiatives that could explain the movement?

The analyst must connect these findings to the insurer’s commercial objectives, profitability expectations, and risk considerations before drawing conclusions.

Perhaps the business deliberately expanded its affordable product portfolio. Perhaps a distribution initiative increased policy volumes but changed the average premium. Or perhaps the shift was unintended and warrants management attention.

The data provides a starting point. Business understanding directs the investigation.

This is why curiosity matters, but curiosity alone is not enough. Analysts need the context to ask pertinent questions, the discipline to validate their hypotheses, and the judgement to distinguish a meaningful business finding from an interesting statistical observation.

The objective is not simply to ask more questions. It is to ask the right questions, investigate the evidence, and establish why the findings matter to the business.

Structure the thinking, but don’t turn it into a checklist

Business understanding does not require every analyst to become an industry veteran. It requires a repeatable method for understanding unfamiliar businesses and the judgement to investigate beyond the initial brief.

A preliminary business understanding questionnaire can provide a useful starting point. A documented understanding of the business, a map of operational processes and associated risks, and a relationship between business activities and KPIs can help analysts understand where to focus.

But these artefacts should guide thinking, not replace it.

Completing a questionnaire does not demonstrate business acumen. Producing a process map does not guarantee that the analyst understands the commercial implications of the activities within it.

The real test comes when the data reveals something unexpected.

Does the analyst investigate the anomaly even when it falls outside the original list of questions? Do they challenge their initial interpretation? Do they engage business stakeholders to understand decisions that are not visible in the data? Do they identify relationships that were never explicitly mentioned during requirements gathering?

A structured method provides direction. An inquisitive mind determines where to go next.

Analytics leaders should therefore create an environment in which analysts are encouraged to investigate, ask questions, and challenge assumptions constructively. They should have opportunities to engage with business users and understand operational realities rather than spending most of their time coordinating requirements with IT teams.

The goal is not to create more documentation. It is to develop the habit of thinking about the business before, during, and after the analytical work.

Change how we measure success

If we want business thinking to become part of analytics delivery, we must also change how we review and evaluate the work.

A conventional delivery review may focus on whether the agreed KPIs are complete, the numbers are accurate, the filters work, and the project has met its milestones.

These questions remain important. Technical quality is not optional, and a poorly designed or inaccurate dashboard can undermine business decisions.

But technical completeness is only one dimension of success.

I would introduce a fundamental question into every analytics delivery review:

What value has our analysis created for the client, and what evidence supports that claim?

The answer should go beyond showing the dashboard or demonstrating that the requirements have been met.

The team should be able to explain what business problem it investigated, what it discovered, what evidence supports its interpretation, and what risks or opportunities it identified. Where appropriate, it should explain the recommendations presented to decision-makers and how their potential impact could be measured.

Not every engagement will immediately produce measurable revenue growth or cost savings. A valuable finding may identify a risk, establish a previously missing baseline, or provide evidence for a decision that has not yet been implemented.

We must distinguish between the value identified by the analytics team, the actions taken by management, and the business outcomes ultimately realised.

This distinction creates accountability without holding analysts solely responsible for outcomes beyond their control.

I believe three dimensions should coexist in our evaluation of analytics engagements:

Technical delivery — Was the solution accurate, reliable, usable, and delivered as agreed?

Analytical value — Did the team investigate business problems, validate findings, identify root causes where the evidence allowed, and quantify meaningful opportunities or risks?

Business outcomes — When recommendations were implemented, did they produce the intended improvements in areas such as profitability, abnormal losses, operational efficiency, or revenue?

These dimensions reinforce one another. Reliable technical delivery enables sound analysis. Sound analysis informs decisions. Measuring outcomes helps establish whether those decisions delivered the intended value.

The important shift is that analytical contribution becomes an explicit part of the definition of success, rather than an incidental benefit of delivering the technical solution.

Become a business partner, not just a technical vendor

Ultimately, the way we hire, scope, deliver, and measure analytics work shapes the relationship we build with our clients.

A technical vendor is primarily expected to fulfil a specification. A business partner is expected to understand the problem behind that specification and contribute to solving it.

This does not mean disregarding the client’s requirements or assuming that the analytics team knows the business better than its leaders. It means bringing a different level of engagement to the work.

When a client requests a dashboard, the team should understand the decision it is intended to support. When a KPI moves unexpectedly, the team should investigate the potential drivers. When the analysis reveals a risk or opportunity, the team should communicate it clearly, support its interpretation with evidence, and help the business understand the implications.

The business retains responsibility for strategic choices and operational execution. The analytics team remains accountable for the quality of its analysis and the clarity of the evidence it provides.

But the relationship changes. The team is no longer simply delivering what was requested; it is contributing to a better understanding of the problem.

For analytics leaders, this shift requires more than telling analysts to be curious. It requires hiring for business reasoning, embedding analytical investigation in the original scope, allowing sufficient time for meaningful engagement, and evaluating work on more than technical completion.

In other words, we must build business thinking into the operating model itself.

The real question for analytics leaders

The analytics industry has invested heavily in platforms, data architectures, analytical techniques, and increasingly sophisticated AI capabilities. These investments matter.

But sophisticated technology cannot compensate for an inability to understand the problem being solved.

If our job descriptions prioritise technical proficiency, our contracts reward deliverables, our project plans leave little room for investigation, and our reviews focus almost entirely on technical completeness, we should not be surprised when our teams behave like task executors.

We cannot expect business thinking to emerge consistently from an operating model that does not explicitly develop, enable, or reward it.

The question for every analytics leader is therefore not merely whether their team has the right technical skills.

It is whether the organisation has created the conditions for those skills to translate into meaningful business value.

Are we designing analytics engagements to deliver dashboards, or are we designing them to help businesses understand their problems, make better decisions, and measure the value those decisions create?