Defining the Problem

The hardest part of solving a problem is often figuring out what the problem actually is. Vague problems lead to vague solutions. Clear, specific problem definitions lead to actionable plans. This chapter explores how to move from a fuzzy sense that "something needs to change" to a well-defined problem that can be solved.

Why Defining the Problem Is Hard

Most problems start as feelings or vague dissatisfactions:

"I want to get healthier."
"Our team is not productive enough."
"The website feels slow."
"I need to save more money."

These are not problem definitions — they are problem symptoms. They tell you something is wrong but not what, specifically, needs to change, by how much, or by when.

The danger of jumping to solutions before defining the problem is that you might solve the wrong thing. Someone who says "I want to get healthier" might start an intense exercise program when their actual problem is that they sleep five hours a night and skip breakfast. A clear problem definition would have pointed them in the right direction.

From Vague to Specific

The key technique is asking sharpening questions. Each question narrows the problem from a broad feeling to a specific, measurable target.

Example: "I Want to Lose Weight"

Vague:     "I want to lose weight."
Question:  How much weight?
Better:    "I want to lose 15 pounds."
Question:  By when?
Better:    "I want to lose 15 pounds in 4 months."
Question:  Why? What is the actual goal?
Better:    "I want to lose 15 pounds in 4 months so I can fit
           comfortably in my clothes and have more energy."
Question:  What have you tried? What constraints exist?
Best:      "I want to lose 15 pounds in 4 months through dietary
           changes, since I have a knee injury that limits exercise."

Now you have a problem you can actually plan for: a specific target, a timeline, a motivation, and a constraint.

Example: "Our Team Is Not Productive"

Vague:     "The team isn't productive enough."
Question:  What does "productive" mean here? What should be happening
           that isn't?
Better:    "The team is missing deadlines on feature delivery."
Question:  How often? By how much?
Better:    "The team has missed 3 of the last 5 deadlines by an average
           of 2 weeks."
Question:  What deadlines? What features?
Better:    "The backend team has missed 3 of 5 deadlines on API
           features, averaging 2 weeks late."
Question:  What's causing the delays?
Best:      "The backend team misses deadlines because requirements
           change mid-sprint, causing rework. The last 3 delays were
           all due to late requirement changes."

Now the problem is not "productivity" — it is "requirement changes during development." That is a very different problem with very different solutions.

The Five Sharpening Questions

When facing any problem, run it through these questions:

1. WHAT specifically is wrong?
   Move from feelings to observable facts.

2. WHO is affected?
   Identify the specific people, teams, or systems involved.

3. WHEN does it happen?
   Is it constant? Intermittent? Triggered by something?

4. HOW MUCH is the impact?
   Quantify if possible. Numbers turn opinions into facts.

5. WHY does it matter?
   What is the consequence of not solving it? This reveals
   whether it is worth solving at all.

Applied Example: "The Website Feels Slow"

WHAT:     Pages take too long to load.
WHO:      Users on mobile devices, primarily.
WHEN:     During peak hours (12-2 PM and 6-9 PM).
HOW MUCH: Average page load time is 8 seconds on mobile during peak
          (vs 2 seconds on desktop and 3 seconds during off-peak mobile).
WHY:      40% of mobile users abandon the site before the page loads,
          costing an estimated $15,000/month in lost sales.

Now you have a defined problem: "Mobile page load times during peak hours average 8 seconds, causing 40% abandonment and $15,000/month in lost revenue." This is something a team can investigate, prioritize, and solve.

Problem Definition in Technology

Requirements Gathering

In software development, defining the problem is called requirements gathering. It is the process of understanding what the software needs to do before building it.

A common mistake is starting with a solution: "We need a mobile app." The sharpening questions reveal the actual problem:

"We need a mobile app."
WHY?
"Because customers can't access our service on their phones."
WHAT specifically can't they do?
"They can't check their order status or contact support."
HOW do they currently do this?
"They call our phone support line, which is overwhelmed."
HOW MUCH is the impact?
"Support wait times are 20 minutes. Customer satisfaction is at 62%."

Actual problem: Customers lack a self-service way to check order status,
creating support call volume that causes 20-minute wait times and low
satisfaction.

The solution might be a mobile app — or it might be a simple order tracking page, or automated text updates, or an FAQ section. Defining the problem properly opens up the solution space.

User Stories

User stories are a format for capturing problems from the user's perspective:

As a [type of user],
I want to [do something],
so that [I achieve some goal].

Example:
As a customer,
I want to check my order status online,
so that I don't have to call support and wait on hold.

The format forces you to identify who has the problem, what they need, and why. This prevents solutions that do not actually address a real user need.

Acceptance Criteria

Acceptance criteria define what "solved" looks like. Without them, you cannot tell when you are done.

Problem: Customers can't check order status online.

Acceptance criteria:
  - Customer can enter an order number and see current status
  - Status shows: order received, processing, shipped, delivered
  - If shipped, show tracking number and estimated delivery date
  - Page loads in under 3 seconds on mobile
  - Works on all major browsers (Chrome, Safari, Firefox, Edge)

These criteria are testable. When they are all met, the problem is solved. Without them, "done" is a matter of opinion.

The Problem Behind the Problem

Sometimes the stated problem is not the real problem. It is a symptom of something deeper.

Stated problem:    "We need a bigger office."
Why?               "We don't have enough meeting rooms."
Why?               "Teams can never find a room for their meetings."
Why?               "We have 40 recurring meetings a week, and most of them
                    are 60 minutes even though only 30 minutes of content."
Real problem:      Meetings are too long and too frequent, wasting room
                    capacity.
Better solution:   Fix the meeting culture instead of renting more space.

Asking "why" repeatedly — sometimes called the "Five Whys" technique — helps you dig past symptoms to root causes.

Common Pitfalls

Jumping to solutions

The most common mistake is skipping problem definition entirely and jumping straight to building something. "Let's build a chatbot" is a solution. What is the problem it solves? If you cannot articulate the problem clearly, the chatbot will likely miss the mark.

Defining the problem clearly is the most important step in solving it. Vague problems lead to wasted effort on wrong solutions.
Move from vague symptoms to specific, measurable problem statements by asking sharpening questions: what, who, when, how much, and why.
In technology, problem definition takes the form of requirements gathering, user stories, and acceptance criteria.
The stated problem is often a symptom. Use "why" questions to find the root cause.
Quantify the problem whenever possible — numbers transform opinions into actionable facts.
Before solving a problem, verify that it is the right problem and that it is worth solving.