Design Thinking in Product Management

Chapter 2
Design-Thinking Models and Product Lifecycle

Post Graduate Program in Product Management
Design Thinking in Product Management   •   Post Graduate Diploma

Design-Thinking Models and Product Lifecycle

Introduction

Design thinking is a human-centred approach to addressing uncertain, complex and poorly structured problems. In product management, it connects customer understanding with opportunity discovery, concept development, experimentation, delivery and continuous improvement. It is not simply a workshop technique or a synonym for visual design. Rather, it is a way of organizing inquiry and decision-making when the product team does not yet know which customer problem is most important, which solution will work, or how value will be sustained in practice.

Product managers use design-thinking models to make uncertainty visible and manageable. A model provides a useful sequence of activities, but it should not be treated as a rigid production line. Real product work involves loops: research may reveal that the original problem was incorrectly framed; testing may require a new prototype; delivery data may expose a new unmet need; and post-launch learning may restart discovery.

This chapter compares four influential approaches: the Stanford d.school process, the Double Diamond, the IDEO model and the Design Council framework. It then shows how these approaches can be adapted across the product lifecycle, from discovery to delivery, growth, maturity and retirement.

Learning Objectives

By the end of this chapter, the learner should be able to:

  1. Explain the purpose, logic and limitations of major design-thinking models.
  2. Compare the Stanford d.school, Double Diamond, IDEO and Design Council approaches.
  3. Distinguish divergent and convergent thinking and relate them to product decisions.
  4. Select and adapt an iterative process for discovery, delivery and lifecycle management.
  5. Integrate design thinking with agile product development, experimentation and outcome measurement.
  6. Evaluate ethical, organizational and governance implications of design-led product decisions.

1. Design Thinking in Product Management

A product manager operates between customer needs, organizational strategy, technology, operations and commercial constraints. These interests rarely align automatically. Design thinking contributes three capabilities.

First, it improves problem definition. Teams often begin with a requested feature rather than an investigated need. For example, “add a dashboard” may conceal the actual problem: users cannot identify which operational issue requires attention.

Second, it makes assumptions testable. A product concept contains assumptions about users, behaviour, value, feasibility and viability. Interviews, observation, prototypes and experiments can provide evidence before substantial investment.

Third, it supports learning through iteration. Instead of assuming that a plan is correct, the team treats each activity as a way to reduce uncertainty and improve the next decision.

Design thinking is especially useful when:

  • the customer problem is ambiguous;
  • stakeholders disagree about priorities;
  • users have difficulty articulating latent needs;
  • the cost of building the wrong solution is high;
  • a new technology creates opportunities without an established market;
  • social, ethical or accessibility consequences must be considered.

It is less useful when a problem is already fully specified and the principal task is routine execution. Even then, usability testing and service improvement may remain valuable.

Important Terminology

User or customer: A person or organization that experiences, uses, purchases or is affected by a product.

Need: A condition or outcome that matters to a user; it is not necessarily the same as a requested feature.

Insight: An evidence-based interpretation of behaviour, motivation or context that reveals an opportunity.

Point of view: A focused statement describing a target user, a meaningful need and the underlying reason it matters.

How-might-we question: An open-ended reframing that converts a problem into an opportunity for exploration.

Prototype: A representation of a concept used to learn, communicate or test; it may be a sketch, role-play, clickable interface or technical experiment.

Iteration: A deliberate cycle of making, testing, learning and revising.

Desirability: Whether people want or value the proposed solution.

Feasibility: Whether the organization can build and operate it with available or attainable capabilities.

Viability: Whether the solution can support a sustainable business or operating model.

Usability: The extent to which specified users can achieve specified goals effectively, efficiently and satisfactorily in context.

2. Divergent and Convergent Thinking

Most design-thinking frameworks alternate between two modes.

Divergent thinking expands the field of possibilities. Teams gather varied evidence, generate multiple interpretations, identify several opportunities and produce alternative concepts. Its purpose is breadth, not immediate agreement.

Convergent thinking narrows possibilities through synthesis, prioritization, testing and decision-making. Its purpose is focus, not premature certainty.

A common failure is premature convergence: selecting the first plausible problem or solution before examining alternatives. The opposite failure is endless divergence: generating ideas without criteria, evidence or a decision path. Effective product management defines when the team will widen inquiry, when it will narrow it, and what evidence is sufficient for the next investment decision.

A useful adaptation is to separate three types of uncertainty:

