Most organizations are pretty good at executing. Given a clear direction, a capable team will generally figure out how to get there. The challenge isn't usually the execution. The challenge is what happens before the execution begins — the moment when someone decides what problem the team is actually trying to solve.
Get that moment right, and execution has a real chance of mattering. Get it wrong, and no amount of skill, speed, or effort will fix what follows.
The uncomfortable truth is that most organizations spend very little structured time on problem definition. They move quickly from "here's the situation" to "here's what we're building" — compressing or skipping the step where the problem itself gets examined, questioned, and clearly framed. The result is that teams frequently execute with tremendous discipline against the wrong target.
There's a version of this failure that shows up constantly across industries. A product gets built for a customer need that was assumed rather than validated. A process gets redesigned around an efficiency problem when the real issue was a communication breakdown between teams. A strategy gets funded and launched against a competitive threat that was misread. Months and budget disappear. The outcome doesn't land. And somewhere in the debrief, if the debrief happens honestly, someone says: "I think we were solving the wrong problem."
The worst part isn't the waste, though the waste is real. It's that the effort looked like progress for a long time. Teams were busy. Milestones were hit. Reports showed green. The organization was executing with confidence — on the wrong thing.
Speed makes this worse, not better. When organizations prize rapid execution, the pressure to move from problem to solution quickly intensifies. Pausing to question the problem definition can feel like delay. In a culture that rewards momentum, it can even feel like weakness. So the assumption stays unexamined, and the organization moves fast toward a destination it never fully verified was the right one.
A few dynamics consistently undermine good problem definition, and they're worth naming directly.
The first is familiarity bias. When a leader or team has seen a similar situation before, the pattern-matching instinct kicks in. "We've seen this — we know what this is." The previous experience collapses the inquiry. What feels like efficiency is actually assumption substituting for understanding. The current situation gets mapped onto the previous one before anyone has checked whether the map actually fits.
The second is organizational pressure to have answers. Leaders are rewarded for clarity and direction. Admitting that the problem isn't yet well understood can feel like admitting incompetence. So the problem gets declared clear before it is, and the team moves. Everyone is relieved by the sense of direction. Very few people stop to ask whether the direction is right.
The third is the structure of most planning processes. They're built around solutions, not problems. A project gets scoped. Resources get allocated. A timeline gets set. All of that infrastructure assumes the problem is known. Going back to question it feels like starting over — which creates real organizational friction even when the questioning is warranted.
The result of all three is that teams regularly begin executing against problems that were never properly understood, on timelines that left no room to find out.
Defining a problem well is a specific discipline. It requires deliberately slowing down before moving fast, which is counterintuitive for most organizations. It requires asking questions whose answers might change the plan — which means creating space where that kind of questioning is safe. And it requires bringing the right people together: not just the people who will execute the solution, but the people who understand the full context of the problem.
A few principles that consistently separate good problem definition from poor:
Separate the problem from the proposed solution. Many "problem statements" are actually solution statements in disguise. "We need to redesign the onboarding process" is not a problem statement — it's a proposed intervention. The problem might be that new customers aren't activating, or that support volume spikes in the first 30 days, or that churn is happening before customers reach the first moment of value. Each of those points to a different solution. Jumping to the intervention before understanding the root means the solution is chosen before the problem is known.
Get closer to where the problem actually lives. The people who designed the strategy and the people who experience the problem are often different groups. Leaders tend to understand the problem conceptually. Customers, frontline employees, and operational teams understand it experientially. Good problem definition draws on both. The gap between how a problem is described in a boardroom and how it's lived by the people closest to it is frequently where the real insight lives.
Ask what's true that wasn't assumed. Every problem definition rests on a set of assumptions. Making those assumptions explicit — and testing the most consequential ones before committing to a solution — is the difference between rigorous inquiry and confident guessing. The most useful question isn't "what's the solution?" It's "what would have to be true for our current framing to be wrong?"
One of the most practical tools for structured problem definition is the Design Sprint — a focused, time-boxed process for clarifying a challenge, exploring solutions, and testing assumptions before committing to full execution.
What makes the Sprint valuable isn't primarily the prototyping or the user testing, though both are useful. It's the front end — the time spent before any solution gets built, working through the problem definition with real rigor. Understanding the customer. Mapping the existing experience. Identifying where the assumptions are weakest. Deciding, explicitly, what the team needs to learn before it can act with confidence.
Organizations that run Design Sprints consistently report learning things in those early sessions that would have sent the project in a different direction if they'd been discovered six months into execution. That's not a failure of the sprint. That's exactly the point. Learning those things early — when the cost of changing direction is low — is what the process is designed to do.
The sprint also does something that's harder to quantify but just as important: it creates shared understanding. The people in the room leave with the same picture of the problem. That alignment has real value when execution begins, because the team isn't operating on seven different versions of what success looks like.
Organizations that consistently skip structured problem definition don't usually fail dramatically. They tend to produce a steady stream of work that's competent but slightly off. Products that don't quite land. Initiatives that close the wrong gap. Strategies that address the symptom rather than the root. Each individual project might look like a partial success. Cumulatively, they represent an enormous amount of effort pointed in directions that weren't fully verified.
The cost isn't just financial. It's the erosion of team confidence that comes from working hard on things that don't move the needle. Over time, people stop believing that their best work will matter. They execute because that's what's expected, not because they trust that the direction is right.
That's a culture problem. And it starts with a problem definition problem.
The next time a significant initiative gets kicked off, consider running the problem definition harder before anything else begins. Bring in people who experience the problem directly. Surface the assumptions underneath the current framing. Ask what the team doesn't know yet that it would need to know to be confident.
That work takes time. It requires a willingness to sit with ambiguity rather than forcing premature clarity. And it might slow the start of execution by days or weeks.
What it's far less likely to do is send the organization six months down the road, fully committed to a well-executed solution to a problem that was never quite right in the first place.