What’s the first move when you’re stuck with a tough problem?
You’ve probably heard the phrase “you can’t solve a problem you don’t understand.” That’s the whole point of the opening step in the six‑step problem‑solving model. It’s not a fancy buzzword; it’s the moment you pause, look at the mess, and ask yourself exactly what you’re dealing with.
What Is the First Step of the Six‑Step Problem‑Solving Model?
In plain English, the initial step is defining the problem. Not “what’s wrong?Consider this: ” but “what exactly is wrong, for whom, and under what conditions? ” Think of it as drawing the borders of a puzzle before you start hunting for pieces. If you skip this, you’ll end up forcing the wrong pieces together and waste a lot of time Surprisingly effective..
Easier said than done, but still worth knowing.
The Core Idea: Pinpoint the Gap
The model assumes a gap between the current state and a desired state. Practically speaking, your job in step one is to describe that gap in concrete, measurable terms. “Sales are low” is a headline; “sales dropped 12 % in Q2 compared with Q1, mainly in the Midwest region, and the average order value fell from $45 to $38” is the definition you need.
Why “Define” Beats “Identify”
People often conflate “identifying” a problem with “defining” it. Definition is the deep dive that separates symptoms from root causes. Identification is the moment you notice something’s off. The difference is subtle but crucial—without a solid definition, the rest of the model is just guesswork.
Why It Matters / Why People Care
Saves Time and Money
Every extra hour you spend clarifying the problem saves dozens of hours later when you’re testing solutions. In a consulting firm I once worked with, a mis‑defined client issue cost the team an extra three weeks of analysis—and a six‑figure bill Worth keeping that in mind..
Prevents “Solution‑itis”
Ever see a team rush to pick a tool or process just because it looks shiny? Think about it: that’s “solution‑itis,” and it usually stems from a vague problem statement. When you know exactly what you’re fixing, you can match the right fix Simple, but easy to overlook..
Boosts Team Alignment
A clear problem definition is a rallying point. Marketing, engineering, finance—everyone can see the same target. In practice, that alignment cuts down on endless meetings and email threads that go nowhere.
How It Works (or How to Do It)
Below is the step‑by‑step playbook I use whenever I’m asked to tackle a new challenge. Feel free to adapt it to your own workflow.
1. Gather the Raw Data
- Quantitative metrics: sales numbers, error rates, response times, etc.
- Qualitative input: customer complaints, employee anecdotes, stakeholder interviews.
Don’t cherry‑pick. The goal is to get a panoramic view, even if some of it looks irrelevant at first.
2. Ask the “5 Ws + 1 H” Questions
| Question | What you’re looking for |
|---|---|
| Who is affected? | Users, customers, departments |
| What exactly is happening? Which means | The observable event |
| When does it occur? Think about it: | Time, frequency, seasonality |
| Where is it happening? On the flip side, | Physical location or system module |
| Why does it matter? | Business impact, risk, opportunity |
| How is it measured? |
Real talk — this step gets skipped all the time.
Write the answers in plain sentences—no jargon. If you can’t answer a question, that’s a clue that you need more data.
3. Frame the Problem Statement
A solid statement follows a simple template:
[Current Situation] + [Desired Situation] + [Impact].
Example: *“Current: Order processing takes an average of 48 hours, exceeding our 24‑hour SLA. Which means desired: Reduce processing time to ≤24 hours. Impact: Improves customer satisfaction and cuts churn by an estimated 5 %.
Keep it under two sentences. If it stretches longer, you’re probably mixing in solutions.
4. Validate with Stakeholders
Run the draft statement by the people who live the problem daily. Ask:
- “Does this capture what you see?”
- “Is anything missing or overstated?”
Iterate until you get a nod of agreement. That’s the moment you know you’ve nailed the definition.
5. Set Success Criteria
Now that you know the gap, decide how you’ll know it’s closed. Success criteria should be:
- Specific – e.g., “reduce average ticket resolution time from 72 hrs to 48 hrs.”
- Measurable – attach a metric or KPI.
- Achievable – realistic given resources.
- Relevant – ties back to business goals.
- Time‑bound – a clear deadline.
Write these down; they’ll become the yardsticks for later steps Still holds up..
6. Document Everything
Create a one‑page “Problem Definition Sheet” and store it in a shared folder. Include:
- Raw data snapshots
- 5 Ws + 1 H answers
- Final problem statement
- Success criteria
When the next person walks into the project, they’ll instantly know where you started.
Common Mistakes / What Most People Get Wrong
Mistake #1: Jumping to a Solution Too Early
I’ve seen teams sketch a new software tool before they even know why the current tool is failing. Here's the thing — the result? A half‑baked rollout that adds more complexity Less friction, more output..
Mistake #2: Confusing Symptoms with the Problem
A spike in customer calls might be a symptom of a broken FAQ page, a pricing issue, or a shipping delay. If you label “high call volume” as the problem, you’ll chase the wrong fix Less friction, more output..
Mistake #3: Over‑Engineering the Definition
Sometimes people write a dissertation‑length problem statement. Still, that muddies the water. Keep it concise; the rest of the model needs room to breathe.
Mistake #4: Ignoring Stakeholder Input
Going solo on the definition is a recipe for pushback later. If the sales team feels you missed a key nuance, they’ll resist any solution you propose.
Mistake #5: Forgetting to Quantify
A vague “we need to improve quality” statement is useless. Without numbers, you can’t tell if you actually improved anything.
Practical Tips / What Actually Works
- Use a visual aid. A simple fishbone (Ishikawa) diagram helps map out possible causes while you’re still defining the problem.
- Limit data sources to three. Too many spreadsheets turn the exercise into analysis paralysis. Pick the most reliable ones.
- Write the statement in the present tense. “Our checkout process takes 30 seconds” reads clearer than “Our checkout process was taking …”.
- Add a “one‑sentence elevator pitch.” If you can explain the problem in 10 seconds, you’ve probably got it right.
- Create a “definition checklist.” Tick off: Who, What, When, Where, Why, How, Success criteria. If any box is empty, go back and fill it.
- Schedule a 15‑minute “definition review” meeting. No PowerPoints, just a quick sanity check with the core team.
FAQ
Q: Can the first step be anything other than defining the problem?
A: In the classic six‑step model, the opening move is always problem definition. Some variations swap “define” with “clarify the goal,” but the intent is the same—pin down the gap.
Q: How long should the problem‑definition phase take?
A: It varies, but a rule of thumb is 10 % of the total project time. If you have a four‑week effort, spend about three days on a solid definition Most people skip this — try not to. Took long enough..
Q: What if new data emerges after I’ve defined the problem?
A: Treat it as a signal to revisit the definition. The model is iterative; you can loop back to step one without starting over.
Q: Do I need a separate definition for each stakeholder group?
A: No. Aim for a single, shared statement that addresses the core issue. You can add notes that highlight specific impacts on different groups.
Q: Is a problem statement the same as a project charter?
A: Not exactly. The problem statement lives inside a charter. The charter adds scope, budget, timeline, and governance details Most people skip this — try not to..
When you finally land on a crisp, data‑backed problem definition, the rest of the six‑step model feels almost effortless. It’s like having a map before you set out on a road trip—you might still hit traffic, but you won’t end up in the wrong state. So next time you’re handed a messy challenge, pause, ask the right questions, and write that one‑sentence statement. In real terms, everything else will fall into place. Happy problem‑solving!
Worth pausing on this one.
