Core Concepts
Five phases. Two roles. Very different responsibilities.
Every phase has a PM layer explaining what you specifically own, decide, and challenge at each step. This is a critical layer which is mostly skipped in many Design Thinking resources!
Empathize
Who has this problem?
Research users through observation, interviews, and engagement. Set aside assumptions and understand the world through the user's lens, including emotional and contextual dimensions that surveys miss.
As a PM, this means...
You own the decision of when there is enough research to move forward, not the researcher. You write the research brief, review the findings, and decide whether the team understands the user deeply enough to define the problem. If not, Empathize continues.
Named after the principle that even your mother will tell you your idea is good. The Mom Test teaches PMs to ask about behaviours, not opinions because opinions are polite and behaviours are honest.
- → Ask: "Tell me about the last time you struggled with X" and not "Would you use this?"
- → Ask about the past, not the future. Past behaviour predicts; future intention flatters.
- → Never mention your solution until you have heard the problem unprompted.
- → Compliments are noise. "That sounds great" contains zero information.
Stakeholder Empathy: The PM's Added Layer
PMs empathise with multiple parties simultaneously: users, engineering, sales, legal, and support. Where the designer focuses on user empathy, the PM must also map stakeholder constraints. These are the parties who will block or enable the solution.
Common Trap
Doing Empathize once at project start and never returning. User context changes as your product evolves. Re-run lightweight research every quarter, not just at project kickoff.
Define
What is the real problem?
Synthesise research into a sharp, human-centred problem statement. This becomes the north star for everything built. A good statement names who has the problem, what they need, and why they cannot currently get it.
As a PM, this means...
You write the problem statement. Not the designer, not the researcher. You synthesise all inputs and make the call. If stakeholders disagree on the problem, that conversation must happen here and not in sprint planning when it costs ten times more to resolve.
Most problem statements are inherited. First Principles Thinking challenges the framing and asks what the most fundamental truth is, stripped of assumptions and analogies.
Instead of accepting "users want a search bar", ask what users are fundamentally trying to accomplish. The answer may be search, but it may also be better categorisation, smarter defaults, or removing unnecessary content altogether.
The Three First Principles Questions
- → What is the user actually trying to accomplish?
- → What is preventing that outcome right now?
- → If we had no existing product at all, how would we solve this from scratch?
Every Define phase should end with a clear, measurable problem statement.
Why the Last Clause Matters
Without a measurable outcome in the problem statement, the team has no objective way to know when they are done. Every problem statement must contain a success metric before ideation begins.
First Principles in Practice
Surface framing: "Users want a faster checkout." First Principles challenge: What are users fundamentally trying to accomplish? Research reveals the issue is trust, not speed. The solution becomes trust signals rather than checkout optimisation.
Problem Sizing
Frequency × Severity × Users = Opportunity Size. If the opportunity is small, stop here before committing resources to ideation and development.
Assumption Mapping
List every assumption embedded in your problem statement. Plot them on a 2×2 of importance vs certainty. High-importance, low-certainty assumptions become the first prototype tests before any solution is built.
Ideate
What could we do?
Challenge assumptions and generate a wide range of potential solutions before narrowing. Volume and variety are the goal in divergent mode. Teams that evaluate while they generate kill their best ideas before they have a chance to develop.
As a PM, this means...
You facilitate convergence, not ideation. Keep the space open long enough to generate truly different ideas and then lead the team through evaluation using a consistent framework: desirability, feasibility, and viability. You add the strategic filter the designer does not own.
There are two distinct modes. Running them simultaneously kills the best ideas. Diverge first, converge second.
- → Divergent: No evaluation. Quantity over quality. Wild ideas are welcome. Build on each other's concepts.
- → Convergent: Structured evaluation. Score ideas against the problem statement, feasibility, and strategic fit.
- → Strategic Filter: An idea that does not connect to your north star metric is a distraction.
Opportunity Sizing Basics
Before committing to prototype one of the top ideas, estimate its value. How many users benefit? How often? What is the revenue or retention impact? Even rough estimates prevent teams from spending weeks on low-value ideas.
Viability Filter: The PM Lens
A creative idea that delights users but does not generate revenue, reduce cost, or create a strategic moat is a nice-to-have. Apply the viability filter here, not during sprint planning.
Confirmation Bias
PMs unconsciously favour ideas that validate their existing hypothesis and dismiss ideas that challenge it.
Countermeasure: Appoint a devil's advocate for every convergence session and force evidence-based scoring.
IKEA Effect
PMs overvalue ideas they personally generated and unconsciously score them higher than alternatives.
Countermeasure: Anonymise ideas before scoring. Remove authorship so the team evaluates ideas, not people.
Prototype
What should we test?
Build the minimum artefact needed to test your most uncertain assumption. A prototype is not a product. It is a learning vehicle. Fidelity should match the risk of the assumption being tested, not the importance of the feature.
As a PM, this means...
You decide what type of prototype to build, not the designer. Every prototype must connect to a specific assumption. The key question is always: "What is the cheapest artefact that answers this question?"
Before investing in a prototype, challenge the assumption that building is the correct answer at all.
- → Build: When the capability is core to your differentiation and no adequate solution exists.
- → Buy: When the capability is commodity and an off-the-shelf solution delivers most of the value.
- → Partner: When the capability requires expertise you do not have internally.
Fidelity should always match the assumption being tested. Higher fidelity than necessary increases cost and can bias feedback.
Decision Rule
- → Concept validity → Paper Sketch
- → Workflow intuition → Clickable Wireframe
- → Willingness to pay → Fake Door Test
- → Technical feasibility → Coded Prototype
High Fidelity Too Early
Building a pixel-perfect prototype to test a concept that could have been validated with a paper sketch. High fidelity biases users toward aesthetics rather than concept validity and wastes engineering and design effort on an unvalidated idea.
Test
Did it work?
Test prototypes with real users to gather evidence and make a decision. The output is not just learnings, it is a decision: proceed, iterate, or stop. That decision must be guided by pre-defined criteria rather than post-hoc interpretation.
As a PM, this means...
You write the test success criteria before a single user session runs. "Users found it useful" is not a criterion. "7 of 10 users completed the primary task without assistance" is a criterion. The criteria exist to prevent confirmation bias from overriding the data.
After testing, the PM makes one of three calls. This is often the most consequential decision in the Design Thinking process.
Proceed
Hypothesis validated. Success criteria met. Move forward with confidence.
Iterate
Partial signal. The prototype partially worked, but specific elements require refinement.
Pivot or Stop
A fundamental assumption was wrong. Return to Define or Empathize rather than polishing the wrong solution.
Behaviour Beats Sentiment
"Users loved it in testing" is not validation. Users are polite. What matters is whether they completed the task, how long it took, where they struggled, and whether they would choose it over their current solution. Measure behaviour, not sentiment.
The Hardest Call
Iterating on a prototype when the results reveal a problem definition issue. Polishing the solution to the wrong problem is the most expensive mistake in product development.
Sunk Cost Bias
After investing time in a prototype, teams interpret ambiguous results as validation because stopping feels like admitting the effort was wasted.
Countermeasure: Define stop criteria before building the prototype. Agreed criteria override emotional attachment.
Optimism Bias
PMs consistently overestimate how many users will succeed, leading to weak success criteria and overly positive interpretations.
Countermeasure: Calibrate success criteria using historical benchmarks rather than intuition.
Design Thinking is non-linear by design. A test result can send you back to Define or even back to Empathize. This is not failure. This is the process working correctly.
One of the most frequently missing topics in DT curricula. Applying the process to the wrong problem type adds overhead without insight.
Technical or infrastructure problems
When the uncertainty is about whether we can build something and not whether users need it. A database migration or CI/CD pipeline decision needs a spike, not a discovery sprint.
Regulatory or compliance requirements
When the requirement is externally mandated and non-negotiable. GDPR compliance does not benefit from empathy research, it benefits from legal guidance and technical implementation.
Well-understood problems with strong existing data
When you already have clear quantitative evidence of exactly what the problem is and who has it. Empathize adds overhead when the problem is already well-defined from usage data.
Incident response or urgent bug fixes
When a production issue needs a fix within hours. Design Thinking timelines are incompatible with P0 incident response. The problem is known; the urgency is absolute.