How to Frame a Business Problem Correctly Before Solving It

To frame a business problem correctly, state the gap in numbers, locate where it is concentrated, test the obvious solution against that evidence, and keep asking what limits the result until you reach one constraint you can act on. Write that constraint as a single sentence before anyone proposes a fix. Most failed projects solve a real symptom with a solution that never touches the constraint.

Why teams skip framing

Framing feels like delay. Someone says "sales are down 17%," and within minutes the room is debating whether to hire salespeople, cut price, or launch a campaign. The meeting ends with action items, which feels like progress.

The trouble is that the first description of a problem is almost always a symptom. It is what someone noticed, not what caused it. When you build a plan on a symptom, you spend money and weeks, and the number barely moves. Then you conclude the execution was weak, when the target was wrong.

Three habits make this worse:

• Urgency. A drop in revenue creates pressure to do something visible.
• Ownership. Each leader sees the problem through their own function. Sales sees a lead problem, marketing sees a conversion problem, product sees a roadmap problem.
• Solution anchoring. The first idea that sounds reasonable becomes the frame. This is closely related to the cognitive biases that hurt business decisions, especially anchoring and confirmation bias.

Framing is the step that interrupts all three. It takes an hour or two and costs nothing but discipline.

What a well-framed problem looks like

A good frame has four parts: a measured gap, a location, a constraint, and a decision. It reads like this:

Quarterly new bookings fell from $310K to $256K because multi-location prospects now make up half of our demos and close at 14% instead of 20%, mostly because we lack an integration they require. We need to decide by the 15th whether to build it or stop targeting that segment.

A bad frame reads like this:

Sales are down and we need more pipeline.

The first version rules out most solutions and makes a few obvious. The second invites every idea in the building.

If your problem statement contains a tool, a hire, or a project name, it is a solution wearing a problem's clothes.

Step-by-step: the seven-question sequence

Work through these in order. Write each answer down. Do not skip to question six because you already "know" the answer. That feeling is the thing you are testing.

1. What happened, in numbers?

State the gap with a metric, a baseline, and a time frame. "Bookings fell from $310K to $256K quarter over quarter" is a gap. "Sales feel slow" is not.

If you cannot put a number on it, your first task is to measure, not to solve. Even a rough count from a spreadsheet beats an impression.

2. Compared to what, and since when?

Every gap needs a baseline. Last quarter? Same quarter last year? Plan? Competitors? Then pin down when it changed. A sudden break points to an event: a pricing change, a new campaign, a staff departure. A slow slide points to drift or market change.

Ask what else changed in that window. List everything, even things that seem unrelated.

3. Where is it concentrated?

Averages hide the problem. Split the number by segment, channel, product, region, rep, or customer size. You are looking for the slice where the gap is much bigger than elsewhere.

Spend most of your analysis time here. In my experience, one cut usually explains 60 to 80 percent of the gap, and it is rarely the cut anyone expected. If you need a way to slice customers, customer segmentation methods cover the common options.

4. What fix is already being proposed, and what does it assume?

Someone in the room has a solution. Good. Write it down and ask: "For this to work, what must be true about the problem?"

If the fix is hiring two SDRs, it assumes the bottleneck is top-of-funnel volume. You can now check that assumption against the data from questions 1 to 3. Often it fails in under ten minutes.

5. What would have to be true for this symptom to exist?

Now run the causal chain. Ask why the concentrated slice behaves the way it does, then ask why again. Three or four rounds usually reach something specific. The 5 Whys method is built for this, with one caution: stop when you reach something you can change, not something you can only observe.

Also try the reverse. Ask what you would do if you wanted to make this problem worse. The answers often expose a process or incentive you have been running without noticing. Inversion thinking is useful here.

6. Which single constraint, if relaxed, moves the number most?

Name one. Not a list of six contributing factors. A system has a bottleneck, and improving anything else is mostly wasted effort until the bottleneck moves.

Test your candidate with a rough size estimate: "If we fixed this fully, how much of the gap closes?" If the answer is under half, you probably have a contributor, not the constraint. Go back to question 3 or 5.

7. What decision does this frame force, and by when?

A frame that does not lead to a decision is an essay. Finish with the choice, the deadline, and the owner. "Build the integration or stop targeting groups, decided by the 15th, owned by the head of product." This is the sentence that goes at the top of your decision brief.

Worked example: "We need more leads"

Here is a realistic case. A software company sells scheduling tools to dental clinics. It has 28 employees and about $4.2M in annual recurring revenue.

