The hidden trap in every brief: Solution Bias
Most briefs begin with a solution. A new website, a new feature, a new campaign. It feels decisive, but it’s often a trap. Solution bias is when we define the problem in terms of a particular fix, jumping to how before understanding why. The result? Great execution on the wrong thing.
Every project starts with a story.
A leader sees an opportunity, a metric dips, a competitor launches something shiny and before long, the brief is written which, with a lot of words around it usually arrives at:
- We need a new website.
- We need a new feature.
- We need a new campaign.
It feels decisive. It sounds like progress, but beneath the clarity lies a subtle trap that shapes how we think, what we build, and how much value we ultimately create.
That trap is called solution bias.
What is solution bias?
Solution bias is the tendency to define a problem in terms of a particular solution. It’s when we jump straight to how without truly understanding why.
Instead of asking, “Why are customers dropping off at checkout?”, we start with, “We need to redesign the checkout page.”
The difference seems small, but it’s the difference between diagnosing a symptom and treating the cause.
Where it comes from
No one sets out to be biased toward solutions on purpose, but it’s baked into how organisations are run. Think about:
- Briefs are written by stakeholders, not investigators. By the time a project lands on your desk, the “what” is often already decided.
- Certainty feels safe. Saying “we need a new campaign” sounds confident; saying “we don’t yet know why customers are leaving” sounds risky.
- Teams crave momentum. It’s easier to start sketching ideas than to sit in ambiguity.
In fast-paced environments, “doing something” beats “understanding something,” and that’s precisely how solution bias takes hold.
Why it matters
When we fixate on a solution too early, three things happen:
- We optimise for the wrong outcome. You can make a beautiful new website that still doesn’t address the trust issue driving abandonment.
- We narrow creative scope. Once a solution is named, alternatives disappear. The team orbits the brief instead of the opportunity.
- We under-deliver on impact. Success gets measured by deliverables (“we shipped the redesign”) instead of outcomes (“customers are converting more”).
There was a great excerpt in a recent Lenny's Podcast episode with Elena Verna where she shares that, in her experience, no rebrand has ever resulted in an uptick in growth.
This is why so many “finished” projects leave everyone feeling oddly unsatisfactory. Oddly too, the team don't really know whether the work done is finished. That's because the problem wasn’t clear enough and not real enough.
Recognising the bias
Teresa Torres, in Continuous Discovery Habits, popularised the term “solution bias” to describe this very phenomenon.
In her words, product teams must “fall in love with the problem, not the solution.” Something I've heard, but only recently linked to Teresa's book.
Design thinking and lean startup movements have long said the same thing, just in different language:
Don’t jump to solutions. Frame the problem first.
Which again, is why we frame - and why it's the first part of the Build Loop.
It’s simple advice. Harder to live by.
Escaping the trap
A few practices help reorient your team:
- Make assumptions visible. List what you believe versus what you know.(Most briefs blur the two.)
- Run a framing phase. Spend a week validating the problem before designing the fix. Small investments here save months later.
- Measure outcomes, not outputs.The goal isn’t to launch the thing; it’s to move the needle.
Rewrite the brief. Replace every proposed solution with a problem statement.
From “We need a new homepage”
To “People don’t understand what we offer within 10 seconds.”
The bigger picture
Solution bias isn’t just a product issue. It’s cultural. Executives want answers, teams want clarity and stakeholders want momentum. Users too, want improvement.
But in the rush to build, we often forget the value of not knowing. Discovery isn’t waste. It’s the difference between relevance and noise.
Every meaningful innovation, from Airbnb to Tesla to the NHS Covid app started not with “we need to build X,” but with “people are struggling with Y.” Why? Because the world doesn’t need more outputs. It needs more understanding.
Love the problem
The next time you read a brief that starts with a solution, pause.
Ask: What problem makes this worth solving?
Because until you know that, you’re not solving - you’re guessing.
