Real PM Scenarios
Context → What They Did → PM Decision → Outcome. Every case ends with a PM Lens: four questions that connect the case to your own product work.
Airbnb — Designing for Trust
Design Thinking · Two-Sided Trust · Wizard of Oz PrototypeThe Business Problem
In 2009, Airbnb had a working booking platform but growth had stalled. Sign-ups were happening; repeat bookings were not. The team assumed a conversion problem. Research revealed it was a trust problem and that the trust gap existed on both sides simultaneously.
The host perspective: Hosts were anxious about letting strangers into their homes. The anxiety was about safety, damage, and uncertainty about who the guest really was.
The guest perspective: Guests faced a mirror anxiety. Would the listing match the photos? Would the host be responsive? Could they trust that the space was clean and safe? Both parties needed trust simultaneously and the product only addressed the booking mechanics, not the trust gap on either side.
The problem was not "low booking conversion." The problem was: " Hosts and guests cannot build enough trust through the current product to make the transaction feel safe for either party."
Mapped through all five phases
Empathize
Founders lived with hosts in New York, observing the anxiety of letting a stranger into their home. They also mapped guest anxiety, the worry about arriving to find a space very different from the photos. Two-sided empathy was essential because the trust problem was bilateral.
Define
Reframed from "How do we get more bookings?" to "How do we design a trustworthy experience for both host and guest?" This widened the solution space beyond the booking interface. The problem sizing: millions of potential listings blocked by a trust gap that no amount of UI polish would fix.
Ideate
Multiple ideas were generated: verified IDs, reviews, insurance products, host profiles, and better photography. The photography idea emerged as the most testable at lowest cost, it addressed the guest's visual trust gap without requiring any engineering.
Prototype → Test
Founders personally ran a Wizard of Oz prototype experiment, personally photographing apartments door-to-door in New York. The assumption being tested: professional photography would materially increase booking confidence on the guest side. Success criterion defined before the test: measurable booking lift in photographed listings vs. control group.
Why Wizard of Oz, not a coded solution
The riskiest assumption was not "can we build a photography programme?", it was "will better photos change booking behaviour?" A manual test answered this in days, not months. Building the automation before validating the value would have been the wrong sequencing.
What the PM specifically owned
The Core PM Decision
Choosing a Wizard of Oz prototype over a technical solution. The riskiest assumption was not "can we scale this?" but "will this change behaviour?" The manual test answered the behavioural question first. This required resisting the engineering team's instinct to build the solution directly and instead validating demand before investing in supply.
What would have triggered a pivot
If professional photos were viewed but did not convert to bookings, the team would have returned to Define. The hypothesis would have been falsified: the guest trust problem was not visual. The team would then have had to investigate whether the trust gap was about reviews, host identity verification, or something else entirely.
The validation methodology gap (what the original case study missed)
The 2–3× booking lift is cited as the result, but the original case study presents it without discussing the control group, measurement period, or whether confounders were controlled for. A PM applying this lesson should note: correlation between photography and bookings is evidence, not proof of causation. The next step is a controlled A/B test before scaling the programme globally.
Measurable Results
Booking increase in photographed listings
To validate vs months to build
Professional photo programme scaled worldwide
What remained uncertain after this test
The test validated that visual trust drove bookings but it did not validate that the value persisted at scale, or that hosts who paid for photography would see a proportionate return. These became the next assumptions to test before globalising the programme.
PM Lens
What did the PM own?
The prototype type selection, Wizard of Oz over an engineered solution. And the decision to map both sides of the trust gap, not just the host's perspective.
What assumption was tested?
That professional photography would materially increase guest trust enough to drive booking behaviour, before building any photography programme.
What would have triggered a pivot?
Views without bookings, suggesting the guest trust problem was not visual (photos), but relational (reviews, identity, communication style).
Apply to your product
What is the cheapest artefact that could test your riskiest current assumption? What Wizard of Oz version of your most complex feature could be delivered manually to 10 users this week?
GE Healthcare — The Adventure Series
Design Thinking · Empathy Research · Multi-Component PrototypeThe Business Problem
GE Healthcare's MRI machines were technically excellent. But in pediatric hospitals, up to 80% of child patients required sedation before scans because the machines were terrifying. The process: a child enters a large, cold, loud machine. The adult is removed from the room. The child is alone, in the dark, in a frightening metal tube.
The business problem: sedation is expensive (approximately $750–$1,000 per patient in additional costs), risky (general anaesthesia carries non-trivial clinical risk for children), and operationally slow (it extends each scan by 30–60 minutes). With millions of pediatric MRI scans conducted annually, the opportunity size was significant.
The initial framing was an engineering problem: "How do we make the machine quieter or more compact?" Doug Dietz of GE Healthcare reframed it as a human-centred problem: "How do we make this experience not terrifying for a child?"
Mapped through all five phases
Empathize — the method matters
Dietz observed children entering the MRI suite at child height, physically crouching to see the space as a child would. He conducted structured interviews with pediatric nurses, child psychologists, and children's museum curators. The key insight emerged from multiple perspectives: children in hospitals already respond positively to narrative and imaginary environments. The solution space was in the experience, not the hardware.
Define — the reframe
The insight chain: Observed data (children entering with fear, parents distressed) → Root cause identified (sterile medical environment triggers fear response) → Reframed problem statement: "Children in MRI suites need a way to feel as if they are on an adventure, not undergoing a medical procedure, because the sterile environment activates a fear response that makes stillness impossible." The problem sizing: sedation cost × annual pediatric MRI volume = addressable cost of ≥$500M annually across the US healthcare system.
Ideate → Three separate hypotheses
Three distinct prototype components were identified, each testing a different assumption: 1) Decals on the machine (testing: does visual transformation change the child's emotional response?). 2) Aromatherapy (testing: does scent contribute meaningfully to environment transformation?). 3) Scripted narratives for technicians (testing: does a story-based framing change how children interpret the experience?).
Prototype: three tests, not one
Each component was tested independently before combining them. This was the critical PM decision: treating the three components as separate assumption tests rather than one bundled prototype. This allowed the team to identify which element drove the most impact, and which could be dropped without loss of effectiveness.
What would have triggered a pivot
If the pirate theme had increased anxiety in children who feared pirates, the team would have iterated on the visual theme. If narrative framing had no effect on stillness rates, the scripted technician approach would have been dropped and resources concentrated on the physical environment transformation only.
What the PM specifically owned
The component decomposition decision
The most important PM decision was treating the three prototype components (decals, aromatherapy, scripted narrative) as three separate assumption tests rather than one bundled solution. This required resisting the natural tendency to prototype the "whole concept" and instead testing each element's independent contribution to the outcome. This is assumption mapping applied to a complex, multi-element solution.
The business case: owned by PM
The problem sizing was a PM deliverable before any prototype was built: sedation cost per patient × annual pediatric scan volume × sedation rate reduction target = business case. Without this, the initiative was a design project. With it, it was a strategic investment with measurable ROI and that framing was what secured the resources to run the programme at scale.
Measurable Results
Reduction in sedation requirement at pilot hospitals
Cost saved per patient in avoided sedation
Patient satisfaction scores in transformed suites
PM Lens
What did the PM own?
The decision to decompose the prototype into three separate component tests, treating each element as an independent assumption rather than bundling them into one prototype evaluation.
What assumption was tested first?
That visual environment transformation (decals) would change the child's emotional framing of the experience, the most impactful and cheapest component to test.
What would have triggered a pivot?
If specific themes increased rather than decreased anxiety. The team had a contingency: theme selection could be iterated without changing the core approach.
The digital product equivalent
Any product feature with multiple components. Before building the full feature, decompose it and test each component's assumption independently. Ship the components that are validated; drop the ones that are not.
IDEO — The Shopping Cart Challenge
PDC · Post-Launch Discovery · New Business from Operational DataThe Business Problem
IDEO was given five days to redesign the supermarket shopping cart. The brief had explicit constraints: the cart must still be nestable (to save space in storage), must cost approximately the same as the existing design, and must address documented safety and theft concerns with existing carts.
What makes this a useful PM case study: The constraints are the most instructive part. The team could not ignore them in favour of a pure user-centred solution. The business context required that user needs and operational constraints be balanced simultaneously. This is exactly the PM's problem in product development: desirability AND feasibility AND viability, simultaneously.
Three user groups observed: Regular shoppers (their experience using the cart), store managers (their operational and safety concerns), and buyers (the purchasing managers who actually selected which carts to procure). All three had legitimately different needs and all three had to be satisfied by the same solution.
Mapped through all five phases
Empathize → Synthesis Method
Insights from all three user groups were synthesised using affinity mapping: observations were written on sticky notes, clustered by theme, and then interrogated for the underlying need in each cluster. The synthesis method not just the individual observations, was the source of the key insight: the most dangerous moments with existing carts were the transitions between shopper control and child passenger, not the main shopping loop.
Define → Constraint Mapping
Before ideation, the team explicitly mapped: what is in scope (user safety, shopping experience, child safety), what is out of scope (replacing the nestable form factor entirely), and what is non-negotiable (cost parity, storeability). This is Constraint Mapping, a PM skill that prevents ideation from generating solutions the business can never ship. Many of the most creative ideas generated in the next phase came from working within, not against, the constraints.
Ideate → The Absurdity Insight
One team generated the idea of attaching children to the cart with Velcro, absurd as a literal product, but it surfaced the underlying insight: the child safety problem was about proximity and control. This led directly to the child seat integrated into the cart frame, a less absurd but traceable solution. Tracking how a wild idea leads to a practical solution is the most instructive part of IDEO's facilitation method.
Prototype → Test at Whole Foods
Four sub-groups each prototyped different components. The PM facilitation question: which sub-group prototypes which feature, and how do the components merge? was answered through a structured criteria review: which components addressed the highest-priority safety and usability assumptions? The test at Whole Foods provided immediate behavioural feedback: actual shoppers used the prototype in a live retail environment, not a controlled lab.
What the PM specifically owned
Constraint mapping — the PM-specific Define output
The explicit mapping of in-scope, out-of-scope, and non-negotiable constraints before ideation began was the most PM-specific contribution in this case study. Without this, the ideation session would have generated solutions that could not be manufactured at cost, could not be stored in standard configurations, or could not pass procurement. The PM's job in Define is not just to write the problem statement, it is to scope the solution space before ideation opens it up.
Sub-group allocation: the PM facilitation decision
The decision of which sub-group prototyped which feature component was a PM facilitation call: map each sub-group's background to the component most relevant to their expertise. Engineers prototype the structural mechanics; designers prototype the user interaction; retail experts prototype the operational flow. Optimal feature-to-team matching reduces rework and improves prototype quality for each component.
Measurable Results
The resulting prototype incorporated modular baskets (addressing the theft problem: you take the basket, not the whole cart), an integrated child seat (addressing safety), and a scannable hook system (addressing checkout friction). The test at Whole Foods produced immediate qualitative validation, shoppers found the cart more intuitive for managing children and groceries simultaneously.
What happened next: The IDEO shopping cart challenge was primarily a demonstration of Design Thinking methodology rather than a commercial product brief. The prototype was not manufactured and distributed at scale. The value of the case study is methodological not as a product success story, but as a worked example of how the five phases produce better solutions than starting from assumptions.
The honest caveat for PMs
This case study is 30+ years old. Design Thinking has evolved significantly since the IDEO shopping cart challenge. Use it as a process illustration, not as a current best-practice reference. The Mom Test, Assumption Mapping, and digital prototype methods covered in this module are more directly applicable to modern PM work.
PM Lens
What did the PM own?
Constraint Mapping before ideation, explicitly defining what is in scope, out of scope, and non-negotiable so that the solution space is wide but bounded.
What assumption was tested?
That modular baskets and integrated child management would solve the safety and theft problems without violating the nestability and cost constraints.
What the absurd idea teaches
The Velcro idea was never a real solution but it surfaced the underlying insight about child proximity and control. Track your team's wildest ideas back to the genuine insight they contain.
Apply to your product
For your current initiative: what are the non-negotiable constraints? Map them before ideation begins. The best solutions will emerge from working within them creatively, not from ignoring them.