The undervalued process of problem definition
- Nova Data Analytics

- Aug 20
- 6 min read
When conducting any analysis, many of us instinctively rush to the data, tools, or algorithms. But here’s the catch: the quality of any analysis is only as good as the problems it aims to solve. A poorly defined problem can waste time and resources, while also leading to misleading and outright wrong conclusions.
Defining the problem is, therefore, not just a technical step; it’s the foundation of a successful analysis. It may feel tedious at times, but it sharpens our critical thinking skills and transforms us into deeper, more structured analytical thinkers. The truth is, every analysis becomes captivating when we’re solving the right problems.

How Do You Know There Really Is a Problem?
The danger of diving headfirst into analysis is that, after all the effort, you may realise that there wasn’t even a real problem to solve in the first place.
So what exactly is a problem?
According to Kepner & Tregoe’s classic problem-solving framework (The Rational Manager), a problem exists when there is a gap between the current state and the desired state, and that gap has measurable consequences.
From this, we can see that real problems share four characteristics:
1. There is a gap between the current and desired state
2. The gap has negative consequences (e.g invalid results, lost revenue, etc.)
3. The gap is not explained by normal variation or known factors
4. The issue is actionable (something can be done about it)
This is what separates a real problem from a perceived problem. Perceived problems are subjective, often based on assumptions, whereas real problems are supported by evidence, contextual and an understanding of root causes.
To ensure you are solving a real problem, understand the context of your problem by doing thorough research. This is critical because there is normal variation, and then there is genuine concern. Additionally, do a root cause analysis, ask why several times to discover underlying issues. This technique, known as the 5 Whys, was first developed by Sakichi Toyoda at Toyota and helps uncover the root cause rather than staying at the surface level.
And, as always, stay objective: avoid perception bias, check the literature, and look at historical data before rushing into conclusions.
Perceived vs. Real Problems
Here are comparisons to show you the difference:
Perceived Problem | Real Problem |
There is a drug resistance problem everywhere. | Drug resistance is increasing among TB patients in Southern Africa. |
Students are failing because they are lazy. | Postgraduate students in low-resource universities are struggling with online learning. |
The company is losing money because employees aren’t working hard. | Company profits have been declining over the past three quarters. |
Keep in mind these are just examples.
Notice that real problems have context, measurable details and specificity. And remember, not every problem is worth solving. Some are real, but are not a priority.
Broad vs Specific problems
An interesting perspective is whether a problem is defined broadly or specifically.
We will soon examine a table where you will notice that there is a connection between defining broad and specific problem definitions and the process of identifying both perceived and real problems. The ultimate goal in problem definition is to arrive at a specific problem you are solving.
At the beginning of your analysis, you may have a too broadly defined problem. Broadly defined problems are difficult to analyse, because they are vague, unfocused and can lead to superficial findings. In contrast, a well-defined problem is specific, measurable, and directly tied to what needs to be analysed.
Being specific does not mean you are oversimplifying; it means you are breaking down a problem into manageable parts. This approach often reveals problems within the problem, and this is where valuable insights lie.
Why does specificity matter?
It guides the type of data you need.
It sharpens your research or analytical methods.
It makes reporting and recommendations more impactful.
It prevents wasted effort on irrelevant information.
Linking real problems to specificity?
Let’s take a look at this table to show how you can go from a perceived problem to a specific one.
Perceived Problem (Assumption-Based) | Real Problem (Broad, Evidence-Based) | Specific Problem (Refined, Researchable) |
We have a drug resistance problem everywhere. | Drug resistance is increasing among TB patients in Southern Africa. | The prevalence of multidrug-resistant TB among patients receiving first-line treatment in rural clinics in Southern Africa remains poorly quantified. |
Students are failing because they are lazy. | Postgraduate students in low-resource universities are struggling with online learning. | Postgraduate students in low-resource universities face barriers to online learning, particularly limited internet connectivity and inadequate digital tools. |
The company is losing money because employees aren’t working hard. | Company profits have been declining over the past three quarters. | Profit declines over the past three quarters have been concentrated in specific product lines, regional markets, and customer segments. |
Let’s look at the first example to explain the flow from an assumption to a specific problem.
Here, the assumption is that drug resistance is a universal problem. On closer investigation, the real issue is that drug resistance is increasing in a particular region, Southern Africa. The specific problem then narrows further, making it a measurable context – prevalence in rural clinics.
Problem definitions vs Questions
You can easily confuse defining problems with asking questions. Problem definition is a statement; recall that this describes the gap between the current state and a desired state, so it is declarative. The problem definition is the “what” (statement of the issue), while the question addresses the “how/why/which”; these guide your actual analysis.
Problem definition = statement (describes the gap between the current and desired state)
Research/analysis question = question (asks how/why/which in order to investigate the problem)
Example from table:
Problem statement: The prevalence of multidrug-resistant TB among patients receiving first-line treatment in rural clinics in Southern Africa remains poorly quantified.
Research Question: What is the prevalence of multidrug-resistant TB among patients receiving first-line treatment in rural clinics in Southern Africa?
Notice how that problem statement stated the gap (“remains poorly quantified”), while the question focuses on measuring/answering that gap.
Breaking Down Real, Specific Problem
Let’s tie this altogether by looking at the TB example against the 4 characteristics of a problem.
Problem statement:
The prevalence of multidrug-resistant TB among patients receiving first-line treatment in rural clinics in Southern Africa remains poorly quantified.
1. Current State
We know that TB patients are being treated with first-line drugs in rural clinics
However, there is limited information or no precise data on how many are resistant to drugs
2. Desired State
We want accurate, quantified data on multi-drug resistance prevalence.
Data collected would enable targeted interventions, better treatment regimens and resource allocation.
3. Gap Between Current and Desired State
Lack of reliable data = knowledge gap
Without measurement, the healthcare system cannot effectively respond to multidrug-resistant TB.
4. Consequences of the Gap
Patients may not be receiving effective treatment
MDR-TB could spread undetected, worsening treatment outcomes
Policymakers and funders cannot make informed decisions
Why this is a real, specific problem?
It’s based on evidence (drug resistance is a growing concern.
It is narrowly defined (specific group, treatment type, and geographical setting)
It has measurable consequences (affects patients, policy makers, the health care system and funders)
It is actionable (data collection and analysis can close the gap)
Why Problem Definition Matters
Problem definition is not just a formality; it guides your entire analysis. Without a clear problem definition, you may encounter three significant challenges:
Wasting time and resources
Solving the wrong problem.
Producing vague, superficial insights
It’s also an iterative process. As you gather information, you may refine or adjust your problem. That’s okay; it means you’re moving closer to clarity.
Revisiting the problem throughout the analysis
Defining problems is rarely “one and done.” Expect to revisit and refine your problem statement as new insights emerge. Each iteration helps sharpen the objectives, making your final solution stronger and more relevant.
Wrapping it up
The overlooked step of problem definition is actually the foundation of impactful analysis. Defining the real, specific, and actionable problem makes everything else, data collection, methods, and reporting, fall into place.
And here’s the good news: once you’ve defined the problem clearly, you’re already halfway to crafting good questions.
In the next blog, we’ll explore how to transform problem statements into effective research questions, objectives, and goals. Stay tuned!
Further Reading & Sources
Kepner, C., & Tregoe, B. The New Rational Manager — classic on structured problem-solving and defining problems.
Booth, W. C., Colomb, G. G., & Williams, J. M. The Craft of Research — framing research problems as gaps in knowledge.
Ohno, T. Toyota Production System: Beyond Large-Scale Production — origins of the “5 Whys.”
ASQ. “DMAIC: The Define, Measure, Analyze, Improve, Control Roadmap” — structured improvement cycle starting with problem definition.
Toyota Global Site. “Genchi Genbutsu” — principle of going to see the problem in context.






Comments