Design Thinking

Critics dismiss design thinking as workshop theatre. Sticky notes, post-its, a facilitator in a hoodie, and a wall of empathy maps that nobody looks at again. That caricature fairly captures how teams often perform it, but it doesn’t fairly describe what it is. Done properly, design thinking is one of the most reliable ways to stop product teams from building the wrong thing. The pattern matters; the post-its are optional.

What is design thinking?

Design thinking is a human-centered approach to solving complex problems by deeply understanding the people experiencing them, framing the problem from their perspective, generating a wide range of possible solutions, and validating those solutions through prototyping and testing. It’s an iterative discipline, not a linear template, and teams use it to reduce the risk of building something nobody wants.

The phrase entered mainstream business vocabulary through Tim Brown and IDEO’s design thinking hub, which describes it as a way to integrate the needs of people, the possibilities of technology, and the requirements for business success. IDEO and the Hasso Plattner Institute of Design at Stanford (the d.school) have done most of the heavy lifting in codifying it since. The core idea predates both. Designers, architects, and engineers have been working this way for decades. In the 2000s, designers and consultants started applying this approach to services, software, and strategy, not just physical products.

For product managers, design thinking matters because most product failures are failures of understanding, not failures of execution. Teams build the wrong feature for the wrong user solving the wrong problem, then wonder why adoption is flat. Design thinking is a way to slow down at the front of the process so you don’t have to clean up at the back of it.

Where did design thinking come from?

The intellectual lineage of design thinking runs through a few specific people and institutions, and understanding that lineage helps explain why the modern version looks the way it does.

The early academic roots

Nobel laureate Herbert Simon laid some of the foundations in his 1969 book The Sciences of the Artificial, which framed design as a way of thinking and a generalizable approach to problem-solving. Bryan Lawson and Nigel Cross spent decades studying how designers actually think, surfacing patterns that turned out to be transferable far beyond product design.

The IDEO and Stanford era

David Kelley founded IDEO in 1991 and later co-founded the d.school at Stanford in 2005. Between them, IDEO and the d.school turned design thinking from an academic curiosity into a method that businesses could actually adopt. Tim Brown’s HBR article gave it a name that executives would say out loud, and his book Change by Design gave them something to put on the shelf.

The current moment

Design thinking has since had a backlash. Critics like Natasha Jen have argued, with reasonable evidence, that practitioners have overhyped it, oversimplified it, and reduced it to a sticky-note ritual. They’re not wrong about how most teams practice it.

They’re not wrong about how it’s often practiced. They are wrong about the underlying ideas, which still hold up. The skill is separating the method from the merchandise.

What are the five stages of design thinking?

Most modern descriptions of design thinking use the five-stage model proposed by the d.school: Empathize, Define, Ideate, Prototype, and Test. Slide decks draw these stages as a tidy linear arrow, but in practice they overlap, loop back on each other, and rarely happen in a clean sequence.

Empathize

The Empathize stage is the work of understanding the people you’re designing for, in the context of the problem you’re trying to solve. It involves observation, interviews, immersion, and any other method that helps the team get past assumptions and into actual user behavior. The point is to surface needs that users themselves often can’t articulate.

This is the stage product teams skip most often, usually because it feels indulgent. It is not indulgent. Skipping it is how you end up with three months of build, no adoption, and a post-mortem full of “we should have talked to more customers.”

Define

The Define stage takes the raw material from empathy work and synthesizes it into a clear problem statement. A good problem statement centers humans, stays narrow enough to act on, and stays broad enough to allow for multiple solutions. “Property managers need a faster way to reconcile rent payments across multiple buildings without losing the audit trail” is a problem statement. “Improve the rent dashboard” is not.

This is closely related to problem framing, and it’s where most product teams start to fall apart. They write problem statements that are actually solution statements in disguise, then wonder why ideation feels constrained.

Ideate

The Ideate stage is generative. The point is to produce many possible solutions to the problem, deliberately deferring judgment so that ideas have room to breathe before the team critiques them. Techniques include brainstorming, sketching, “How might we” questions, worst possible idea, and structured methods like the CIRCLES Method.

Two ideation failures show up repeatedly. The first is teams converging too early on a single solution because someone senior in the room signaled what they wanted. The second is treating ideation as a discrete event rather than an ongoing practice. The Stanford d.school’s own introduction to design thinking process guide emphasizes deferring judgment for a reason; the goal at this stage is range, not quality.

Prototype

The Prototype stage turns ideas into something users can interact with. The bar is intentionally low. A prototype can be a paper sketch, a clickable Figma file, a coded MVP, or a roleplay where someone acts out the experience. The Stanford process guide puts it well: build to think, don’t think to build.

The cost of a prototype should be roughly proportional to the cost of being wrong. Cheap prototypes for high-uncertainty ideas; more polished prototypes when you’re refining a near-final solution. Teams routinely invert this, building expensive prototypes of the things they’re already confident about and skipping prototypes for the things that actually need testing.

