Spot the Job to Be Done

Identify the real problem users need solved.

What This Is

Understand the real problem users are hiring your software to solve. Before writing any code, you need to know what job users are trying to get done - not what features they say they want.

Minimum Viable Understanding

Write down: “Users want to [accomplish X] but currently [struggle with Y]”

Red flag: Building features nobody asked for wastes months of work.

The 5 Whys Test

Ask “why” five times to get past surface requests to real needs:

1. “We need a calendar app” → Why?
2. “To track appointments” → Why?
3. “Clients keep getting double-booked” → Why does that happen?
4. “Using separate calendars for each project” → Why is that a problem?
5. “Switching between them is error-prone and wastes time” → That’s the job

Good vs Bad Problem Statements

Bad example:

• ❌ “Build a calendar app”

Good example:

• ✅ “Help freelancers avoid double-booking clients when juggling multiple projects”

Notice how the good example describes the struggle without mentioning the solution.

Quick Validation Test

Can you describe the problem without mentioning your solution?

If you can’t explain the struggle without saying “they need an app that…”, you haven’t found the real job yet.

One-Sentence Maxim

“People don’t want a quarter-inch drill, they want a quarter-inch hole.” - Theodore Levitt

The drill is your solution. The hole is the job to be done. Always focus on the hole.