UncertaintyTypical questionUseful evidence
Problem uncertaintyIs this a significant problem for a meaningful segment?Interviews, observation, behavioural data
Solution uncertaintyWill the proposed experience solve it?Prototypes, usability tests, experiments
Business or operating uncertaintyCan it be delivered and sustained?Technical spikes, business modelling, pilots, unit economics

These uncertainties may overlap, but they should not be confused. A technically feasible feature can still solve an unimportant problem; a desirable solution may be commercially or operationally unsustainable.

3. The Stanford d.school Process

The Stanford d.school commonly presents design thinking through five modes: Empathize, Define, Ideate, Prototype and Test. The modes are often shown sequentially, but the intended practice is iterative rather than linear.

Empathize

Empathy involves understanding people in context. Product teams may use contextual interviews, observation, diary studies, journey mapping, support-ticket analysis and analysis of behavioural data. The objective is not to collect opinions alone, but to understand what people do, why they do it, what constrains them and what consequences follow.

Good empathy research distinguishes stated preferences from observed behaviour. A customer may say that speed is most important but repeatedly choose a slower option because it provides reassurance or control.

Define

The team synthesizes evidence into a focused problem statement or point of view. A strong definition identifies a particular user and meaningful need without prescribing a solution. “Busy clinicians need a way to review urgent patient information quickly because interruptions make conventional sequential review unsafe” is more useful than “build an AI dashboard.”

Ideate

Ideation generates alternative ways to address the defined need. Techniques include brainstorming, brainwriting, analogous inspiration, extreme-user scenarios and constraint-based ideation. Quantity can be useful early, but ideas must later be assessed against user value, feasibility, viability, accessibility, safety and strategic fit.

Prototype

A prototype is an instrument for learning. Low-fidelity prototypes are appropriate when the team is testing structure, language or workflow. Higher-fidelity prototypes are justified when visual behaviour, performance or stakeholder confidence must be examined. A prototype should make a specific assumption visible.

Test

Testing exposes the prototype to representative users or operational conditions. The team should define what it wants to learn, recruit relevant participants, observe behaviour and record evidence. Testing is not a demonstration designed to obtain approval. Negative findings are valuable because they prevent investment in weak assumptions.

The d.school process is particularly useful for teaching and for early discovery because it gives teams a memorable vocabulary. Its limitation is that it can appear user-centred but under-specify business strategy, organizational implementation, service operations and post-launch measurement.

4. The Double Diamond

The Design Council’s Double Diamond, introduced in 2005 and subsequently developed through its framework for innovation, depicts four activities: Discover, Define, Develop and Deliver. The two diamonds represent two cycles of divergence and convergence.

  • Discover: Explore the situation, users, stakeholders and evidence.
  • Define: Interpret findings and identify the most valuable problem or opportunity.
  • Develop: Generate and evaluate alternative responses.
  • Deliver: Test, refine and implement solutions.

The first diamond concerns doing the right problem; the second concerns developing the right response. The model explicitly challenges the assumption that product work begins with a fixed problem and proceeds directly to a solution.

The Double Diamond is valuable for cross-functional communication because it makes the shape of uncertainty visible. It also accommodates policy, service and organizational change, not only digital interfaces. Its limitations are that the visual symmetry can imply equal time in each phase, whereas real work is uneven, and that it does not prescribe particular research methods or decision criteria.

5. The IDEO Model

IDEO’s human-centred design practice is often summarized as Inspiration, Ideation and Implementation. The model emphasizes movement from understanding people and context, through generating and selecting ideas, to making solutions real and learning from their use.

Inspiration

Inspiration involves identifying opportunities through field research, conversations, analogous settings, cultural analysis and stakeholder engagement. The emphasis is on gaining a rich understanding of people’s lives rather than asking only what feature they want.

Ideation

Teams synthesize research, frame opportunities, generate concepts and make rough prototypes. Ideation is collaborative and benefits from diverse expertise. The facilitator must create psychological safety while also ensuring that concepts are connected to evidence.

Implementation

Implementation includes piloting, refining, operationalizing and scaling the concept. This phase acknowledges that a product is not successful merely because a prototype is attractive. Distribution, support, training, pricing, policy, technology, partnerships and measurement affect whether value is realized.

IDEO’s model is especially helpful when a product is part of a broader service or ecosystem. However, the labels are broad and may require supplementation with explicit product strategy, prioritization, technical governance and quantitative measurement.

6. The Design Council Framework

