Problem Framing: The Decision Before the Decision

Problem framing is the decision before the decision. Every method starts with the problem already defined. Nobody asks whether the problem itself is the right one. In nearly fifty years of advising on consequential decisions, the ones that fail most expensively are those that solved the wrong problem because nobody questioned the frame.

Every popular problem-solving method begins with the problem already defined. The team sits down to brainstorm solutions, weigh options, apply criteria. Nobody asks whether the problem itself is the right one. Problem framing is the act of defining what you are actually deciding and why before evaluating options or gathering data. In the Universal Decision-Making Method that Roger Estall and I set out in Deciding, framing is Step 1: the decision that shapes every decision after it.

I have spent nearly fifty years helping organisations make consequential decisions. The ones that fail most expensively are not the ones that choose the wrong option. They are the ones that solve the wrong problem, because nobody stopped to question the frame before the work began.

Problem framing is the act of deciding what question you are really trying to answer and why before you start chasing solutions.

Click to expand

What is problem framing?

In design thinking and product development, "problem framing" often means a workshop exercise: gather the team, write problem statements on sticky notes, vote on which one to pursue. That is not what I mean. Problem framing, as a decision discipline, is the structured work of establishing what you are deciding, why you are deciding it, what outcome you intend, how long the outcome matters, and what conditions surround the decision right now.

The Universal Decision-Making Method treats framing as Step 1 because the frame determines what will later count as evidence, what options will appear legitimate, and what success will mean. The result is not a slogan on a whiteboard. It is a documented frame that the Decider and everyone involved can examine, challenge, and revise.

This is why framing is not merely preliminary. It is a decision in its own right. A poor frame does not make later analysis slightly less useful. It makes later analysis confidently wrong, which is worse. Organisations have an impressive appetite for that sort of thing.

Why problem framing comes before problem solving

The instinct in any organisation is to solve. A problem appears, and the room fills with solutions before anyone has tested whether the problem is the right one. The group leaps to options, evaluates them against criteria that feel rigorous, selects the best one, and implements it. Six months later the project stalls, and the post-mortem reveals that the problem was defined too narrowly, too late, or simply incorrectly. Solving is not deciding, and the two jobs fail differently: a room can solve all day without anyone committing to anything.

This is not a failure of intelligence or effort. It is a structural gap. The confusion between problem definition and problem solving lets teams mistake motion for progress. Most decision-making frameworks treat problem definition as a small box in a larger flowchart, then devote most of their energy to solution generation and evaluation. The ratio is backwards, especially in complex problem solving, where the first description of the problem is often the least reliable one.

I have often asked clients: "If risk management is the answer, what was your question?" The usual response is a short silence. Then someone realises that the organisation adopted a methodology without ever defining the decision it was supposed to improve. It looked like rigour. It was rigour applied to the wrong question.

The five steps of problem framing

Step 1 of the Universal Decision-Making Method has five checks: clarify Purpose, the reason this decision is worth making at all; identify the Opportunity, the opening this decision is meant to exploit; state the intended Outcome, so the room is not quietly optimising for different results; set the Duration, because a five-week decision and a five-year decision do not deserve the same frame; and establish Context, the internal, external, and wider conditions surrounding this decision now. That is the outline. The practical mechanics sit in the problem framing techniques I actually use.

Each check prevents a different kind of failure. Purpose stops a project objective from pretending to be the reason the organisation exists. Outcome stops the familiar meeting in which half the room is chasing market share and the other half is protecting margin. Context stops teams from treating the world as background scenery. It also leaves room for useful surprises; serendipity in decision making is only useful when the frame is wide enough to recognise the relevance of an unexpected input.

The point is not to make framing elaborate. The point is to make it explicit. A decision-making process model that collapses all five checks into "define the problem" is not defining the problem. It is hoping the problem will define itself, which is a charming policy and a poor discipline.

Frame the decision you are facing before evaluating any of the options sitting on your desk. Start the Walk →

What is an example of framing a problem?

A national postal service saw letter volumes falling and framed the challenge as a letter-volume problem. That frame produced the obvious answers: cut costs, improve efficiency, market letters more vigorously. None of those answers addressed the real shift, which was that digital communication had replaced letters while online shopping was creating parcel demand through the same national logistics network.