The symptom. New bookings dropped from $310K in Q1 to $256K in Q2, a decline of about 17%. The VP of Sales proposed hiring two SDRs at roughly $70K base each, $140K before commission, with about four months to ramp.

Question 1 and 2. Bookings fell $54K. The slide started in April, right when the marketing team launched a paid campaign.

Question 3. The team pulled the funnel. Demos held were flat at 200 per quarter. Lead volume was flat. So the top of the funnel was fine. Close rate fell from 24% to 20%, which means 48 deals became 40 at a steady deal size of about $6,400.

Splitting by clinic type showed why:

• Single-location clinics: 140 demos in Q1, 100 in Q2, closing at a steady 26%.
• Multi-location groups: 60 demos in Q1, 100 in Q2, closing at 20% in Q1 and 14% in Q2.

The new campaign had targeted dental groups. They were now half of all demos, and they close worse. Meanwhile the company had shifted demo slots away from the segment that converts.

Question 4. The SDR plan assumed a volume problem. Volume was flat. Two more SDRs would add demos, and under the current mix, more demos from groups would deepen the problem.

Question 5. Why do groups close at 14%? The team read 30 lost-deal notes. Nineteen of them, 63%, cited the same issue: the product did not integrate with the practice management system most groups use. Deals stalled in IT review and then went quiet.

Question 6. The constraint was the missing integration, not lead volume. Rough sizing: if groups closed at 20% again on 100 demos, that is 6 extra deals, about $38K per quarter, covering most of the $54K gap.

Question 7. The reframed problem: "Multi-location prospects are half our demos but stall on a missing integration. Decide by the 15th whether to build it or pull spend from that segment."

The outcome. The team paused the group-targeted campaign spend for six weeks, shifted budget back toward single-location clinics, and assigned two engineers for about six weeks on the integration, roughly $45K in loaded cost. The SDR hires were shelved. Bookings recovered to about $300K the following quarter.

The framing took one afternoon. The alternative was a $140K annual commitment aimed at a bottleneck that did not exist.

Common mistakes and how to avoid them

Mistake 1: Framing the problem as a solution

"We need a better onboarding flow" sounds like a problem statement. It is a project. It hides the question of whether onboarding is what's wrong. Avoid it by deleting any noun that is a tool, hire, or deliverable from your problem statement and seeing what is left. If nothing is left, you have not framed anything yet.

Mistake 2: Stopping at the first plausible cause

In the example, "conversion dropped" was a plausible cause. Acting on it might have meant sales training or discounting. The real cause sat two levels down. A good check is to ask, "Could I be wrong about this, and what would show it?" If you cannot name evidence that would change your mind, you are defending a belief, not testing a frame. Related thinking on this is in how to make better decisions under uncertainty.

Mistake 3: Framing by committee

Groups converge on the safest description, which is usually the vaguest. Draft the frame yourself, put it on one page, and ask others to attack it. You get sharper edits and a faster meeting.

Mistake 4: Over-framing

Framing is not research. Set a time box: 90 minutes for most decisions, a day for expensive ones. If you hit the box and the data is thin, write your best frame, label the weakest assumption, and plan a cheap test to check it.

A short template you can copy

Use this on the top of any proposal:

• Gap: [Metric] moved from [baseline] to [current] between [dates].
• Where: The gap is concentrated in [segment, channel, or process].
• Proposed fix and its assumption: [Idea], which assumes [belief about the cause].
• Evidence for and against: [Two or three data points each].
• Constraint: [One sentence naming the limiting factor].
• Size check: Fixing it would close roughly [X%] of the gap.
• Decision and deadline: We will choose between [options] by [date], owned by [name].

If you cannot fill in the constraint line, you are not ready to pick a solution. That is useful information, not a failure.

When to use this and when to skip it

Not every decision deserves seven questions. For a cheap, reversible choice, act and adjust. The guide to reversible vs irreversible decisions is a good filter. Use full framing when the fix costs real money, takes more than a few weeks, or would be hard to undo.

Key takeaways

• The first description of a problem is usually a symptom or a disguised solution. Treat it as a hypothesis, not a diagnosis.
• Segment the data before you theorize. One cut often explains most of the gap, and it is rarely the one you expected.
• Test every proposed fix by asking what it assumes about the cause, then check that assumption against evidence.
• Name one constraint and size it. If fixing it would close less than half the gap, keep looking.
• End the frame with a decision, an owner, and a date, so the work leads to action.
• Time-box the exercise. An hour or two of framing is cheap insurance against a quarter spent on the wrong project.