The Design Council’s current framework, often called the Double Diamond framework, describes design as a process of discovering, defining, developing and delivering. It emphasizes four principles:

  1. Put people first: Understand the needs, capabilities and aspirations of those affected.
  2. Communicate visually and inclusively: Use shared representations and include diverse perspectives.
  3. Collaborate and co-create: Treat design as a multidisciplinary activity rather than an isolated specialist function.
  4. Iterate, iterate, iterate: Use early learning to improve the response before and after implementation.

The framework also stresses that design is not linear. The team may return from delivery to discovery, and learning may reveal that the problem itself requires reframing. This is important for product managers because launch is not the end of design work.

The Design Council framework is sometimes treated as identical to every version of the Double Diamond. In practice, the Double Diamond is the central representation, while the broader framework includes principles, methods and an emphasis on social and organizational context. Distinguishing the diagram from the wider practice prevents over-simplification.

7. Comparing the Models

DimensionStanford d.schoolDouble Diamond / Design CouncilIDEOProduct-management implication
Core structureFive modesFour activities in two diamondsThree broad spacesChoose the level of detail needed
Main emphasisEmpathy and iterative makingProblem framing and solution developmentHuman-centred innovation through implementationLink research to delivery and adoption
Typical useWorkshops and discoveryPortfolio, service and innovation projectsAmbiguous innovation and service designAdapt rather than copy the model
StrengthClear practical vocabularyMakes divergence/convergence explicitConnects inspiration to implementationSupports cross-functional alignment
LimitationMay understate business and operationsCan appear overly symmetricalBroad phases need governanceAdd evidence gates and lifecycle metrics

These models are complementary rather than mutually exclusive. A team might use the Double Diamond to communicate the overall programme, the d.school modes to structure a discovery sprint, IDEO’s implementation logic to plan a pilot, and agile practices to manage delivery.

The correct question is not “Which model is universally best?” but “Which representation helps this team make the next high-quality decision?”

8. Adapting Design Thinking Across the Product Lifecycle

A product lifecycle includes more than development. A practical lifecycle may contain discovery, validation, delivery, launch, growth, maturity and retirement. Design thinking remains relevant throughout, but the dominant uncertainties and methods change.

Discovery

The objective is to identify a significant problem and a strategically relevant opportunity. Activities include stakeholder mapping, segmentation, contextual research, service blueprints, market analysis and problem framing. The principal output is not a requirements document; it is a set of evidence-supported opportunity hypotheses.

A product manager should avoid asking research participants to design the product. Instead, investigate goals, workarounds, constraints, emotions, decision processes and consequences. Research should include non-users and people who are excluded or disadvantaged by current solutions.

Validation

Validation tests whether a proposed response is desirable, usable, feasible and viable. A concept can be tested at multiple levels: a paper workflow, clickable prototype, concierge service, technical spike, landing-page experiment or limited pilot. The method should match the assumption and the risk.

A useful evidence register records the assumption, test, participants or data source, result, confidence and decision. Confidence is not a claim of absolute truth; it indicates how much uncertainty has been reduced and what remains unknown.

Delivery

During delivery, design thinking must operate alongside engineering, security, compliance, analytics and operations. Product discovery does not stop when development begins. Designers and product managers continue to test workflows, clarify acceptance conditions, evaluate edge cases and assess accessibility.

Agile backlogs should express outcomes and user value rather than merely lists of interface components. A cross-functional team can maintain a dual-track pattern: discovery investigates future work while delivery builds validated increments. The two tracks must communicate closely so that research does not become detached from technical reality.

Launch and Adoption

Launch is an operational and learning event. Teams should define onboarding, support, communication, training, instrumentation and rollback responsibilities. Early usage data should be interpreted with qualitative evidence. Low adoption might indicate poor awareness, weak value, confusing interaction, inappropriate targeting or an organizational barrier.

Growth and Maturity

At growth, the team may optimize activation, retention, accessibility, reliability and cost. Design research should examine new segments and unintended consequences. At maturity, improvement may involve service simplification, interoperability, automation, localization or redesign for changing expectations.

Retirement

Retirement is also a design problem. Users may depend on the product, and discontinuation can create financial, accessibility or safety risks. Responsible retirement includes notice, migration support, data export, alternatives, contractual review and secure deletion where appropriate.

9. Selecting and Combining Processes

A process should be selected according to uncertainty, consequence, reversibility and organizational context.