When the frame moved from "how do we protect letter revenue?" to "what is a national postal network for in a digital economy?", the same assets pointed to a different business. The lesson is not parcels. The lesson is that a different question made different evidence visible. I have written separately about cases where the wrong frame produced the wrong answer; the hub argument is simply that the example works because the question changed before the solution did.

The framing effect: how framing distorts decisions

Daniel Kahneman and Amos Tversky demonstrated in 1981 that the way a problem is presented changes the decisions people make, even when the underlying facts are identical. A medical treatment described as having a ninety per cent survival rate is preferred over one described as having a ten per cent mortality rate. Same fact, different frame, different decision.

The usual advice is to be aware of the framing effect. Awareness is a reasonable beginning. It is not a countermeasure. You cannot reliably watch yourself being framed in real time, any more than you can inspect your own blind spot while changing lanes. I have written more about how the framing effect operates in committees, where the first confident description of a problem often becomes the room's shared reality before anyone has earned it.

The Universal Decision-Making Method does not ask you to notice framing bias after the frame has already entered the room. It asks you to build the frame deliberately before evaluating options. That is the practical difference between knowing about cognitive biases in decision making and having a method that gives those biases less room to work.

Common problem framing mistakes

The recurring mistakes are dull, which is why they are dangerous. Teams start with the answer, then define a problem that justifies the favoured method. They confuse stated Purpose with actual Purpose. They treat context as generic background rather than decision-specific input. Those three alone can ruin an expensive decision without anyone raising their voice.

Another common mistake is goal fixation. Pilots call it got-to-get-there-itis: the immediate goal replaces the wider Purpose. "Arrive at the destination" displaces "arrive safely." The same substitution occurs in boardrooms when "launch this quarter" quietly replaces "launch a product that will not injure customers, destroy trust, or invite regulators to take an interest." The vocabulary changes. The error does not.

The ugliest mistake is failing to recognise a decision as a decision at all. Air New Zealand Flight 901 crashed into Mount Erebus in 1979 after amended navigation coordinates were not communicated to the flight crew. The coordinate change was treated as data entry. It was in fact a decision with consequences. Problem framing begins by noticing that a decision is being made.

A problem framing canvas for leaders

A problem framing canvas is useful only if it forces the frame into the open. It should not invite a group to decorate a wall with problem statements. It should require the Decider to record the Purpose, Opportunity, Outcome, Duration, and Context in plain language, with a date attached and enough specificity that another person can challenge it.

I have written separately about why most problem framing canvas templates launder the first mistake instead of catching it. A canvas that begins with "write your problem statement" has already accepted the problem statement. That may be convenient for a workshop. It is not much use for judgment.

The test is simple. Can the frame survive being written down? Can someone point to the assumptions it rests on? Can the team revisit it when conditions change? If not, the canvas has produced alignment, not a frame. Alignment on a poorly defined problem is not progress.

How to reframe when the frame is wrong

Framing would be straightforward if you only had to get it right once. You do not. Conditions change, assumptions collapse, and the frame that was sound six months ago may be the reason the project is now failing.

I have set out the full discipline of reframing problems mid-decision elsewhere. The signals are consistent: assumptions fail faster than the team can replace them, stakeholders in the same meeting are solving different problems, contradictory data is explained away, or nobody can agree what success now means. These are not execution problems. They are reframing signals.

The taxi industry is a plain example. GPS navigation, smartphone adoption, mobile payments, and flexible labour markets each looked manageable on its own. Together they changed what a taxi service was. Operators who treated each change as a separate irritation kept the old frame. Others saw the combined context and reframed early. The customers did not wait politely while the incumbents finished their analysis.

Problem framing is not something you do once at the start of a project and file away. It is the discipline that determines which problems get solved and which assumptions pass without scrutiny. Everything that follows the frame is execution, and no amount of good execution recovers a bad frame.

---

Grant Purdy is the co-author, with Roger Estall, of Deciding (2020), and the architect of the Universal Decision-Making Method.