Nobody Asked You to Solve It Yet
The difference between product thinking, solution thinking, and UX thinking and why confusing them is costing your team good ideas.
There’s a meeting that happens in almost every product team. Someone identifies a problem users are dropping off at checkout, engagement is low, the onboarding flow feels clunky. Within four minutes, someone else has a solution on the whiteboard.
The problem gets replaced by a feature. The feature gets debated. The original problem quietly leaves the room.
This is what I call solution thinking and it’s the default mode most of us are running in without realizing it. It’s not laziness or bad intent. It’s just the most natural response to discomfort: a problem exists, so we reach for the nearest fix.
But solution thinking is different from product thinking. And both of them are different from UX thinking. Understanding which mode you’re in and when is one of the most underrated skills in building anything people actually use.
Solution Thinking: The Reflex
Solution thinking starts with an answer. It sounds like:
“We should add a progress bar.”“Let’s send a reminder notification.”“What if we redesigned the onboarding flow?”
The feature is named before the behavior is understood. And the behavior is what matters.
Solution thinkers aren’t wrong to want to fix things they’re just skipping a step. The step where you sit in the discomfort of not knowing long enough to actually understand what’s broken.

The dangerous thing about solution thinking is that it feels productive. You leave the meeting with action items. You have something to build. But you may be building a precise answer to an imprecise question.
Product Thinking: The Frame
Product thinking zooms out. It asks: what outcome are we trying to create, and for whom?
It sounds like:
“Why are users dropping off at checkout what do we know about what they expected vs. what they found?”“What does success look like in six months, and how does this feature contribute to that?”“Are we solving the right problem, or just the most visible one?”
Product thinking holds the tension between business goals and user needs. It works at the level of systems how does this piece connect to everything else? What gets worse if we change this? What constraint are we not seeing?

Product thinking is valuable because it forces prioritization. Not every user problem is worth solving. Not every solution worth building serves the business. Product thinking is the negotiation between those two truths.
But here’s what product thinking often misses: it can still make assumptions about users without watching them. It can be strategic and still be wrong about behavior.
UX Thinking: The Ground Floor
UX thinking starts with a person. A specific, flawed, distracted, motivated human being trying to do something.
It sounds like:
“What is this person actually trying to accomplish not what we designed for, but what they came here to do?”“Where did they hesitate? What did they misread? What did they skip entirely?”“What does this interaction feel like not look like?”
UX thinking is rooted in observation. It doesn’t trust assumptions, even reasonable ones. It knows that the gap between what people say they’ll do and what they actually do is where the most important design decisions live.
When I ran my Snackbites usability study, the hypothesis was that users struggled with navigation. That was the product thinking frame a reasonable assumption based on the drop-off data. But watching five people try to order popcorn revealed something different: they weren’t lost, they were overwhelmed. Not by the flow, but by the number of choices arriving simultaneously at the customization step.
The solution thinker would have redesigned the navigation. The product thinker might have simplified the information architecture. The UX thinker watched a person pause for six seconds, sigh quietly, and tap “skip” and asked: what just happened there?
That six-second pause was the data. Everything else was interpretation.
Why All Three Matter And Why Order Matters
These three modes of thinking aren’t competing. They’re sequential. The problem comes when we apply them out of order.
Solution thinking before UX thinking gives you a beautifully built answer to the wrong question. You ship a feature that no one asked for in the form you built it.
Product thinking before UX thinking gives you a well-framed problem with incorrect assumptions baked in. Your strategy is coherent but it’s built on what you think users want, not what you’ve observed them need.
UX thinking first means you start with behavior what do people actually do, feel, and expect? Then product thinking frames the opportunity which of these behaviors is worth designing for? Then solution thinking builds now that we know the right problem, what’s the right answer?
The sequence is: observe → frame → build.
Most teams do it backwards.
The Hardest Part
The hardest part of UX thinking isn’t the methods. It’s the patience to not have the answer yet.
It means walking into a research session genuinely not knowing what you’ll find. It means presenting findings that create more questions than they answer. It means telling a stakeholder “we don’t know enough yet” when everyone wants to move fast.

It also means being the person who says, quietly: we’re solving this from inside a conference room, and the people we’re designing for have never been in this room.
That discomfort is not a problem to fix. It’s where good research starts.
A Way to Check Yourself
Next time you’re in a product meeting, notice which question is driving the conversation:
- “What should we build?” → Solution thinking
- “What should we focus on?” → Product thinking
- “What is actually happening for users?” → UX thinking
All three questions matter. But if you can’t answer the third one confidently, the answers to the first two are guesses sophisticated, well-intentioned guesses, but guesses.
The best teams I’ve seen aren’t the ones who move fastest. They’re the ones who know which question they’re answering at any given moment.
Nobody Asked You to Solve It Yet was originally published in Bootcamp on Medium, where people are continuing the conversation by highlighting and responding to this story.