Exploring the Problem Space¶

Good software work begins by understanding the problem before committing to a solution. This is easy to say and rare to practice. Most teams have a structural pressure (deadlines, stakeholder expectations, the desire to ship something visible) that pushes them toward jumping to a solution as soon as a problem is mentioned. The cost is paid later, when the team discovers they have built the wrong thing very well.

The discipline of problem exploration is the deliberate refusal to commit to a solution until the team understands what problem they are actually solving, for whom, and what success would look like. Done well, it produces simpler products, better fits, and fewer abandoned features. Done poorly or skipped, it produces the build trap.¹

Why First Solutions Are Usually Wrong¶

The first proposed solution to any problem is rarely the best one, for predictable reasons:

The problem is usually different from what was first reported. A stakeholder asks for X; the underlying need is Y; the right solution may not look like X at all. The asker is reporting a symptom in solution-language.
The team's first solution reflects their default tools. A team good at React builds a React thing. A team good at workflow automation builds a workflow. The instinct is to apply what the team already knows, regardless of whether it is the right shape for the problem.
The first solution rarely accounts for the workarounds users already have. Users facing a problem have usually built informal workarounds. The "solution" that ignores those workarounds adds friction without removing the existing friction.
The first solution is often a feature, when the answer is a removal or a process change. Some problems are solved best by deleting a feature, simplifying a workflow, or updating documentation. The reflex of building something new is sometimes the wrong reflex.

A team that explores the problem first arrives at a solution that fits the problem. A team that commits to a solution first arrives at a solution and tries to make it fit.

What Exploration Actually Looks Like¶

The work of understanding a problem is concrete, not aspirational. A few of the activities that matter:

Talk to people experiencing the problem. Not to ask if they like your idea, but to understand what they are trying to accomplish and what makes it hard.²
Watch how the work is currently done. Observed workflows show what users actually do, including the workarounds they have built. Self-report is much less reliable than observation.
Map the constraints. What rules, regulations, contracts, integrations, or operational realities have to be respected? Constraints are part of the problem, not external to it.
Identify the incentives. Who benefits if the problem is solved? Who is harmed? Whose work gets harder, even briefly, during a transition? The political shape of a problem often determines what solutions are actually viable.
Catalogue the risks. What could go wrong if we solve this badly? What could go wrong if we solve it right but in the wrong order? Risks are part of the problem space.
Find the existing workarounds. What are people doing today to cope? Workarounds reveal what the real problem is; they also constrain what solutions will actually be adopted.
Surface the operational pain. Support tickets, incidents, and recurring complaints are the most direct evidence of where the system is failing users.

The work is not glamorous. It is mostly listening, observing, and asking better questions than the team would think to ask if they were already focused on building.

Always Explore More Than One Solution¶

A single solution idea creates tunnel vision. The team commits to it, defends it against alternatives, and discovers its flaws only after building it. Generating multiple candidate solutions before committing is a small investment that consistently pays back.

The point is not to pick the best of five options through a formal scoring exercise. The point is that having multiple options changes the conversation:

Comparing solutions reveals their actual properties. A solution evaluated in isolation looks pretty good. The same solution next to two alternatives reveals what it is missing.
The act of generating alternatives surfaces the implicit assumptions in the first one. Each alternative tends to break a different assumption, and the team learns which assumptions are load-bearing.
Some alternatives are cheaper. Often the second or third solution the team considers is a much smaller, simpler version of the first one, and it solves enough of the problem.
Some alternatives are not "build something." Process changes, configuration changes, documentation, or removing features sometimes outperform building new ones. The discipline of exploring these candidates lets them win when they should.

A useful informal target: never commit to a solution until at least three credible alternatives have been seriously considered. The first one will almost never be the one chosen.

Common Anti-Patterns¶

Skipping discovery because "we already know what they want." Stakeholder confidence about what is needed is rarely justified, especially when the stakeholder has not used the existing system in months.
Treating discovery as a phase, not a habit. A discovery sprint at the start of a project, then no discovery for the next year. The team's mental model of the problem ages without being refreshed.
Validation theater. "Research" that asks users if they like an idea, generates an enthusiastic yes, and produces no new information. Real discovery surfaces what the team did not already know.
Generating alternatives in name only. Three options are presented; two are obviously bad; the third is the one the team wanted to do anyway. Real alternatives are ones the team would actually be willing to pick.
Conflating problem exploration with solution design. Discussing what is hard about the problem keeps morphing into discussing how to fix it. The two are different kinds of conversation and benefit from being kept apart.

What This Looks Like in Practice¶

Define the problem in user terms before defining the solution in feature terms. Who experiences this? What are they trying to accomplish? What makes it hard? Why does it matter to them?
Spend time with users facing the problem. Even an hour with a customer who has the problem produces more useful insight than a week of internal discussion about it.
Generate at least three candidate solutions. Including at least one that is not "build something new." Including at least one that is much smaller than the others.
Articulate what success would look like. What would change in the world if we solved this well? Without an explicit answer, the team cannot tell whether their solution worked.
Make problem exploration continuous. Discovery is not a one-time activity at project kickoff; it is an ongoing investment in keeping the team's model of the user current.³

Questions worth asking

What problem are we solving? Who experiences it? How do they work around it today? What would improve if this were solved? What would we expect to see if our solution worked?

See The Build Trap for the longer treatment. ↩
Rob Fitzpatrick, The Mom Test (2013). On how to interview customers without leading them. The book's central argument: most validation questions ("would you buy this?") produce comforting and useless answers; questions about past behavior, on the other hand, produce real signal. ↩
Teresa Torres, Continuous Discovery Habits (Product Talk LLC, 2021). The canonical articulation of small, ongoing customer research as a working practice rather than an episodic activity. ↩