Problem Formulation: How to Define a Problem Before Using AI
How do we decide which business problem we are asking AI to solve?
Tarun Ayitam · 5 October 2026
Problem reframing examples
The elevator is slow.
How can we make the elevator faster?
How can we make the wait less unpleasant?
A mirror offers something to do while waiting. The elevator can stay the same while the experience changes.
Three illustrative scenarios. Explore another perspective.
Example 1 of 3: The elevator is slow.
What changed here? Did the elevator become faster? Why does making the wait less unpleasant feel like such an elegant solution? What had we assumed the problem was? Are real-life problems different from maths problems?
Read the full set of questions (24 more)
In mathematics, they give us problems, but in the real world, do they give us problem statements? Do we formulate the problem correctly? Is the problem that the elevator is slow, or that people dislike waiting? Would investigating why it is slow lead us to the same solutions as investigating why the wait bothers people? How do we know whether we need to investigate the cause, question our definition of the problem, or do both? Do we rush into the solution before understanding the problem?
How can we then be methodical, without rushing into the solution? Can a step-by-step process help us hold our anxiety and address problems better? Before prompt engineering helps us communicate a task, how do we decide what that task should be? Could a carefully written prompt still express a poorly formulated problem? Does our internal reference frame shape what we ask AI to do?
When we ask AI a question, what have we already assumed? What counts as a good answer to us? Which of those assumptions have we communicated, and which have we left AI to guess? If we name who did something, does that direct AI’s attention towards responsibility? If we ask for ideas, how might its answer differ from when we ask for an execution plan? If we ask it to break work into tasks, what becomes clearer, and what might we lose sight of? Could we take two minutes to examine how we are looking at the problem before reaching out to AI?
If we build a machine to solve this problem, which understanding of the problem are we building into it? Can we understand a machine in terms of its inputs, processes and outputs? Before fixing those, how could we examine different understandings of the problem? Would breaking it into smaller pieces help us see more clearly? Could that also make us lose sight of the whole? What would we need to investigate before deciding which problem the machine should solve?
Problem formulation involves identifying and articulating the problem we intend to solve, including its scope, assumptions and constraints. Oguz A. Acar describes four components: diagnosis, decomposition, reframing and constraint design. This article explores those components through Socratic questions. The steps below offer a way to practise them, with room to revisit earlier judgments. Read Acar’s explanation ↗.
Step 1. Problem diagnosis
Diagnosis involves investigating what is happening, distinguishing evidence from assumptions, and clarifying what we want to achieve. Root-cause analysis can support that investigation.
9 questions to work through
So where do we start? What would we need to know about the elevator problem before suggesting a solution? What exactly were people complaining about? Had we measured how long they waited? Could the same waiting time feel different under different conditions? What evidence would help us understand their dissatisfaction? What are we trying to achieve: a shorter wait, a more pleasant wait, or both? How would we know whether we had improved the situation? What would a useful problem statement need to make explicit?
Step 2. Problem decomposition
Decomposition breaks a complex problem into manageable parts while keeping their relationships visible.
5 questions to work through
What smaller questions would make this problem easier to investigate? Could we examine the actual waiting time, people’s expectations and their experience while waiting separately? What would we need to observe or measure for each? How might these parts affect one another? If we improved one part, how would we check whether the overall experience had improved?
Step 3. Problem reframing
Reframing examines the problem from different perspectives to discover other possible solutions.
5 questions to work through
What have we assumed by asking how to make the elevator faster? How would our options change if we asked how to make the wait more tolerable? What might we discover by considering the experience of someone who cannot stand comfortably while waiting? Which evidence would help us judge whether a different framing addresses what matters to people? Would that evidence lead us to revisit our diagnosis or the way we divided the problem?
Step 4. Constraint design
Constraint design defines the boundaries within which a solution must work, including resources, processes and output requirements.
5 questions to work through
What limits must a workable solution respect? If replacing the elevator is beyond our budget, what possibilities remain? What requirements must we preserve for people with different accessibility needs? Which limits are fixed, and which have we assumed without checking? If an AI agent could act on our behalf, what could it change independently, and what would require our approval?
Before your next prompt
If AI gives us a convincing answer, how will we check whether it addresses the problem we intended to solve? Have we given it enough evidence to question our assumptions? If it can take actions, how will we know those actions are bringing us closer to the outcome we want?
Will you choose one business challenge you are currently facing and write down your first formulation before opening AI? Can you write a problem statement for that challenge, examine its assumptions through these four components, and then write it again? Will you share your original and revised problem statements in the comments, along with what changed in your understanding?
Try the two-minute exercise
Choose one real business challenge. Write your first problem statement, examine it through the four components, then write it again. Copy your reflection to share it.
Growth hacker, organisation designer and management consultant. Has spent 15 years building growth and organisation systems inside 32+ companies, and has personally hired 200+ people across 20+ organisations. Studied Mathematics and Theoretical Computer Science at IISER Pune. TEDx speaker.
Follow on LinkedInWant to see how this applies to your company's EBITDA?