Making room for clarity
A practical way to break a complex product problem into questions small enough to explore.
In this note
A complex product problem often arrives as a crowded sentence. It contains a user need, a proposed feature, a deadline, a technical constraint, and several assumptions. The difficulty is not always a lack of ideas. Sometimes there are too many ideas occupying the same space.
I find it useful to think of clarity as separation before simplification. Before making the problem smaller, give its different parts somewhere to stand.
Start with the moment, not the solution
“We need a better platform” is a direction, but it does not yet describe a problem someone can investigate. A more useful starting point names a person, a moment, and a difficulty.
Who is trying to do something? Where do they hesitate? What makes that hesitation costly or frustrating?
These questions do not require a polished answer. They need a description that another person can challenge. A rough sentence with a concrete situation is more useful than an elegant statement that could mean anything.
Separate what is known from what is assumed
A small table can help prevent a plausible explanation from quietly becoming a fact.
| Part | Question to ask |
|---|---|
| Observation | What have we actually seen or heard? |
| Interpretation | What do we think it means? |
| Assumption | What would need to be true? |
| Next check | How could we learn more? |
The point is not to create another document to maintain. It is to notice where confidence has moved ahead of evidence.
For a hypothetical onboarding problem, a short working note might look like this:
Question: Can a newcomer find the next step?
Assumption: The starting point is unclear.
Next check: Ask someone to explain where they would begin.
Decision: Revisit the starting point after that conversation.
This is deliberately modest. It describes a question and a way to learn, not a complete delivery plan.
Choose a useful next decision
Breaking down a problem does not mean dividing it into the largest possible number of tickets. A long task list can preserve every uncertainty in smaller boxes.
Instead, ask which decision would make the next part easier. Perhaps the team needs to agree on the intended user. Perhaps an integration is uncertain. Perhaps two people mean different things by the same word.
Addressing that uncertainty may be more useful than producing another screen or specification.
Leave room to revise
Clarity is not a promise that the first explanation will be correct. It is a shared understanding that is precise enough to test and flexible enough to change.
That is a worthwhile place to begin: one understandable problem, one visible assumption, and one next step that teaches something.
Thanks for spending a little time here.
More field notes