How to move from advanced analytics to building analytical capability
Being the best analyst in the room is not the same as building the capability. The shift is to build the foundation that makes analytics repeatable: trusted KPIs, reusable data products and a clear path from reporting to decisions.
Most analysts are rewarded for solving hard questions. Few are told that the next step is a different job: building the foundation that lets an organisation answer those questions again and again, without one hero in the room. That means trusted KPIs, reusable data products, business stakeholders who actually use the analytics, better decisions, and a way to measure the value created. This article is about that move, from doing advanced analytics to leading an analytics transformation.
For years, my best day at work was the day I solved a hard question.
Someone would bring a messy business problem. I would sit with the data, find the answer, and send it back. People said, “You always find a way.” I loved hearing it.
Then one day I looked at it differently. If the answer depends on me, the organisation does not have a capability. It has a person. And a person goes on leave, changes teams, or simply gets tired.
Do you see the difference? Answering questions is a skill. Building the system that answers them again and again, without you in the room, is a different job. Most of us are never told that these are two jobs. We just wake up one day and find that the second one is waiting.
I will use a few moments from my own work as small examples. This is not my story. It is a map, and I hope it saves you some of the wrong turns.
Three stages, three questions
Looking back, I can see three stages in my own work. You may see yours in them.
Stage 1: Solve the question. I started as a business analyst and data researcher. My focus was simple. Understand the business problem. Decide how it can be answered with data. Then answer it correctly, with Python, SQL and Power BI. The question I asked myself was, “How do I solve this the right way?” This stage builds your craft. Do not rush it.
Stage 2: Design it end to end. Later, I worked with very large datasets in a high-pressure, campaign-style environment. Now the question changed. It was no longer “What is the answer?” It became “How should the whole thing run?” That meant thinking about data collection, with the data model quietly in the back of my mind. It meant choosing the metrics that show operational efficiency and right targeting. It meant finding insights that could actually change an outcome. And it meant something nobody puts on a CV: keeping a tired team’s morale up when the pressure is high.
One small thing from that time still helps me. Once our reports were automated with Python and descriptive analytics was sorted, the team had room to breathe. Only then could we move to diagnostic work: correlations, past trends, and then predicting what may come next. The order was not an accident. Automation bought us the time to think.
Stage 3: Build the capability. In my current work with a large client, the question changed again. It became “What do we need in place so that good analytics happens even when I am not there?” That led to work on the roadmap, the operating model, how analytics performance is measured, which AI opportunities are real, and how use cases are built to serve decisions. It also meant helping build the foundation: shared data products, standard KPI definitions, and broad data product definitions that teams could reuse and self-serve.
That path was not smooth. It was long, tiring and often argumentative, because every team arrived with a different journey and a different definition of “done.” But that is exactly where the capability was born.
The tools stay the same. What changes is the question you ask, and who is helped by the answer: first one person, then a team, then everyone who comes after you.
The four levels of analytics, and why the order matters
You have probably seen the four levels. I want to show them as one story about a decision, because that is how leaders experience them.
- Descriptive: what happened? Sales fell by 8%.
- Diagnostic: why did it happen? Two markets and three product categories caused most of the fall.
- Predictive: what is likely to happen? Sales will probably fall again next quarter.
- Prescriptive: what should we do? Move stock and change promotions in those markets.
Two things I wish someone had told me earlier. First, these are not four separate projects. Each one stands on the one before it. Second, higher is not always better. A reliable dashboard may be exactly what a leader needs, and if it is wrong, no model above it can be trusted. Choose the level that fits the decision, not the one that sounds impressive.
When you are a person doing advanced analytics, you often jump to the top. When you are building capability, you look at the whole ladder and ask where the organisation is standing today. Then ask the question that matters most: which decision will this change? An insight that changes no decision is a report, not value.
A five-step path for an organisation
If the four levels are the ladder, this is how you climb it. In large organisations, this climb is what people call an analytics transformation: a change in how the organisation asks, trusts and uses analytics, not a change of tools. I think of it as five steps, and I always begin at the bottom.
- Trust. Everyone agrees on the numbers and who owns them.
- Visibility. People can see what is happening, in one place.
- Drivers. You understand why it is happening.
- Anticipate. You can see what is likely to happen next.
- Influence. Analytics shapes the decision, and recommends the action.
You cannot recommend actions on data nobody trusts. You cannot predict what you do not yet understand. So the climb is led by maturity, not by technology. You cannot skip steps. You can only pretend to.
Where AI fits
AI does not change this order. It makes the order matter more.
Get Jaishri Rai’s stories in your inbox
Join Medium for free to get updates from this writer.
An AI assistant is only as good as what stands behind it. If two KPI definitions disagree, it will quote the wrong one with confidence. If nobody owns a document, nobody notices when it goes out of date.
I saw this while building a small assistant that answers only from governed documents, on synthetic data. The lesson was the same as everywhere else: know what you possess, write the test questions first, and keep the guardrails in code, not in hope. I am planning an intake agent that would use it as a tool. It is not built yet, so I will not claim it. The full story is in my earlier article, published on Medium, and the code is public on GitHub.
What building capability really means
Capability sounds like a big word. In practice, it is five small things that make good analytics repeatable.
1. One definition for each important number. Two teams quoting two numbers for the same metric is the fastest way to lose a leader’s trust. Standard KPI definitions, with a named owner, fix this quietly. Boring work. Very high value.
2. Data products that others can reuse. A report built once for one person is a task. A data product built once for many people is an asset. Define it broadly enough that the next team can use it without starting again. This is what makes self-service possible.
3. Repeatable delivery. Automate what is routine, so your best people spend time on thinking. I learned this when automated reporting gave my team the space to move to diagnostic work.
4. A way to choose what to build. Every analytics team has more ideas than time. Without a roadmap and a simple way to rank use cases by value, effort and dependencies, the loudest voice wins. With one, the conversation becomes fairer and calmer.
5. A way to measure value, adoption and the function itself. We measure the business. We rarely measure the team that serves it. How long does a request take? Where does it get stuck? How many requests reuse something that already exists? Then the harder questions: do people actually use what we built, and did it change a decision or save time or money? A dashboard nobody opens has delivered no value. What you do not measure, you cannot improve.
The hard part nobody warns you about
I will be honest. Building capability is slower and less glamorous than building a clever model.
There is no single moment of success. There are meetings. Many meetings. Teams disagree on what a metric means. Leaders want results this quarter, while the foundation needs a year. Your own team, who loved solving puzzles, may feel they are now “just writing definitions.”
Four things helped me.
Listen to each journey first. Every team arrives from a different place. If you start with your framework, they hear a lecture. If you start with their problem, they hear help.
Bring business stakeholders in early. Adoption is not won at launch. It is won when the business helps define the question, owns the KPI and sees its own problem solved. Analytics built for stakeholders gets viewed. Analytics built with them gets used.
Show small wins early. A single trusted KPI that every team agrees on does more for belief than a long strategy deck.
Look after the people. Capability is built by tired humans. I learned in a high-pressure environment that morale is not a soft topic. It decides whether the work continues on a hard Thursday evening.
A quick self-check, and what to take away
Ask yourself five questions. Be honest, no one is watching.
- If I left tomorrow, could my team still answer my most common questions?
- Do two teams use the same definition for our top five KPIs?
- Is what I built for one person usable by the next person?
- Do we have a clear way to decide what to build first, and why?
- Do we know how long a request takes, whether people use what we build, and what value it created?
If you said “no” to most of these, you are not failing. You are standing at the door of the next stage.
Here is what I take away.
- Solving questions is a skill. Building the system that solves them is a different one.
- Trust comes first. Shared definitions and clear owners come before prediction.
- Build for reuse, and measure value and adoption. Data products and automation free people to think. A tool nobody uses has created no value. Look after the people who run it.
I started my career asking, “How do I solve this correctly?” I now ask, “What would make this easy for the next person?” Both questions matter. But the second one is where the capability lives.
If you are on this journey, I would love to hear which stage you are in, and what is holding you back.
