Skip to main content

The problem
is sacred

Never assume you understand the problem. The real problem is rarely the one presented in the first conversation.

Statement​

You have to earn your understanding of the problem through active listening, observation, and uncomfortable questions. A misunderstood problem contaminates everything that follows, without exception.

Why it matters​

The Problem Statement is the foundation of the entire methodology. If the foundation is crooked, the whole structure tilts. It doesn't matter how sophisticated your Context Engineering is or how powerful the AI model you use: garbage in, garbage out.

The temptation to assume "we already understand" is the most expensive mistake in a project's lifecycle. Every minute invested in understanding the real problem saves hours of building in the wrong direction.

Practical implications​

  • Before writing any context, validate that the problem you have documented is the real problem, not the symptom.
  • Ask uncomfortable questions: if nobody feels uncomfortable, you probably aren't going deep enough.
  • Document the problem's evolution: the Problem Statement isn't born perfect — it's discovered progressively.
Anti-pattern: The Inherited Problem Statement

What it is. Accepting the problem as handed to you by the client without questioning, challenging, or deepening it. Typically sounds like: "The client already told us what they need, we just have to build it."

How to detect it. The Problem Statement is a copy-paste from the project brief or the client's email. No one has asked "why" more than once. There are no interviews with end users, only with the person who requested the project. The team cannot articulate the difference between the stated problem and the root problem.

How to prevent it. Apply the Five Whys technique before accepting any Problem Statement. Interview at least three different stakeholders independently. Document the problem's evolution from the initial request to the validated statement.

Connections​