SituationSuitable emphasisExample activities
Unknown customer problemDiscover and empathizeObservation, interviews, journey mapping
Several plausible opportunitiesDefine and convergeSynthesis, prioritization, opportunity sizing
Uncertain interaction or workflowPrototype and testRole-play, usability test, clickable prototype
Technical or operational riskDevelop and implementTechnical spike, pilot, service rehearsal
Existing product underperformingIterate across lifecycleBehavioural analytics, support research, redesign
High-risk domainEvidence, governance and staged releaseSafety review, accessibility assessment, audit trail

A practical adapted process can use six repeatable steps:

  1. Frame the decision: What must the team decide, by when, and what would make the decision consequential?
  2. Explore the system: Study users, non-users, stakeholders, constraints and existing workarounds.
  3. Synthesize and prioritize: Identify patterns, tensions and opportunities; state assumptions explicitly.
  4. Create alternatives: Generate several concepts before selecting one.
  5. Test proportionately: Choose the cheapest credible test for the riskiest assumption.
  6. Learn and govern: Decide whether to proceed, revise, pause or stop, and record the rationale.

This process is iterative because any step may send the team backward. It is disciplined because iteration is tied to a decision and evidence rather than continuous activity without closure.

10. Worked Application: An Illustrative Digital Health Case

Background

A fictional regional clinic wants to reduce missed follow-up appointments. The initial request is for a mobile reminder application. The product manager does not accept the request as the problem definition.

Problem exploration

Interviews with patients, reception staff and clinicians reveal several causes: some patients lack reliable data access; appointment times change; messages use unfamiliar medical terms; and patients fear being judged when they need to reschedule. The problem is therefore not simply absence of reminders.

Using the Double Diamond, the team first discovers the broader service context and then defines the opportunity as: “Patients need a clear, low-friction way to understand and change follow-up arrangements because uncertainty and embarrassment contribute to missed care.”

Concept development

The team generates alternatives: SMS reminders with plain language, a call-back option, a rescheduling link, a community health-worker workflow and a multilingual voice message. A prototype of the complete service—not only the interface—allows patients and staff to role-play reminder and rescheduling scenarios.

Testing and delivery

The prototype reveals that patients prefer a direct rescheduling option, while staff need rules preventing inappropriate changes. A limited pilot tests several message formats and operational workflows. The team monitors successful confirmations, completed rescheduling and staff workload, while conducting interviews about comprehension and trust.

The product manager should not infer success from message-open rate alone. A message may be opened without being understood, and attendance may be affected by transport or health conditions outside the product’s control. Results should therefore be triangulated across behavioural, qualitative and operational evidence.

Ethical and governance considerations

Health information is sensitive. The service requires data minimization, access control, secure communication, informed governance and clear retention practices. The team must consider patients with disabilities, limited literacy, language differences and unreliable connectivity. Automated messages should not expose confidential information on a shared device. A human escalation route is necessary when a patient indicates urgent need.

Learning points

  1. The requested feature was narrower than the service problem.
  2. Research included users, staff and operational constraints.
  3. Prototyping tested the service system, not only the screen.
  4. Iteration connected qualitative insight with operational evidence.
  5. Ethical and accessibility requirements shaped the concept from the beginning.

11. Measurement and Decision Quality

Design thinking does not eliminate the need for metrics. It improves the quality of the questions that metrics address. Product teams should distinguish output measures from outcome measures.

  • Output: number of features released, prototypes tested or interviews completed.
  • Outcome: improved task completion, reduced missed appointments, increased retention or reduced support burden.
  • Guardrail: privacy incidents, accessibility failures, unsafe behaviour or inequitable impact.

Metrics must be interpreted in context. An increase in engagement may be beneficial for a productivity tool but harmful for an addictive service. A reduction in support contacts may indicate improved usability—or that users have abandoned the product.

Where experiments are used, teams should specify the target population, intervention, comparison, outcome, duration and possible harms before collecting results. Randomized experiments can estimate causal effects under suitable design conditions, but they may be inappropriate when sample sizes are small, risks are high or withholding a beneficial service is unethical. Qualitative research and observational evidence remain essential for explaining mechanisms and discovering unanticipated effects.

12. Organizational and Managerial Implications

Design thinking changes how product work is governed.

Leadership: Leaders must create permission to investigate and challenge an initial brief. If teams are rewarded only for shipping, they may suppress negative evidence.

Structure: Cross-functional teams should include product, design, engineering, research, operations, data and relevant domain expertise. Collaboration is not achieved merely by placing specialists in the same meeting; roles, decision rights and shared outcomes are required.

Portfolio management: Not every idea deserves a full build. Small discovery investments can help determine which opportunities merit larger delivery investments. Staged funding reduces exposure to untested assumptions.

