The Problem Often Gets Smaller When I Explain It in One Sentence

Some problems arrive wearing a lot of architecture.

There is a diagram, a deck, three meetings, six constraints and a document long enough to make the problem feel important.

I have noticed that the most useful moment often comes when someone can finally say the problem in one sentence.

Not the solution.

The problem.

Complexity around a problem is not always complexity inside the problem

A system can be complicated while the failure we need to fix is narrow.

A search platform may contain caches, queues, services, databases and multiple teams.

But the immediate problem might be:

The same expensive comparison is being recomputed even when the underlying inputs have not changed.

That sentence does not solve the system.

It changes what I need to inspect.

A good problem sentence removes accidental scope

When the problem is vague, the solution space explodes.

“Search is slow” can lead to almost anything.

• new infrastructure
• a database migration
• more caching
• a new API
• another queue
• more hardware

“This endpoint spends most of its time repeating a comparison whose source data changes once per batch” gives me a very different starting point.

The sentence creates boundaries.

Boundaries make smaller experiments possible.

I separate symptom, friction and constraint

One sentence is useful only if it describes the right thing.

I find it helpful to separate three layers.

• Symptom: What do we observe?
• Friction: What repeated mechanism creates the pain?
• Constraint: What must remain true while we change it?

For example:

Symptom: The request takes 30 seconds.

Friction: A large intermediate result is recomputed for every request.

Constraint: A downstream key can change without rerunning the original job.

Now the design conversation has somewhere concrete to begin.

The one-sentence test can also stop me from building

This is the part I like most.

Sometimes I cannot write a clean problem sentence because I am actually excited about a technology, not a problem.

I want a local LLM, an agent, a vector database or a new service.

Then I work backwards to justify it.

Trying to state the friction without naming the technology is a useful check.

If the problem disappears when the technology name disappears, I may not have a problem yet.

My preferred sequence is problem → smallest experiment → architecture

I do not think every complex system can be reduced to one clever sentence.

Some problems are genuinely broad and involve competing constraints.

But compression is still useful because it exposes where the uncertainty is.

So before I reach for a large design, I like this sequence:

• Write the problem in one sentence.
• Name the constraint that prevents the obvious fix.
• Build the smallest experiment that could disprove the current assumption.
• Only then decide how much architecture the solution deserves.

The system may stay complex. The next decision does not have to be.