Skip to main content
Design thinking gets a bad reputation in some product circles. Too fluffy. Too workshop-y. Too many Post-it notes and not enough shipping 🙄 Some of that criticism is fair - when design thinking becomes a box-ticking exercise or a two-day offsite with no follow-through, it earns the eye-rolls. But the underlying principles are genuinely useful, and understanding them makes you a better product thinker regardless of whether you ever run a formal design sprint.

​
What it is

Design thinking is a problem-solving approach developed at Stanford’s d.school and popularised by IDEO. The core idea is simple: before you define a solution, deeply understand the people you’re designing for. It’s human-centered by design (no pun intended). It’s usually described as five stages: Empathise - Understand your users. Observe them, interview them, immerse yourself in their world. This is discovery work - the same customer interviews and research you’d do anyway, but with a deliberate focus on feelings and context, not just behaviour. Define - Synthesise what you learned into a clear problem statement. Not “users want a better dashboard” but “busy ops managers lose track of team workload because their tools don’t show real-time status in one place.” Specific, human, actionable. Ideate - Generate as many solutions as possible before committing to any. Quantity over quality at this stage. The point is to avoid anchoring on the first idea that sounds reasonable. Prototype - Build something small and rough to make your idea tangible. Not to ship - to learn. A sketch, a mockup, a paper prototype. Good enough to test, fast enough to throw away. Test - Put your prototype in front of real users. Watch what happens. Go back to empathise if needed. The process is intentionally iterative, not linear.

​
Why it matters for product

The most valuable part of design thinking isn’t the framework - it’s the habits it builds. The “define” stage in particular is underrated. Most teams jump from research directly to solutions, skipping the hard work of writing a crisp problem statement. Design thinking forces you to stop and ask: what is the actual problem we’re solving? Getting that right changes everything downstream. The ideation stage is the other one worth protecting. In most product meetings, the first reasonable idea wins. Design thinking explicitly creates space to generate ten ideas before evaluating any of them - and the tenth idea is often better than the first.

​
The honest caveat

Design thinking works best at the fuzzy front end of a problem - when you’re still figuring out what you’re solving. It’s less useful once you’re deep in execution and need speed over exploration. It also requires psychological safety to work well. The empathise and ideate stages only produce honest output if people feel safe sharing observations and half-baked ideas without judgement. If your team culture doesn’t support that, the framework won’t save you 🤷 Lesson learned: design thinking isn’t a methodology you adopt wholesale - it’s a set of instincts you borrow. Empathise before you define. Define before you ideate. Prototype before you build. That sequence alone will improve most product processes.