Introduction
In "Solutions Disguised as Problems," we talked about how teams often implement requests without understanding the actual need behind them. This is the practical companion to that article: a simple checklist you can use before committing to work.
Think of this as a filter. Seven questions. Seven minutes. Run through them with your team before you estimate, before you add something to the backlog, before you start designing or building. If you can answer these questions clearly, you probably understand the problem well enough to move forward. If you can't, you've just saved yourself from building the wrong thing.
This isn't comprehensive discovery. It's a quick validation to catch obvious waste before it becomes a problem.
Purpose
A quick validation checklist to run before committing to work. Helps teams avoid building solutions to unclear or unimportant problems.
When to use it
Before estimation, before adding something to the backlog, before starting design or development.
The Test
Run through these questions as a team. If you can't answer them clearly, you probably don't understand the problem well enough to start building.
1. What is the problem this is intended to solve?
Can you state it without referencing the solution?
Is this a real problem or a requested feature?
2. Who has this problem?
Be specific. Not "users" but which users?
How many people does this affect?
3. What would this enable them to do?
What outcome are they trying to achieve?
Why does this matter to them?
4. How are they achieving those outcomes today?
What's their current approach?
If they're not achieving it, why not?
5. What happens if we don't solve this?
What's the actual impact?
Is this urgent or just nice-to-have?
6. Once this is in place, what stories would you hear?
What would users say about it?
How would their behavior change?
7. How could we objectively verify those stories?
What can we measure?
What can we observe?
8. What would this enable you to do?
What outcome are you trying to achieve?
Why does this matter?
Interpreting Your Answers
If answers are clear and specific: You likely understand the problem. Move forward with confidence.
If answers are vague or uncertain: Pause. Either get more information or decide not to build it yet. Vagueness often means the problem isn't real or isn't important.
If you can't answer #6 or #7: You won't be able to validate whether your solution works. Consider whether that's acceptable before proceeding.
When to Stop
Nobody can clearly articulate who has the problem
The impact of not solving it is minimal
The current approach is "good enough"
You can't define what success looks like
Stopping isn't failure. It's avoiding waste.