Documentation: Teams should record research evidence, decisions, assumptions, trade-offs and unresolved risks. This supports continuity when team members change and provides an audit trail in regulated contexts.

Culture: Psychological safety is necessary for reporting failed tests and inconvenient findings. A failed prototype is not necessarily a failed team; it may be a successful prevention of waste.

13. Limitations and Critical Perspectives

Design thinking has important limitations.

First, it can become a branded vocabulary for practices that already existed in ethnographic research, participatory design, systems thinking and service design. The label should not substitute for methodological quality.

Second, empathy activities can produce shallow or extractive research. Listening to users is not equivalent to sharing their lived experience. Researchers must examine power, representation and interpretation.

Third, prototypes and workshops can create false confidence. Positive reactions in a facilitated session do not prove sustained behaviour, market demand or operational feasibility.

Fourth, human-centred design may underweight non-human stakeholders, environmental effects and structural conditions. A product can be convenient for an individual while increasing inequality, surveillance or ecological cost.

Fifth, consensus is not always the correct objective. Product managers must sometimes make a transparent decision amid disagreement, particularly when evidence is incomplete or stakeholder interests conflict.

The remedy is not to abandon design thinking but to combine it with systems analysis, technical assessment, commercial reasoning, accessibility practice, safety engineering, legal review and responsible research.

14. Technology, AI and Contemporary Practice

Digital collaboration tools, analytics, generative AI and simulation can accelerate research synthesis, prototyping and scenario generation. AI may help cluster interview transcripts, generate alternative interface copy or identify patterns in support data. However, AI-generated interpretations can reproduce bias, omit minority experiences or present speculation as fact.

Human researchers remain responsible for consent, confidentiality, source verification, interpretation and decision-making. Sensitive research data should not be entered into systems without appropriate contractual, security and privacy controls. Teams should disclose material use of automated analysis where it affects participants or consequential decisions.

Contemporary design practice increasingly emphasizes inclusive design, participatory design, trauma-informed research, sustainable service design and systems thinking. These developments extend the question from “Can we make this usable?” to “Who benefits, who bears the risk, what system does this reinforce, and what happens at scale?”

Chapter Summary

Design thinking is an iterative approach to understanding people, framing meaningful problems, creating alternatives, testing assumptions and implementing learning. The Stanford d.school process uses Empathize, Define, Ideate, Prototype and Test. The Double Diamond and Design Council framework organize work into Discover, Define, Develop and Deliver, emphasizing divergence and convergence. IDEO presents a broad movement through Inspiration, Ideation and Implementation.

No model should be applied mechanically. The d.school process is accessible for structured discovery; the Double Diamond clarifies problem and solution spaces; IDEO links human insight with implementation; and the Design Council framework emphasizes collaboration, inclusion and iteration. Product managers can combine these models with agile delivery, staged investment, experimentation and lifecycle governance.

Across discovery, validation, delivery, launch, growth, maturity and retirement, the central discipline is matching the method to the uncertainty and decision at hand. Effective practice integrates qualitative and quantitative evidence, includes diverse and affected stakeholders, tests risky assumptions early, and treats ethics, accessibility, privacy and operational feasibility as design requirements rather than late-stage checks.

Key Terms

Design thinking: A human-centred, iterative approach to solving complex problems.

Divergent thinking: Expanding the range of possibilities or interpretations.

Convergent thinking: Narrowing possibilities through synthesis, evaluation and choice.

Empathy: Understanding people’s experiences, contexts and motivations.

Problem framing: Defining the situation and opportunity without prematurely prescribing a solution.

Point of view: A focused statement connecting a target user, need and meaningful reason.

Ideation: The generation and exploration of alternative concepts.

Prototype: A representation used to learn, communicate or test an assumption.

Usability testing: Observing representative users attempting relevant tasks.

Double Diamond: A framework of Discover, Define, Develop and Deliver.

Stanford d.school process: Empathize, Define, Ideate, Prototype and Test.

IDEO model: Inspiration, Ideation and Implementation.

Design Council framework: A human-centred, collaborative and iterative framework centred on the Double Diamond.

Desirability: The extent to which users value or want a solution.

Feasibility: The extent to which a solution can be built and operated.

Viability: The extent to which a solution can be sustained economically or organizationally.

Dual-track development: Coordinating ongoing discovery with delivery of validated work.

Guardrail metric: A measure used to detect harmful or unacceptable side effects.

