Experience and luck aren't enough. Discover the disciplined, 6-phase framework that moves data teams from being 'order takers' to true strategic partners
Intro
I doubt even a hallucinating AI born and living in data centers with mind-boggling parameters having voracious appetite for energy could add anything to the field of data analytics. However, as a non-hallucinating middle-aged man with a modest appetite for beef and single malt Scotch, I see a gap in our understanding that has not been addressed as much as it should.
Data analysts are empowered by tremendous computing power backed by gargantuan masses of good data and ever-evolving analytical methods. However, is this power harnessed in the best way? How does one know if they are solving the right puzzle and answering the right question? In other words, the question I am asking is how can we make sure the analytical process consistently delivers good analytics?
Most analytical processes seem to rely on a cocktail of experience, legacy approaches, and luck.
Experience, as invaluable as it is, could be a trap when applied to a new context or subject.
Legacy approach or the "we’ve always done it this way" could also not consistently lead to the best possible outcomes.
Luck, I assume the reader is familiar with the concept of guessing right and boardroom drama it could spark
It is baffling we don’t talk more about the structure of doing data analytics. Below, I’ve articulated my vision of how an analytical process should actually function.
As the process varies between descriptive, diagnostic, predictive and prescriptive analytics, I will focus on the diagnostic type for the sake of simplicity. We will be looking at the big picture of solving a complex problem; smaller tasks use a relevant lighter version with same principles.
Keep in mind, any topic below is huge on its own and I am only scratching the surface here.
Phase 1: Initiation and Discovery
This phase starts with the question and ends with a clear understanding of what needs to be done and a roadmap for the work ahead. The trouble is questions tend to be short, vague, broad or some non-linear combination of these. Furthermore, a request could be heavily biased by the requester's own experience and assumptions, which often is a recipe for a long walk down a dead-end street.
The goal here is to get as many as possible lines of problem description so you can read between the lines. I am only half-joking.
In all seriousness, the first and hardest challenge is resisting the urge to immediately open the data to see what is in there. Instead, your actions must be focused on ruthless discovery. Once the question hits the analytics desk, a great effort must be spent on:
Map the Context: understand the environment and reasons for the question to arise. The request could be a tiny symptom of a much deeper and broader business issue. Be aware of a hidden context lurking below.
Understand the Business: ensure very good understanding of the processes, logic and how and where the data is generated in relation to the request. Make specific inquiry to find if there had been any recent change in any of those.
Drill with the "Why": diagnose real user need. Users are notoriously bad at defining their own needs while tending to be hyper-specific and demanding. It is the data analyst's job to play both therapist and detective to find the real question and elicit the relevant details.
Define a "Good" Answer: clarify what would be considered a good answer - what does the requester expect to get - is it a single number, a narrative story, three bullet points for a slide deck or a spreadsheet with all the data. This definition should include granularity, accuracy, time-frame, etc. Remember, unclear goals are the fastest road to no bonuses.
Define the Scope: clarify the scope regarding markets, products, periods, promos, exchange rates, etc.
Standardize the Lingo: The corporate jargon not only varies between departments but also evolves over time. Ensure the definitions of the used terms to avoid any confusion down the road. For example, "active user" could surprisingly mean about four different things in two departments depending on who is holding the mic.
This may feel like an interrogation but the more we know at the start, the shorter the way to the end. Remember to act as a respectful partner to the business and not an order taker or condescending know-it-all data guru. At this phase it is essential to challenge what you hear and dive deeper if something does not make sense or is not clear enough. This phase is crucial and requires utter focus, a healthy dose of skepticism and reading between the lines.
Phase 2: Data Collection and Evaluation
Once the context is clear and the roadmap is drawn, it’s time to assess the raw materials. We need to evaluate the data required to build our answer, specifically focusing on its availability, accessibility, recency, quality, and granularity. Success here depends on these factors being within the ranges necessary to meet the scope we defined in Phase 1.
In practical terms, you will usually find your data falls into four buckets:
- Ready to Go: Data that is readily available, clean and ready to use.
- The Obstacle Course: Data is there, but requires three levels of approval and a sacrifice to a squirrel to access OR some work to extract, transform and clean.
- The External Data: Information that needs to be sourced and brought in from an external system.
- The Void: there is simply no data
It is likely that certain data issues cannot be resolved within the project's timeframe. When this happens, you must circle back to the requester to recalibrate the scope and adjust expectations. It is far better to deliver a narrowed, accurate insight than a comprehensive report built on a foundation of "best guesses."
Phase 3: Data Exploration and Setting Data Foundation
With the data vetted, the work moves from "talking about it" to "getting your hands dirty." However, this isn't about the final output yet; it’s about exploration and infrastructure. Even if the request is internal and you "supposedly" know the data well, don't get cocky. You must get acquainted with the specifics of this particular dataset to fill in the inevitable gaps. This phase is about ensuring that what you think is in the data actually matches the reality of the tables.
The goal here is to set the foundation—preparing the datasets and writing the queries, scripts, or extraction processes that will power your analysis. Keep in mind: this is not the final dataset. In the course of the next phases, you will inevitably need to make changes. Therefore, build this foundation with three rules in mind:
Document: Future-you will not remember the details—like why you excluded that one specific account three weeks ago. It doesn’t have to be "heavy-duty" documentation; a series of notes explaining the logic, the flow, and the nuances is enough.
Keep it Organized and Clean: Write your code or set up your files so that even a new joiner on the team could understand them.
Build for Flexibility: Ensure your process is easy to refresh and update. If a single change in the date range requires you to rewrite fifty lines of code, you haven't built a foundation—you’ve built a trap.
At this stage, your greatest asset is a repeatable engine. You want a setup that allows for adjustments and reuse without causing a total breakdown when the requester inevitably says, "Wait, can we also look at...?
Phase 4: Building Hypothesis
Answering the "what" and "why" in a complex environment is a daunting task if you just stare at a spreadsheet and wait for an epiphany. How many times have we heard "Just look at the data, it will tell you" as a direction? Unfortunately, this attitude does not help toward resolving an issue and we need a plan on how to interrogate data. The reality has this annoying feature to be restricted by time, resources, space and knowledge. To get results, you don’t wait for the data to speak; you ask the data to confirm or reject specific hypotheses.
But how do you build hypotheses that actually lead to a solution? You need two perspectives working in tandem:
The Logical Perspective (MECE)
To ensure your search is disciplined, the guiding principle is your hypotheses to cover the entire "solution space" without tripping over each other. In the consulting world, this principle is known as MECE: Mutually Exclusive, Collectively Exhaustive.
Mutually Exclusive: Each idea is distinct and doesn't overlap with the others.
Collectively Exhaustive: Together, they cover every possible explanation.
Example: If you’re investigating a profit issue, you split it into Revenue and Cost. There is no third option, and they don’t overlap. Simple, clean, and impossible to escape.
The Practical Perspective (The Hypothesis Tree)
How do you generate the ideas to test, aka hypotheses? From a data or statistical point of view the number of hypotheses could be daunting. However, the practical terms narrow down the potential candidates. Start by talking to people. Ask the business teams for their perspectives. Talk to as many people as possible—across different functions, roles, and seniority levels. Often, the front-line teams already know what’s broken; they just haven’t seen the proof.
Once you’ve gathered these insights, you’ll likely have a few strong leads. To make them manageable, one might need to break them down into sub-hypotheses. For example, a "Revenue" hypothesis is too big to swallow, so you split it up by product, region, or demographic. The process of splitting a hypothesis into sub-hypotheses creates a Hypothesis Tree with branches that are easier to evaluate.
The "I Don't Have Time for This" Reality Check
I’m sure this sounds like a lot for a data analyst struggling to send some figures to a nervous marketing manager by 5:00 PM. But here’s the secret: you’re already doing this instinctively usually missing the part of organizing the hypotheses which is exactly how you end up missing good ones.
If the initial hypotheses from the business don’t pan out and no good answer is found, you’ll need to generate your own. When that happens, don’t start chasing every random idea right away, no matter how clever it seems to be. You need to first evaluate it for feasibility and the "cost" in terms of time and effort. Keep in mind every organization has its sacred cow - things or people you do not question and you need the evaluation to save you from such a trap.
This phase is not a straight line—it works in a constant loop with the next one.
Phase 5: Testing Hypothesis
Now we come to the part that is usually most interesting and comfortable for the analysts.
This is where one can apply a variety of methods from simple charting and subset comparison to statistical analysis and ML models and everything in between.
However, "comfortable" shouldn't mean "undisciplined." The best approach is to start with the simplest possible method and only move to more complex ones if the outcome is not good enough. When choosing your weapon one needs to consider:
The Constraints: Does this fit our timeframe, data availability, and resources?
The "So What?": Does the method provide a definitive answer to the question? Does it meet the breadth and depth discovered in Phase 1?
The Explainability Problem: Would the business accept and understand the outcome explanation generated by the method?
The analyst must keep their eyes on the target while navigating the real-world restrictions.
Keep the Requester in the Loop
Keep the requester updated on the outcome of each hypothesis as you test it. This keeps the project on course, often generates new ideas, enriches the overall understanding of the problem and makes the stakeholders happy.
Take It One Step Further
It is quite possible for several hypotheses to prove true at once. In that case, look for the underlying factor tying them together.
Example: You find that a surge in ice cream sales is driven by a specific city, across all flavors and age groups. That’s a good "what" and may complete the initial requests. However, it doesn’t explain the "why". Digging deeper, you find out the local manager redesigned the kiosks with fresh colors and new signage that made them much more attractive.
This is a step further that provides the actionable insights to implement across other regions and move the needle further. It also differentiates the analyst from an "order taker" and turns them into a "strategic partner".
Phase 6: Delivering outcomes
As analysts, we are usually proud of our work. We want to take credit for the brilliant solutions we found for difficult problems. This makes it difficult to face the hard truth: nobody cares how you did it.
And for a good reason — the business teams are too busy running the business to stop and admire a geek talking Elvish to them. They don't want a math lecture or story of a genius-level application of some analytical method; they want reliable, actionable insights and metrics to help them run the company better.
Accounting for this reality, the delivery of results that works best follows the Minto Pyramid Principle. Instead of telling a story that builds to a climax, you flip it on its head:
Start with the conclusion/recommendation: Lead with the takeaway points. Give the answers immediately.
Provide the key arguments: Present the high-level logic that supports the conclusion.
Data & details: Finish with the granular evidence for those who want to dig deeper.
In my humble opinion, Phase 6 should be more or less a formality. Because of the active communication and "looping" through all the other phases, there should be no surprises at the end. The business has been part of the journey and this is just the final sign-off.
Closing Words
A data analyst’s value isn’t measured by the complexity of their code or the number of slides in their deck. It’s measured by the decisions they influence. To achieve that influence, the analyst needs to consistently deliver good, actionable results.
This six-phase process provides the structure necessary to deliver the highest value and quality in your outcomes. While it may require more discipline upfront, it is the most reliable way to move an analytical team from being a simple query engine to being a true strategic partner. Stop waiting for the data to tell the story—start building the framework that uncovers the truth.
