Design Thinking: empathy first, solution last.

Design Thinking is the framework that escaped its discipline and became corporate wallpaper. You can buy the post-it notes pre-printed. You can hire a consultancy to "facilitate the workshop." You can watch a senior leader walk into a conference talk and use the words empathise, define, ideate as if they were a magic incantation that, said aloud, will produce a strategy. None of this is what the framework was meant to do. What it was meant to do is fix a specific failure mode in product and engineering teams: leaping to solutions before they had understood the problem. On that narrow brief, it is genuinely useful.

It is also, more than any framework in this series, the one most likely to be misapplied as theatre. Two days of post-its and a "how might we" wall, followed by no changes to the roadmap, the team or the metric anyone is actually measured on, is not Design Thinking. It is a paid offsite. Knowing the difference is the whole game.

Where the framework comes from.

The clean version of the story attributes Design Thinking to IDEO in the 1990s and the Stanford d.school in the 2000s, with Tim Brown's 2009 book Change by Design doing most of the work to push it from a design discipline into corporate strategy. The longer version reaches back to Herbert Simon's The Sciences of the Artificial in 1969 and a whole tradition of human-centred design that long predates the post-its. The bit that matters for product people is the formalisation into a five-step process at the d.school. That's the version that travels into product orgs, and the version you'll see on the consultant's slide.

The five steps.

Empathise. Field research, interviews, observation. Sitting with users in their context, watching what they actually do, not what they tell you in a survey. This is where most teams cut corners, because empathy is slow and the calendar is full. The whole framework depends on this step being done properly. If you skip it, every subsequent step is built on whatever the loudest person in the room assumed.

Define. Frame the problem in a single sentence. The d.school's signature artefact here is the problem statement or point of view: "X needs Y because Z", where the surprise is the Z. If your Define step lands on something obvious ("users want it to be faster") you probably skipped the empathise step.

Ideate. Generate solutions, plural. The discipline is to produce more options than you'll use, on purpose, before you commit. The "how might we" question format lives here. So does the post-it wall. The point isn't the post-its. It's that you don't pick the first solution that occurs to you.

Prototype. Build the cheapest possible artefact that lets you put your idea in front of someone. Paper sketches, clickable Figma, a fake door, a Wizard of Oz mock-up. The point is build to think, not build to ship. Prototype quality is calibrated to the cost of being wrong. High-cost decisions justify higher-fidelity prototypes.

Test. Put the prototype in front of real users. Watch what happens. Then, and this is the part that gets skipped most often, go back to Empathise, because what you've learned has changed what you should be asking.

Tim Brown and the push into business.

Tim Brown's Change by Design made the leap from design discipline to corporate strategy explicit. His argument is that the same five-step posture works at the level of business model design, not just product design. That's where Design Thinking became a consulting product and started showing up in MBA syllabi. It's also where it lost most of its rigour, because the corporate version dropped the inconvenient bits (actually observing users, actually building cheap prototypes) and kept the easy bits, which is post-its.

The "design thinking workshop" trap.

The most common failure mode is the workshop that becomes the deliverable. The team spends two days in a room. The facilitator produces a beautiful Miro board. The leadership team feels good about the day. Then nothing changes. The reason is mechanical: the workshop produced ideas, not commitments. Nobody owns turning the Define statement into a problem the roadmap is now working on. Nobody owns building the prototypes. Nobody owns testing. The workshop was the work, instead of being the start of the work.

The fix isn't to run better workshops. The fix is to refuse to run the workshop until you've decided what the next four weeks of follow-up work looks like — who owns the prototyping, who owns the testing, what gets moved off the roadmap to make room. If you can't answer those questions on the way in, don't book the room.

Compatibility with agile.

Design Thinking and agile sit at different points in the same arc. Design Thinking is the upstream piece — figuring out which problem is worth solving, and roughly how. Agile is the downstream piece, building, shipping, iterating on the solution you committed to. The two complement each other when they're sequenced properly: Design Thinking sprint produces a defined problem and a tested prototype, the agile delivery team picks it up and builds it. The two collide when teams try to do both inside the same two-week sprint, because the cadence of empathy work and the cadence of engineering delivery are fundamentally different.

When to use it.

• Novel problem. You're entering a market or use-case the team has never touched. Design Thinking earns its weight here, because empathising with users you don't yet understand is the only way to avoid building the wrong thing.
• Customer-facing surface. The work changes the experience real users meet directly. Design Thinking helps because the cost of getting it wrong shows up as churn and bad reviews.
• High strategic ambiguity. The leadership team can't agree on what problem you're solving. The Define step is the most valuable artefact you can produce: a single sentence everyone signs.

When not to use it.

• Known engineering work. Re-platforming, infrastructure upgrades, performance fixes. The problem is well-defined and the constraints are mostly internal. Don't workshop a database migration.
• Single feature with clear AC. The PO already knows the user, the problem and the acceptance criteria. A two-day workshop to confirm what you already know is theatre.
• Time-critical fixes. Production is down, a customer is leaving, a regulator is asking questions. Design Thinking is slow on purpose. Crises need a faster cycle.

How we use this at Product Pieces.

We use Design Thinking in two specific places. The first is when a team comes to us with a customer-facing product that has clearly been built without anyone having watched a customer use it. The empathise-define sequence is the cheapest way to recover ground — two weeks of well-run interviews and a sharp problem statement is worth more than the next quarter's roadmap. The second is when the leadership team disagrees about what problem the product is solving. The Define step forces the disagreement into the open, and the artefact you leave with is a sentence everyone signed.

We don't use it for delivery work, and we don't use it inside an agile cadence. The two skills sit either side of a clean handoff, not on top of each other.

Next issue: N°21, User Research. The discipline behind the empathise step.