Service blueprint: A representation of user-facing and backstage service activities.

Iteration: Repeated learning and refinement based on evidence.

Review Questions

Short Answer Questions

  1. What is the difference between divergent and convergent thinking?
  2. List the five modes of the Stanford d.school process.
  3. What do the two diamonds in the Double Diamond represent?
  4. Distinguish desirability, feasibility and viability.
  5. Why should a product team prototype a service rather than only a screen?

Long Answer Questions

  1. Compare the Stanford d.school process, the Double Diamond and the IDEO model in terms of structure, strengths and limitations.
  2. Explain how design thinking can be integrated with agile product delivery without becoming a sequence of disconnected workshops.
  3. Discuss the role of research and synthesis in defining a product opportunity.
  4. Explain how design-thinking activities should change across discovery, validation, launch, maturity and retirement.
  5. Critically evaluate the claim that design thinking is inherently human-centred and ethical.

Analytical / Application Questions

  1. A team receives a request to build a loyalty dashboard, but customer-support evidence suggests that users do not understand reward eligibility. Apply the Double Diamond to reframe and investigate the opportunity.
  2. Select a suitable combination of design-thinking methods for a safety-sensitive product with uncertain user needs and strict operational constraints. Justify your sequence and evidence gates.
  3. An experiment increases engagement but also increases complaints from users with disabilities. Explain how the product manager should interpret the evidence, identify guardrails and decide the next iteration.

Multiple Choice Questions with Answers

Question 1

Which activity is primarily associated with the Define mode in the Stanford d.school process?

A. Synthesizing evidence into a focused problem statement

B. Generating as many concepts as possible

C. Building a high-fidelity production system

D. Measuring post-launch revenue only

Correct Answer: A. Synthesizing evidence into a focused problem statement

Question 2

What do the two diamonds in the Double Diamond primarily communicate?

A. The need for two independent product teams

B. Alternation between divergence and convergence in problem and solution spaces

C. A fixed sequence that cannot be revisited

D. The distinction between hardware and software development

Correct Answer: B. Alternation between divergence and convergence in problem and solution spaces

Question 3

Which IDEO phase most directly concerns piloting, operationalizing and scaling a concept?

A. Inspiration

B. Ideation

C. Implementation

D. Observation

Correct Answer: C. Implementation

Question 4

A prototype is best understood as:

A. A final product released to all customers

B. A representation used to learn about an assumption

C. A legal approval document

D. A replacement for customer research

Correct Answer: B. A representation used to learn about an assumption

Question 5

Which statement best distinguishes feasibility from viability?

A. Feasibility concerns whether users want it; viability concerns usability

B. Feasibility concerns whether it can be built and operated; viability concerns sustainability

C. Feasibility concerns branding; viability concerns visual design

D. Feasibility and viability are identical concepts

Correct Answer: B. Feasibility concerns whether it can be built and operated; viability concerns sustainability

Question 6

During product discovery, which evidence is most directly useful for understanding how users behave in context?

A. Contextual observation

B. A final sales forecast

C. A completed production deployment

D. A stakeholder’s preferred feature list

Correct Answer: A. Contextual observation

Question 7

Why should product teams use guardrail metrics?

A. To maximize the number of features released

B. To detect harmful or unacceptable side effects of an intervention

C. To replace all qualitative research

D. To ensure every experiment produces a positive result

Correct Answer: B. To detect harmful or unacceptable side effects of an intervention

Question 8

A product team discovers during usability testing that its original problem statement is wrong. What is the most appropriate design-thinking response?

A. Ignore the finding to preserve the roadmap

B. Return to problem framing and revise the opportunity

C. Release the prototype unchanged

D. Stop collecting evidence permanently

Correct Answer: B. Return to problem framing and revise the opportunity

Question 9

Which practice best reflects responsible use of AI in design research?

A. Treating automatically generated themes as verified facts

B. Uploading sensitive data to any free AI tool

C. Reviewing AI-assisted analysis for bias, accuracy and confidentiality

D. Removing human researchers from consequential decisions

Correct Answer: C. Reviewing AI-assisted analysis for bias, accuracy and confidentiality

Question 10

Which lifecycle statement is most accurate?

A. Design thinking ends at product launch

B. Retirement requires no user-centred planning

C. Post-launch evidence can reveal the need to restart discovery

D. Discovery is appropriate only after engineering is complete

Correct Answer: C. Post-launch evidence can reveal the need to restart discovery

Design Thinking in Product Management
Chapter 2 of 15