← Home

Problem Framing

Frame the problem before building the system.

How a problem is framed determines what solutions become visible — and what gets built.

Problem framing fails in two opposite ways

Problems are often framed either too vaguely to act on — or too narrowly to question.

Too broad

The frame needs narrowing

We don’t have good visibility into what’s happening.

That sounds like a problem.

But what exactly is the problem?

  • a data problem
  • a tracking problem
  • a reporting problem
  • a decision structure problem

A vague frame does not guide action. It leaves the solution to guesswork.

Too narrow

The frame needs reopening

We need to build a dashboard.

Maybe.

But it could also be:

  • a data quality problem
  • a tracking problem
  • a prioritization problem
  • a decision problem

A closed frame does not test the problem. It smuggles in the answer.

The frame shapes what can be built

A problem frame does more than describe the problem. It shapes what counts as a relevant solution.

Change the frame, and the system you should build may change with it.

Too vague

A vague frame produces scattered solutions. Too many things remain possible, so action becomes guesswork.

Too narrow

A narrow frame produces premature systems. Useful alternatives are excluded before they are tested.

Misplaced

A misplaced frame makes the wrong things seem important. The system may be well built, but aimed at the wrong target.

The risk is not building poorly. It is building the wrong thing well.

Humans narrow — AI expands

Human intelligence and AI have different sets of strenghts and weaknesses

Human intelligence provides

  • relevance
  • boundaries
  • prioritization
  • judgment
  • commitment

AI provides

  • hidden assumptions
  • competing interpretations
  • adjacent strategies
  • non-obvious options
  • unrealized possibilities

AI helps explore the space. Human judgment defines the direction.

The process

How I frame problems

Before building systems, I work through five framing questions.

Question 1

What is the actual problem?

Not the visible symptom. The underlying target. What are we really trying to solve?

Question 2

What assumptions are already shaping the frame?

What is being treated as obvious? What has been accepted too early?

Question 3

What else could this be?

What alternative interpretations exist? What adjacent possibilities have not been considered?

Question 4

What belongs — and what does not?

What defines the boundary of this problem? What should remain outside the frame?

Question 5

What can now be built?

Only after the problem is clear can the system become clear. This is where execution begins.

The full approach

Most systems underperform because at least one of these steps is wrong.

Start with the problem

Good systems do not begin with implementation. They begin by making the right problem visible.