Doug Worsham

What if intensive problem definition is sometimes counterproductive?

February 07, 2026

design

problem-definition, SFBT, self-efficacy, imagined-futures

Lately, I’ve been wondering: What if intensive problem definition, despite deep traditions in design thinking, might sometimes be counterproductive?

This might feel a little blasphemous from a traditional design thinking perspective. We’re taught to deeply define problems before thinking about solutions. But what if these boundaries aren’t as important as we’ve been led to believe?

I started thinking about this question while researching best practices on coaching and professional development, specifically Steve de Shazer and Insoo Kim Berg’s work on “Solution-Focused Brief Therapy” (SFBT).

What the research shows

SFBT rests on a premise that challenges conventional design wisdom: you may not need to deeply define a problem’s origins to solve it. Rather than dwelling on problems, SFBT emphasizes exploring desired futures, identifying exceptions (times when the problem was less severe), and building on existing strengths.

“Steve de Shazer recognized early on that although the causes of problems may be complex, their solutions need not necessarily be.” (Trepper et al., 2006)

And it works. Anthony Grant’s research studies explored the effectiveness of SFBT’s future-focused questioning for coaching people on challenges (Grant, 2012; Grant & O’Connor, 2018; Grant & Gerrard, 2020). These studies compared solution-focused and problem-focused coaching across 5 dimensions:

  • Self-efficacy: Solution-focused questions led to a greater increase in self-efficacy
  • Positive affect: Solution-focused questions increased positive affect; problem-focused questions did not
  • Negative affect: Both approaches reduced negative affect, but solution-focused did so more effectively
  • Action planning: Solution-focused participants generated more concrete action steps
  • Problem understanding: Counterintuitively, solution-focused participants also demonstrated increased insight into the nature of their problems

That last finding is particularly striking: people who focused on solutions understood their problems better than those who focused on the problems themselves.

Problem-finding still matters

Before going too far down this road, I should say that talking about problems isn’t inherently bad. The research support for thoroughly understanding problems is substantial:

  • Paul Nutt’s research (1999) into organizational decisions found that “rushing to judgement” on a solution before developing sufficient understanding was a common cause of failed decision making
  • Getzels and Csikszentmihalyi’s 20-year study (1976) of art students showed that students adept at finding problems to solve in their work produced more creative work and were more likely to succeed in sustaining their artistic careers

So understanding problems is important. But I suspect there’s something deeper happening here. For example:

  • Nutt also found that a “limited search” for potential solutions was an organizational decision-making trap
  • In Getzels and Csikszentmihalyi’s work, “problem-finding,” with its focus on discovery and invention, feels fundamentally different from a strict design thinking approach to “problem definition”

There’s a tension here worth exploring. Solution-focused thinking, having shown significant benefits in therapeutic and coaching settings, might also be beneficial for design teams. At the same time, we still need to give careful attention to problems and challenges in our process. This brings up a set of deeper questions about how we approach problems in design work.

Questions worth exploring

As I’m learning more about this, several questions keep coming up. I’m hoping to explore each of these in future posts about how we might shift our thinking about problems in the design process.

Are the boundaries between problem-definition and solutions really necessary? Design thinking consultants often place strict boundaries between these phases. But do expert designers actually adhere to these boundaries in their day-to-day practice?

What happens when problem definition goes too far? Do some organizations and teams get stuck in negative feedback loops where extensive problem definition leads to feelings of overwhelm and helplessness?

Is the “problem-solution” framing itself limiting? Are there other ways to think about design that open up more possibilities? What if our primary goal was progress or improvement, rather than a complete solution?

What would a more constructive approach look like? How might we apply these ideas in practice, especially for small design teams with limited capacity?

Putting it into practice

For now, in my own day to day practice, I’m experimenting with spending less energy analyzing what’s wrong, and more energy building what could be. The research suggests this is likely to be more effective, and I suspect it will probably be more fun, too.

References