Test

The Test stage puts prototypes in front of real users and gathers feedback. Testing isn’t validation, despite how teams often frame it. A “successful” test is one that surfaces something the team didn’t know, regardless of whether the prototype worked. If every test confirms what you already believed, you’re either lying to yourself about the results or you’re testing the wrong things.

Testing also feeds back into all the previous stages. New insights from testing often send you back to Empathize (you misunderstood the user), or Define (you framed the problem wrong), or Ideate (you defined the solution space too narrowly). This is why the linear arrow diagram is misleading.

How is design thinking different from product discovery?

Product managers regularly ask whether design thinking and product discovery are the same thing. They overlap, but they aren’t the same.

Design thinking is a broader problem-solving methodology that applies to almost anything: products, services, processes, organizational design, public policy. Product discovery is the specific application of design-thinking-adjacent practices to the question of what to build next in a product. ProdPad’s guide to continuous discovery covers how to adapt these principles for the cadence of an ongoing product team rather than a one-off design engagement.

The practical difference matters. Teams often run design thinking as a project: a defined challenge, a defined team, a defined output. Product discovery, by contrast, runs continuously and integrates into how the product team works week to week. If your design thinking work ends when the workshop ends, you have a workshop habit, not a discovery practice.

How is design thinking different from a design sprint?

A design sprint is a specific, time-boxed application of design thinking, codified by Jake Knapp and his team at Google Ventures. The classic design sprint compresses understand-ideate-prototype-test into five days, with a tightly choreographed structure for each day.

Design thinking is the underlying philosophy. The design sprint is one packaged way to practice it. You can do design thinking without ever running a design sprint, and you can run a design sprint that misses the point of design thinking entirely (most do, when teams treat them as a feature factory accelerator rather than a problem-validation exercise).

What does design thinking look like in a product organization?

In practice, design thinking inside a product team rarely looks like the five-stage diagram. It looks like a set of habits embedded in how the team works.

Empathy work is continuous, not scheduled

Strong product teams talk to customers every week, not every quarter. The PM, designer, and engineer (often called the “Product Trio“) share responsibility for being close to users. Teresa Torres goes deeper into how this works in practice in her webinar with Janna Bastow on continuous product discovery. Empathy isn’t outsourced to a research team that hands off a report.

Problem framing is a separate, named activity

The team treats problem framing as work in its own right, not something that happens in the first five minutes of a planning meeting. Problem statements are written down, reviewed, and refined. The discipline of writing a clear problem statement before jumping to solutions is what separates outcome-focused teams from feature factories.

Ideation produces options, not commitments

When the team converges on a direction, they’ve usually generated several alternatives, even if only one moves forward. The discarded options aren’t waste; they’re context for the decision, which makes the decision easier to defend and easier to revisit if the chosen direction doesn’t pan out.

Prototypes are cheap and frequent

The team expects, by default, to prototype significant ideas before building them. The prototype might be a clickable wireframe, a fake landing page to test demand, a Wizard-of-Oz experiment where humans do the back-end work, or a concierge MVP for early customers. The format follows the question the team is asking.

Testing reshapes the roadmap

When tests reveal something unexpected, the team is willing to change the roadmap. This is the part that breaks down most often in practice. Teams do beautiful discovery work and then ship the original plan anyway, because leadership committed the roadmap to stakeholders six months earlier. The problem isn’t the discovery work; it’s the roadmap structure it has to feed into.

Why do most design thinking initiatives fail?

The pattern of failed design thinking adoption is consistent enough that it’s worth naming directly. Most failures share a few characteristics.

Teams run it as a workshop, not a practice

A team books two days, fills a wall with sticky notes, leaves with a stack of “How might we” statements, and goes back to their normal way of working on Monday. The workshop felt energizing. Nothing changed. Design thinking is a way of working, not an event.

The output doesn’t connect to the build process

The team does empathy work, writes problem statements, and generates ideas. Then those outputs sit in a Miro board while sales requests and executive opinions continue to drive the actual roadmap. No connective tissue links the insights to the decisions about what to build.

Tools shape behavior, and the tools are wrong

If the team’s primary tool is a delivery tracker (Jira, Linear, Asana), the gravitational pull is toward output. Tickets close, sprints end, velocity is measured. None of that rewards or even surfaces the work of design thinking. The team can do all the empathy work they want, but if the tool they live in is a ticket queue, the ticket queue wins.

This is one of the deeper reasons design thinking adoption fails inside product organizations. The discipline asks teams to focus on outcomes and problems; the tooling focuses them on outputs and tickets. Tooling beats methodology when the two conflict.

There’s no place for the strategic context to live

Customer insights, problem statements, prioritized ideas, experiment results, and roadmap commitments tend to live in five different tools, owned by five different people. Without somewhere to bring them together, the connections design thinking should produce, between user needs and what teams build, never form. ProdPad closes this gap: a single place where feedback, ideas, experiments, OKRs, and the roadmap all connect, so design thinking outputs actually become product decisions.

