Are You Solving the Right Problem? A Guide to Problem Discovery

Sometimes we get it wrong. We know we are getting it wrong, and yet the sunk-cost fallacy keeps us going. When Thomas Wedell-Wedellsborg surveyed over 100 C-suite executives across 91 companies in 17 countries, 85% agreed their organizations were bad at diagnosing problems and 87% agreed that this flaw carried significant costs (HBR, Jan–Feb 2017).

Read that again. These leaders are not saying their teams were bad at solving problems. Most organizations are full of capable people who can execute. They were saying their organizations routinely execute well against the wrong problem, and it is costly.

This is why so many programs underperform, products miss, and funded initiatives fail to move the needle. The expensive mistakes don't happen during execution. They happen earlier, quietly, when someone frames the problem, and everyone else starts solving it. The issue with that is often that really smart people are solving the wrong problem.

The slow elevator, and why framing is everything

Wedell-Wedellsborg's now-famous example: tenants complain that the office elevator is too slow. Framed as "the elevator is too slow," the solutions are expensive: replace the motor, upgrade the system, install a new elevator.

Reframed as "the wait is annoying," a different solution appears: put up mirrors. Complaints drop to nearly zero. Nobody made the elevator faster. They solved a better version of the problem.

The point of reframing isn't to find the one "real" problem hiding underneath. It's to ask whether there is a better problem to solve one where your budget buys an outcome instead of an expensive treatment for a symptom.

Now scale that up. An economic development organization sees local businesses struggling and frames the problem as "businesses need more funding." A product team sees churn and frames it as "we need more features." A nonprofit sees low enrollment and frames it as "we need better marketing." Each frame dictates a solution: a loan program, a roadmap, a campaign and each solution may be built on an untested assumption.

Symptoms get surface solutions.

Surface-level problems produce surface-level solutions, and the pattern is predictable:

The visible problem is what shows up in a board meeting: declining enrollment, slow business growth, low product adoption. The real problem is what's actually driving that result, and it's often two or three layers down, invisible until you go looking for it.

Businesses may not need more capital; they may need customers, or childcare for their staff, or a regulation changed. Users may not want more features; they may not understand the three you already built. This is where addressing the Say-Do Gap is essential. The Say-Do Gap is the gap between what people say they will do and what they actually do.

When you solve the visible problem, results don't improve, because the real problem remains. Then the organization concludes the program "didn't work" when the truth is the program worked fine against a problem that didn't matter.

This is the pattern behind the failure statistics we cover in Why Most Initiatives Fail Before Execution: the initiative was lost at the framing stage, months before anyone executed anything.

The problem discovery process

Problem discovery is the structured work of finding what's actually driving or limiting results before a solution is chosen. It's not a brainstorm, and it's not a survey. Done well, it combines three practices drawn from two decades of research, and it's the first phase of everything we do at Ground Floor Labs.

1. Reframe before you diagnose

Wedell-Wedellsborg's research offers seven practices for reframing. The five we find most powerful in program and product contexts:

Get definitions in writing. Ask each stakeholder to write down the problem in their own words, separately. The differences between their statements are where the real conversation starts, and in our experience, the statements rarely match.

Bring outsiders in. People inside the frame can't see the frame. An outside perspective a different department, a business owner, an end user spots assumptions insiders have stopped noticing.

Ask what's missing. Problem statements describe what's present. Ask what the statement leaves out: who isn't mentioned, what constraint isn't named, what happened before the problem appeared.

Consider multiple categories. Is this an incentive problem, an expectation problem, an information problem, a capability problem? A slow elevator is an engineering problem; an annoying wait is a psychology problem. Category determines solution space.

Analyze positive exceptions. Find the cases where the problem doesn't occur: the business that thrived, the cohort that completed and ask what was different. Exceptions point at drivers.

2. Define the problem with discipline

Dwayne Spradlin's work at InnoCentive analyzing thousands of problems submitted for open innovation found that organizations consistently under-invest in problem definition, then pay for it downstream (HBR, Sept 2012). His four-step process:

1. Establish the need. What's the basic need, and who has it? Not the solution you have in mind, but the solution you need.

2. Justify the need. Why does this matter, and why does it align with your mandate? If you can't answer, stop.

3. Contextualize the problem. What's been tried by you and by others? What worked, what didn't, what constraints exist?

4. Write the problem statement. One rigorous document, agreed to by stakeholders, before any solution work begins.

Most organizations skip straight from a vague version of step 1 to solution design. The discipline is in steps 2–4.

3. Surface the assumptions underneath

Every problem frame rests on assumptions about who needs what, what barriers exist, and what will create change. "Businesses need more funding" assumes funding is the constraint. "We need better marketing" assumes awareness is the bottleneck. These assumptions are usually invisible, unranked, and untested.

Discovery makes them explicit: map them, rank them by risk, and test the ones most likely to derail you before budget is committed. That process is its own discipline, and we cover it fully in Assumption Mapping for Programs & Initiatives.

What discovery looks like in practice

At Ground Floor Labs, discovery is the first phase of the Build With Validation methodology, and it has a defined shape:

Stakeholder interviews - structured conversations with the people who have the problem, not just the people funding the solution. Data review - what the existing evidence actually shows, separated from what everyone assumes it shows. Assumption mapping - every assumption the initiative is running on, ranked by risk. It ends with a diagnostic briefing and one of three clear recommendations: proceed, pivot, or pause.

That last part matters. Discovery that always concludes "proceed" isn't discovery; it is more like decoration. The value of the process is that it can tell you not to build the thing, while the budget is still in your pocket. The most expensive outcome in innovation isn't a failed experiment; it's building the wrong thing well.

How to start this week

You don't need an engagement to begin. Three moves:

1. Take your current initiative and ask five stakeholders to independently write down the problem it solves. Compare the statements.

2. For the frame you're using, list what it assumes, who needs what, what's blocking them, and what will change behaviour. Star the assumptions you have no evidence for.

3. Find one positive exception - a case where the problem doesn't occur and interview it.

If the statements diverge, the starred list is long, or the exception surprises you, you've just learned the diagnosis isn't settled. That's not a setback; that's the cheapest lesson you'll get all year.

Solving the visible problem is how budgets disappear. Discovering the right one is how outcomes happen. If you're accountable for an initiative and you can't yet prove you're aimed at the right problem, book a discovery call. You'll leave with the assumptions worth testing first, whether or not we work together.

Sources: Thomas Wedell-Wedellsborg, "Are You Solving the Right Problems?" Harvard Business Review, Jan–Feb 2017 · Dwayne Spradlin, "Are You Solving the Right Problem?" Harvard Business Review, Sept 2012 · HBR IdeaCast, "Solving" 2024.