Before examining what Design Thinking is, understand the structural problem it addresses. New product failure rates are high — and the causes are split between "fuzzy front end" problems (before the product even launches) and execution problems (how it goes to market). DT primarily attacks the fuzzy front end.
Tim Brown (CEO of IDEO) defines design thinking as "a discipline that uses the designer's sensibility and methods to match people's needs with what is technologically feasible and what a viable business strategy can convert into customer value and market opportunity."
| Common Misconception | What DT Actually Is |
|---|---|
| Aesthetics — making products look good | A methodology for solving complex human-centered problems. Shimano's Coasting bike's visual design was intentionally deferred while the experience system was designed first. |
| A downstream activity after the "real" work is done | Frontloaded strategic work. Design thinkers should be involved before any direction is set — not called in to "wrap a beautiful wrapper around an idea." |
| Something only professional designers do | A mindset and methodology anyone can apply. Kaiser had nurses, doctors, administrators, and process designers all using DT methods to redesign shift changes. |
| A linear, step-by-step process | A system of spaces that projects loop back through. Particularly between inspiration and ideation — iteration is the norm, not the exception. |
| About being creative/artistic | About being systematic and human-centered. "99% perspiration" — hard work, direct observation, rapid experimentation, iterative refinement. |
Edison created the electric lightbulb — and then wrapped an entire industry around it. He understood that the bulb was "little more than a parlor trick" without a system of electric power generation and transmission. His genius was conceiving the full marketplace, not just the device.
Note: Edison wasn't always prescient — he initially thought the phonograph would be used mainly for business dictation. But the method of observation → iteration → prototyping → testing is precisely what DT codifies.
The Stanford d.school / IDEO model. Not a one-way pipeline — teams loop back, especially between Empathize→Define and Ideate→Prototype→Test. The process is non-linear by design.
| Stage | Core Activity | Methods | Output |
|---|---|---|---|
| 1. Empathize | Direct observation of users in context. Not surveys — watching, shadowing, interviewing about experience (not preference). Ask "why" repeatedly. | Ethnographic observation, contextual interviews, "a day in the life," shadowing, fly-on-wall observation | Rich behavioral data, surprising observations, emotional insights. The Kaiser nurses' 45-minute debriefing problem surfaced here. |
| 2. Define | Synthesize observations into a clear problem statement. The "How Might We..." (HMW) question format. Reframe the problem based on what you observed, not what you assumed. | Affinity mapping, Point-of-View statement ("User needs to... because..."), HMW questions, journey mapping | A sharp, human-centered problem statement that reframes the original brief. This is where JTBD meets DT — the "job" becomes the "problem to solve." |
| 3. Ideate | Generate as many ideas as possible before evaluating any. Quantity over quality. "Yes, and..." not "yes, but..." Wild ideas welcome — they often seed practical ones. | Brainstorming, brainwriting, SCAMPER, Worst Possible Idea, Crazy 8s (8 sketches in 8 minutes) | A large set of diverse ideas. The goal is to avoid premature convergence — too many teams jump to the first idea that seems feasible. |
| 4. Prototype | Build a cheap, rough version of the idea to make it tangible and learnable. "Prototypes should command only as much time and effort as needed to generate useful feedback." A marker + film canister + clothespin is a prototype. | Physical mockups, paper prototypes, role-playing, storyboards, Wizard of Oz tests (simulate the system) | A testable artifact. Not a finished product — "the more finished a prototype seems, the less likely its creators will pay attention to feedback." |
| 5. Test | Expose the prototype to real users and observe their reactions. Not "do you like it?" but "show me how you'd use this." Failures teach more than successes. Iterate based on what you learn. | User observation, think-aloud protocols, A/B comparisons, speed dating (rapid feedback from many users), video documentation | Refined understanding of the problem (often loops back to Empathize or Define) plus improved prototype directions. |
The Stanford d.school framework (from Prof. Brower's slides) applies DT at two levels: the market/customer level and the organizational level. The same five movements apply — but the inputs and outputs change depending on whether you're designing for a customer or redesigning how an organization thinks.
| Traditional Approach | Design Thinking Approach |
|---|---|
| Problem is defined at the start by leadership or market research | Problem definition is a creative act — what you discover in empathy often changes the problem entirely |
| Customer input collected once (market research) before development begins | Customer is present at every stage; user feedback drives iteration throughout |
| Prototyping happens late (market testing) after significant investment | Prototyping happens early and often; failure is expected and cheap by design |
| Success = product launches; failure = product doesn't reach market | Success = learned something; failure = built something no one can react to |
| Multidisciplinary teams are a "nice to have" for big projects | Interdisciplinary teams are the core engine; insights emerge from disciplinary collision |
Brown describes the design process as "a system of spaces rather than a predefined series of orderly steps." Projects loop — especially between inspiration and ideation — as ideas are refined and new directions are taken.
The circumstances — a problem, opportunity, or change in business fortunes — that motivate the search for solutions. This is where the team defines what they're trying to learn about, not what solution they're building toward.
Shimano: The trigger was growth stagnation. The inspiration space expanded the question from "what new high-end bike?" to "why don't 90% of American adults ride bikes at all?"
Generating, developing, and testing ideas that may lead to solutions. Brainstorming, prototyping, rapid testing. Characterized by divergence (many ideas) followed by convergence (selecting and refining the most promising ones).
Kaiser: Teams brainstormed in workshops, built working prototypes of the new shift-change process in just one week — including new procedures and simple software.
Charting the path to market. Involves communicating, engineering, and deploying the solution. Not a hand-off moment — design thinkers should stay engaged through implementation to protect the intent.
Shimano: Implementation included not just the bike design but in-store retail redesign, a brand platform ("Chill. Explore. Dawdle."), and partnerships with local governments for safe bike paths.
Brown identifies five characteristics of effective design thinkers. These are not innate personality types — they are developed through practice and the right organizational environment.
Imagine the world from others' perspectives. "People first" approach. Notice things others miss. Use observations to inspire innovation — not validate preconceptions.
See contradictory aspects of a problem simultaneously and create solutions that go beyond either/or choices. Roger Martin's "Opposable Mind" — hold tension without resolving it prematurely.
Assume that at least one solution exists better than all existing alternatives — regardless of constraints. Constraints are creative springboards, not dead ends (see Aravind).
Pose questions and explore constraints in creative ways that lead in entirely new directions. Significant innovations come from experimentation, not incremental tweaks.
Enthusiastic interdisciplinary work. At IDEO: engineers + marketers + anthropologists + industrial designers + architects + psychologists. Many have experience in more than one discipline.
The problem: Nurses spent the first 45 minutes of each shift at the nurses' station debriefing the departing shift. Methods varied across every hospital. Critical patient information was routinely missed.
What the DT team observed: "For many patients, each shift change felt like a hole in their care." Nurses noted info on scraps of paper and even on their scrubs.
The reframe (Define stage): The problem wasn't "how to improve debriefing notes" — it was "how to eliminate the gap in patient care during transitions."
The solution: Nurses pass information in front of the patient rather than at the nurses' station. Simple software lets nurses update notes throughout the shift. One week to build the working prototype.
The problem: Shimano faced growth stagnation in high-end road and mountain bike segments. First instinct: find a new high-end product innovation.
DT reframe: Don't ask what product to make — ask why 90% of American adults don't ride bikes at all. Discovery: (1) Nearly everyone had happy childhood cycling memories; (2) Adults were intimidated by Lycra-clad specialist salespeople, complex gear systems, expensive equipment, unsafe roads, and maintenance demands.
The "Coasting" solution: No handlebar controls, no visible cables, back-pedal brakes, auto-shifting 3-speed computer. Designed the whole experience: retail redesign, brand platform ("Chill. Explore. Dawdle. Lollygag."), partnership with governments for safe routes.
Key move: The bike's visual design was intentionally deferred until the experience system was complete. 7 manufacturers built Coasting bikes; 8 more joined in 2008.
The mission: Eradicate needless blindness in India's population including rural poor. Founded 1976 from 11 beds in the founder's home. By 2007: 5 hospitals, 2.3M+ patients/year, 270K+ surgeries.
The constraint-as-innovation: Western intraocular lenses cost $200/pair. Rather than negotiate with suppliers, Aravind built its own manufacturing plant in a hospital basement and produced equivalent lenses for $4/pair.
System design: Eye camps in rural areas for screening; telemedicine trucks for specialist remote consultations; buses to transport patients needing surgery. 60% of patients served for free.
The observed behavior: Many people collect coins from cash purchases in a jar at home, then take them to the bank when the jar is full. It's a painless, nearly invisible savings behavior already exhibited by millions.
The design insight: Don't tell people to save — build the behavior they already do into the debit card system. When a customer uses a debit card, round up to the nearest dollar and deposit the difference into savings automatically.
The emotional job: The real payoff is the monthly statement showing customers they've saved money "without even trying." Bank sweetens the deal: 100% match on change saved in first three months, 5% annually thereafter.
Session 3 is a bootcamp — learning is experiential, not lecture-based. You will go through the DT process in compressed time with your team, likely around a human-centered design challenge. Here's how to approach each stage for maximum quality.
In a bootcamp, you'll often interview a classmate about a real experience. Don't accept the first answer — ask "why?" three to five times. If someone says "I find grocery shopping stressful," ask why. Then why again. The insight is usually two to three levels below the surface: "I feel like I'm failing my family if I don't buy the right things." That's the emotional job. That's what DT can redesign around.
Too broad: "How might we make grocery shopping better?" (infinite scope). Too narrow: "How might we add a self-checkout feature?" (already a solution). Good: "How might we help time-pressed parents feel confident they're feeding their family well — without the planning burden?" The HMW question should feel both constraining (specifies the user and the tension) and generative (doesn't prescribe the solution).
The most common bootcamp failure: someone generates an idea and the team immediately debates its feasibility. Kill the "yes, but" reflex. In ideation, bad ideas are worth surfacing — they often contain a useful kernel. "What if the grocery store came to you?" sounds wild; it leads to the idea of a personal shopper service. Run Crazy 8s: 8 rough sketches in 8 minutes. Volume is the goal.
The whiteboard marker + film canister + clothespin is a real example from IDEO — it gave surgeons a concrete object to react to. In a bootcamp: use paper, sticky notes, post-its, role-play, or storyboards. The goal is to make the idea tangible enough that someone else can react to it. A rough sketch of a user interface is a prototype. A staged roleplay is a prototype. Don't over-engineer it — you'll iterate anyway.
Show the prototype to the person you interviewed. Don't explain how it works — watch them try to use it. Their confusion is data. When they ask "wait, what's this for?" — that's the most valuable thing they could say. Resist the urge to defend your idea. The test stage is about learning, not validation. "We were wrong about X" is a better test outcome than "they liked it."
Connect the failure stats to the DT motivation: "Most new products fail not because the engineering was bad — but because the problem definition was wrong. DT is primarily a tool for getting the problem right before committing to the solution." That's the fuzzy front end argument in one sentence.
If discussion gets surface-level ("DT is about being creative"), push to the structural insight: DT moves the problem definition from a given to a creative act. The value isn't in the brainstorming — it's in the reframe that makes a great solution obvious. Kaiser's insight wasn't "better notes" — it was "the patient experiences a hole in care."
Connect all three sessions: "Outside-In is the orientation (Session 1). JTBD is the lens for understanding the customer's world (Session 2). Design Thinking is the creative process for turning those insights into solutions (Session 3). They're three layers of the same idea." Say this explicitly — Prof. Brower wants students to see this integration.
DT is product management with a different vocabulary. "Empathize" = user research. "Define" = problem statement / "jobs story." "Ideate" = solution brainstorm. "Prototype" = MVP / fake door / paper prototype. "Test" = user testing / A/B test / beta launch. The difference: DT spends more time in Empathize and Define than most PM teams do. That's the discipline worth importing.
Aravind's constraint-driven innovation (manufacturing $4 lenses) mirrors how breakthrough products in emerging markets get built. M-Pesa (Kenya) — mobile money on feature phones. Paystack — solving Nigerian card rails global players ignored. Constraints in African markets force Outside-In design because Inside-Out solutions optimized for Western infrastructure simply don't work.
The Kaiser case is directly applicable to Native's parent onboarding experience. New parents using the app are like patients during shift changes — high anxiety, partial information, need to feel confident quickly. DT approach: shadow new parents during their first week with the app, observe where confusion occurs, reframe from "complete onboarding steps" to "parent feels confident their child is in good hands" — then prototype from that reframe.
Session 1 established the orientation — start with the customer's world. Design Thinking is the organizational methodology for operationalizing that orientation at scale. Outside-In is the "why"; DT is the "how."
JTBD is the lens for understanding the customer's job. DT's Empathize stage is where you discover the job. DT's Define stage is where you articulate it as a problem statement. The two frameworks are sequential: JTBD gives you the target; DT gives you the creative process for hitting it.
You now have the complete Module 1 toolkit: diagnose Inside-Out vs Outside-In → understand the JTBD (3 dimensions) → prescribe a DT-based solution approach. The case analysis should move through all three frameworks in order. DT gives you a concrete "what to do next" recommendation that JTBD alone doesn't provide.
The journey analysis is essentially the Empathize + Define stages applied to a real customer journey. You're doing the first two stages of DT — observing behavior, mapping the journey, identifying friction points — and then using JTBD to explain what job is being failed at each friction point.
DT generates solutions that serve the customer's job better. Better job-serving → stronger downstream advantage → higher price premium (Dawar's logic). This is the chain: DT → better job-fit → downstream competitive advantage → margin. All of Module 1 is about how customer understanding creates pricing power.
Module 2 (CDJ, adoption lifecycle, crossing the chasm) assumes you have a product/service that serves the job. DT is how you ensure that assumption is true before you try to scale it. Crossing the chasm requires a "whole product" — which is a DT output: a complete experience designed around the mainstream customer's job, not just a core technology.