How does design thinking fit with agile and lean?

Commentators often present design thinking, agile, and lean startup as competing frameworks, which is unhelpful. They’re complementary, and most mature product organizations use elements of all three.

Design thinking is strongest at the front of the process: understanding problems and generating solutions. Lean startup, as articulated by Eric Ries, is strongest at the validation step: building MVPs and using build-measure-learn loops to test hypotheses about business viability. Agile is strongest at the delivery step: shipping working software in small increments with frequent feedback.

A useful way to think about it: design thinking helps you figure out what to build, lean startup helps you figure out whether it’s worth building, and agile helps you build it well. The three together form a complete operating model. Teams that adopt only one usually struggle with whatever the other two cover.

The dual-track agile pattern

Many product teams now operate in what’s commonly called dual-track agile, where a discovery track (heavy on design thinking and validation) runs continuously alongside a delivery track (agile sprints). Ideas move from the discovery track to the delivery track only after they’ve earned enough validation to justify the build cost. Marty Cagan describes this pattern in detail, and Teresa Torres puts it at the core of how she frames continuous discovery.

Where does design thinking break down in software products?

Design thinking has roots in physical product design and service design, and some of the assumptions don’t translate cleanly to software.

Software users often don’t know what they need until they see it

The deep empathy work that design thinking emphasizes is harder when users are interacting with a product that doesn’t yet exist. Their reported needs are often anchored to what they’ve used before. This is part of why prototyping matters so much in software: you frequently learn more from a user reacting to a rough prototype than from a user describing what they want.

Software has compounding complexity

Physical products tend to be discrete: you design a chair, you ship a chair. Software products accumulate. Every feature added today shapes what’s possible tomorrow. Design thinking’s emphasis on solving the immediate problem can lead to local optima that create global problems, where the team designed each individual feature well but the overall product feels incoherentThis is where product strategy and product vision have to do work that design thinking alone can’t.

Stakeholder pressure distorts the process

In a consulting engagement, the design thinking team often has explicit air cover to disregard executive opinions and follow the user. In an internal product team, that air cover is harder to come by. The CEO has feature requests. Sales has deal-blocking asks. The board wants a specific KPI moved. Design thinking in this context becomes a political act as much as a methodological one, and methodology alone won’t carry it.

What does good design thinking look like in 2026?

The version of design thinking worth practicing in 2026 looks meaningfully different from the version consultants were selling in 2015. The hype cycle has done its work. The remaining adopters mostly take it seriously, and enough real-world contexts have pressure-tested the methodology that we know where it holds up.

Teams integrate it, rather than bolting it on

Design thinking practices weave into the normal cadence of the product team: weekly customer conversations, ongoing problem framing, continuous prototyping, regular testing.There’s no separate “design thinking workshop” because the entire week is design thinking.

Outcomes anchor the work

Specific business and customer outcomes anchor the work rather than abstract problems. Teams tie problem statements to OKRs or other outcome measures. They evaluate ideas by their probable impact on those outcomes, not by their cleverness.

It accepts AI as part of the toolkit, not a replacement

AI tools now run in nearly every step of the process: synthesizing customer interview transcripts, clustering feedback, generating “How might we” alternatives, drafting prototype copy, even simulating user reactions. The good teams use AI to accelerate the parts that scale (synthesis, ideation breadth) while protecting the parts that don’t (genuine empathy, judgment about which problems matter). The bad teams hand the whole process to an LLM and wonder why their output feels generic.

The 2026 State of B2B Product Management report surfaces this as a genuine concern, with practitioners worrying that AI-generated artifacts will shadow incompetent discovery work and reduce trust in the outputs.

It treats the tool stack as part of the practice

The teams getting real value from design thinking treat their tool stack as part of the design. Customer feedback flows automatically to the place where ideas are formed. Ideas connect to the roadmap. The roadmap connects to OKRs. Experiments connect to outcomes. The connective tissue is the thing. Without it, design thinking is just well-intentioned activity that doesn’t change what ships.

Where this breaks down in practice

The hardest part of design thinking isn’t learning the five stages. It’s holding the line against the gravitational pull of the delivery process. Product teams that successfully practice it usually have three things in common: leadership that protects the discovery work, a roadmap structure that allows discovery findings to change the plan, and tooling that connects what users say to what the team builds.

The teams that struggle usually have all three working against them. Delivery pressure squeezes discovery. The roadmap locks to dates leadership committed before any of the discovery happened. The tooling treats user feedback and the build backlog as separate domains, owned by different teams, viewed in different tools.

Design thinking is a methodology, but methodology alone is never enough. What changes outcomes is the operating model around it: the structures, incentives, and tools that decide whether the discovery work actually flows into the decisions that matter. Get those right, and the five stages take care of themselves. Get those wrong, and no number of workshops will save the product.