Stop Solving the Wrong Problem
Why the rush to solutions is killing innovation — and what to do instead
Most innovation fails before it even begins.
Not because the solution is wrong — but because the problem was never properly defined.
Walk into almost any meeting where a challenge is being discussed. Someone outlines an issue: a performance gap, a user complaint, a missed opportunity. There is a brief pause. Then someone speaks.
“We should build a dashboard.”
“What if we automate the process?”
“We need better data.”
“Let’s create a task force.”
Heads nod. Energy rises. The conversation shifts to timelines, owners, and implementation. It feels productive. Ideas are flowing. Action is emerging.
But something important just happened.
No one defined the problem.
The group moved directly from a vague situation to a concrete solution. The conversation converged before it diverged. Direction replaced understanding.
This pattern is so common that it feels normal. We assume this is how problem solving works: identify an issue, propose a solution, move forward.
But this instinct — the rush to solutions — is one of the most consistent barriers to effective innovation.
When teams move too quickly to solutions, they lock themselves into a narrow interpretation of the problem. They optimize within assumptions that were never examined. And the consequences appear later: weak adoption, stakeholder resistance, unexpected barriers, costly rework.
At that point, we blame execution.
But the real issue occurred at the beginning.
We solved the wrong problem.
Creative problem-solving research recognized this decades ago. The quality of solutions depends heavily on how problems are framed, and separating problem finding from solution generation improves innovation outcomes (Basadur, Graen, & Green, 1982). Design thinking later reinforced the same principle: spend time understanding before ideating (Brown, 2008; Liedtka, 2018).
Despite this, the rush to solutions remains the dominant behaviour.
Why?
Why We Rush to Solutions
Part of the explanation lies in meeting dynamics.
When a problem is introduced, there is often a brief silence. That silence is valuable — it creates space for reflection. But silence feels uncomfortable. It signals uncertainty. The first person to speak reduces tension.
And the easiest way to contribute is to propose a solution.
Solutions signal competence. Questions can feel like hesitation. Over time, teams learn that proposing answers demonstrates expertise, while exploring the problem risks appearing uncertain.
Behavioural economics helps explain why this happens. Herbert Simon’s concept of bounded rationality suggests that decision-makers rarely search for optimal solutions. Instead, they settle for the first option that appears “good enough” (Simon, 1955). This reduces cognitive effort and restores a sense of progress.
Action bias amplifies the effect. Under uncertainty, doing something feels better than doing nothing (Kahneman, 2011). Proposing a solution creates movement, even if understanding is incomplete.
Organizational culture reinforces these tendencies. Many organizations reward decisiveness. Progress is measured by action. Meetings are expected to produce next steps. Exploration can appear inefficient, especially under time pressure.
Managers learn that proposing solutions signals leadership. Teams learn that moving quickly demonstrates effectiveness.
Action replaces understanding.
Cognitive shortcuts amplify the problem further. Humans are highly skilled at pattern recognition. When we encounter a situation, we instinctively match it to something familiar. This allows rapid response — but encourages premature categorization. Once a problem is placed into a familiar category, known solutions are retrieved and exploration stops.
This reliance on heuristics simplifies decision-making but constrains innovation. Familiar problems trigger familiar solutions. Organizations become efficient at incremental improvement rather than fundamental rethinking.
The rush to solutions therefore is not accidental. It is driven by social pressure, cognitive efficiency, and organizational incentives — all pushing toward premature convergence.
The Structural Bias Toward Solutions
The tendency to move quickly to solutions is also structural. It reflects how teams think.
Min Basadur’s research on creative problem solving identified different thinking styles across the innovation process: problem finding, ideation, evaluation, and implementation (Basadur, 2004). Effective innovation requires all of them. But many organizations — particularly technical ones — are dominated by implementers and optimizers.
These individuals excel at refining ideas and executing plans. Their skills are highly valued, and rightly so. But problem-finding styles, which focus on exploring ambiguity and challenging assumptions, are often underrepresented.
The result is predictable. When a challenge is introduced, solution-oriented thinkers dominate the discussion. Conversations accelerate toward implementation before the problem is fully understood.
This dynamic is reinforced by how expertise is defined. In many environments, expertise is associated with answers. Senior leaders are expected to know what to do. Specialists are valued for providing solutions. Progress is measured by decisions and actions.
Yet innovation rarely depends on immediate answers. It depends on understanding complexity and uncertainty. In these situations, expertise is better expressed through inquiry — identifying assumptions, exploring alternatives, and recognizing what is not yet understood.
When organizations redefine expertise to include problem definition, behaviour shifts. Questions become signals of insight rather than hesitation. Exploration becomes part of progress.
Improving innovation is therefore not only about adopting new tools. It is about rebalancing thinking styles and redefining what expertise looks like.
From Creative Problem Solving to Design Thinking
The importance of problem definition has deep roots. Creative problem-solving research emphasized separating problem finding from solution generation, highlighting that innovation begins with framing the challenge (Basadur, Graen, & Green, 1982; Basadur, 2004).
Design thinking later expanded this approach, placing user understanding at the beginning of the innovation process (Brown, 2008; Liedtka, 2018). The familiar sequence — empathize, define, ideate, prototype, test — is essentially a structured attempt to slow down premature convergence.
This evolution reflects an expanding focus: from ideas, to users, to implementation. Each step moves innovation closer to real-world impact.
The next step is embedding adoption considerations directly into problem definition. Innovation is not just about generating creative ideas. It is about creating solutions that people are willing — and able — to adopt.
And that begins with framing the problem correctly.
Framing the Problem Properly
Once teams resist the rush to solutions, the next challenge is knowing how to explore the problem effectively. Three complementary approaches are particularly powerful: reframing the question, identifying root causes, and understanding the job users are trying to accomplish.
The “How Might We” formulation is often the first step. By converting a challenge into an open-ended question, teams keep the solution space open. Instead of stating, “We need to improve system performance,” the group asks, “How might we improve the user experience of the system?” The shift appears small, but it changes the nature of the conversation. Assumptions soften. Alternatives emerge. Exploration precedes convergence.
But reframing alone is not enough. Teams must also move beyond symptoms. Root cause exploration pushes the discussion deeper. When adoption is low, the instinct is to add training. When performance is weak, the instinct is to increase monitoring. These responses often address visible symptoms rather than underlying drivers. Asking “why” repeatedly reveals structural issues — misaligned incentives, lack of trust, workflow friction, perceived risk.
Understanding the job to be done adds another layer. Rather than focusing on features, teams ask what users are trying to accomplish. Technologies are rarely adopted for their own sake. They are adopted to make progress in specific situations. When the job is clear, alternative approaches become visible. Functional needs emerge alongside emotional and social considerations — trust, autonomy, perceived risk.
This perspective aligns closely with outcome-driven innovation, which emphasizes identifying the outcomes users are trying to achieve before designing solutions (Ulwick, 2005).
Together, these approaches transform problem definition from a superficial exercise into disciplined exploration.
Slowing Down to Speed Up Innovation
Each of these practices slows the early phase of innovation. It delays visible action. It extends exploration.
Yet experienced innovators recognize that slowing down at the beginning accelerates everything that follows.
When the problem is well defined, solution generation becomes more focused. Fewer ideas are needed. Stakeholders align earlier. Adoption barriers are anticipated. Implementation becomes smoother.
By contrast, rushing to solutions creates hidden costs. Teams move quickly at first, but encounter resistance later. Adjustments are required. Features are added. Stakeholders must be re-engaged.
The most effective innovators therefore develop a counterintuitive habit.
When others rush forward, they pause.
When others propose solutions, they ask questions.
When others categorize quickly, they explore alternatives.
They slow down — and by doing so, they move faster.
From Problem Definition to Adoption
The most important benefit of disciplined problem definition is adoption.
Innovation succeeds or fails at the point of use. A solution may be technically elegant and economically attractive, yet still struggle if users hesitate, stakeholders resist, or organizations cannot integrate it into existing workflows.
Embedding adoption considerations into problem definition changes the trajectory of innovation. Instead of asking only how to improve performance, teams ask how to improve performance in a way that users trust, stakeholders support, and organizations can realistically implement.
Root cause analysis and job-to-be-done thinking reveal motivations, constraints, and stakeholder dynamics early. The result is innovation designed not just for performance, but for acceptance.
Problem definition becomes adoption design.
Rethinking Progress
One of the deeper challenges underlying the rush to solutions is how organizations define progress.
In many settings, progress is equated with visible action. But in innovation work, visible action can be misleading. Teams may move quickly while still operating with incomplete understanding.
Behavioural economics again explains the trap. Action bias encourages movement even when reflection would improve decisions (Kahneman, 2011). The sunk cost effect reinforces early commitment.
Breaking this cycle requires redefining progress. Instead of measuring activity, organizations can value learning. Instead of asking “What solution are we implementing?”, they can ask “What have we learned about the problem?”
When progress is defined in this way, exploration becomes legitimate.
From Problem Definition to Impact
The rush to solutions shapes the entire trajectory of innovation. When teams converge too early, they define challenges narrowly and explore limited alternatives.
By contrast, disciplined problem definition changes everything. The focus shifts from generating ideas to understanding context. Exploration precedes execution. Decisions are grounded in clearer insight into motivations, constraints, and opportunities.
Innovation does not fail at implementation.
It fails at problem definition.
When teams take the time to define the problem well, solutions align more closely with real-world conditions. Stakeholders engage earlier. Adoption becomes more likely.
Innovation, in this sense, is not driven primarily by better ideas.
It is driven by better understanding.
And that understanding begins with the discipline to pause — long enough for the right problem to emerge.
References
Basadur, M. (2004). Leading others to think innovatively together: Creative leadership. The Leadership Quarterly, 15(1), 103–121.
Basadur, M., Graen, G. B., & Green, S. G. (1982). Training in creative problem solving: Effects on ideation and problem finding. Organizational Behavior and Human Performance, 30(1), 41–70.
Brown, T. (2008). Design thinking. Harvard Business Review, 86(6), 84–92.
Kahneman, D. (2011). Thinking, fast and slow. Farrar, Straus and Giroux.
Kahneman, D., & Tversky, A. (1979). Prospect theory: An analysis of decision under risk. Econometrica, 47(2), 263–291.
Liedtka, J. (2018). Why design thinking works. Harvard Business Review, 96(5), 72–79.
Simon, H. A. (1955). A behavioral model of rational choice. Quarterly Journal of Economics, 69(1), 99–118.
Ulwick, A. W. (2005). What customers want: Using outcome-driven innovation to create breakthrough products and services. McGraw-Hill.


Yes — critical thinking abilities are required to be able to solve the actual problem. Or else, you may just be solving the symptoms.
A very important point. I would add that problem definition itself is never neutral, it depends on who is defining the problem and from which perspective. Sometimes the problem is framed by leadership, technical teams, or operations teams, and each may see a different reality.
There is also often an authority bias in organizations: once a C-suite leader supports a solution, others may hesitate to challenge it, even if the underlying problem has not been fully examined.
A stronger approach may be to first define the problem through root cause analysis, and then intentionally separate roles within the team one group to propose solutions, and another to critically test and challenge them. That can improve both problem framing and solution quality.