Ambiguity and Curveball PM Case Framework

What's being tested

Ambiguity and curveball cases test whether a Product Manager can impose structure when the prompt is vague, unfamiliar, or intentionally odd. DoorDash cares because PMs operate in a three-sided marketplace where customer demand, merchant operations, and Dasher supply interact in nonlinear ways; a good answer must balance user empathy, business impact, and operational feasibility. The interviewer is probing how you clarify the problem, choose metrics, identify constraints, prioritize options, and communicate tradeoffs without over-engineering or freezing. Strong candidates show calm judgment: they do not need the “right” answer immediately, but they do need a coherent way to find it.

Core knowledge

Clarifying questions are not a formality; they define the case boundary. Ask who the target user is, what goal matters, what geography/timeframe applies, whether this is a growth, retention, monetization, or quality problem, and what constraints are fixed.
DoorDash marketplace framing usually involves consumers, merchants, and Dashers. Any recommendation should consider impact on order volume, conversion rate, average order value, merchant profitability, Dasher earnings, on-time delivery rate, and support contact rate.
Problem decomposition should be MECE enough to guide action. For example, a decline in orders can be decomposed as: fewer visitors, lower restaurant availability, lower cart conversion, higher fees, worse ETA, payment issues, cancellations, or external seasonality.
North Star metrics should map to the case goal. For consumer growth, use monthly active consumers, order frequency, or new user activation. For marketplace quality, use delivery defect rate, lateness, cancellation rate, and refund rate. For profitability, use contribution margin per order.
Guardrail metrics prevent narrow optimization. If you propose lowering delivery fees to increase conversion, guardrails include gross profit, Dasher pay, merchant commission satisfaction, ETA, and order batching quality. DoorDash PMs must avoid “growth at any cost” answers.
Root-cause analysis should separate symptoms from drivers. A useful equation is:
$\text{Orders} = \text{Traffic} \times \text{Store Coverage} \times \text{Menu Conversion} \times \text{Checkout Conversion}$

Then segment by city, cuisine, time of day, customer tenure, subscription status, and device platform.
Curveball product design still needs a user, pain point, and success metric. If asked something unusual like “DoorDash for airports” or “delivery to a hiking trail,” do not jump to features. Identify the high-friction moment, willingness to pay, operational complexity, and whether DoorDash has a right to win.
Prioritization frameworks are useful only if tied to judgment. RICE can structure options:
$\text{RICE} = \frac{\text{Reach} \times \text{Impact} \times \text{Confidence}}{\text{Effort}}$

But explain why one dimension dominates, such as safety, trust, regulatory risk, or merchant burden.
Launch/no-launch reasoning should include a reversible pilot. For ambiguous ideas, propose a constrained test: one market, one user segment, limited merchant set, clear success threshold, and pre-defined rollback criteria. Avoid nationwide launches for unvalidated behavior.
User empathy should be specific, not generic. A busy parent optimizing dinner, a late-night college student, a merchant with thin margins, and a Dasher trying to maximize hourly earnings have different needs. Tie product choices to those needs.
Marketplace tradeoffs often involve liquidity. More demand without enough Dashers increases ETA; more Dashers without demand lowers earnings; more merchants without quality control increases choice but can hurt reliability. Mention which side of the marketplace is constrained.
Communication under ambiguity matters as much as the content. A strong structure is: clarify goal, define users, map the system, identify hypotheses, prioritize bets, define metrics, propose rollout, and state risks. Narrate your assumptions explicitly.

Worked example

DoorDash orders are down 10% in New York—what do you do?

In the first 30 seconds, a strong candidate would clarify whether the drop is week-over-week, year-over-year, or against forecast; whether it affects all of New York or specific zones; and whether the goal is diagnosis, immediate mitigation, or long-term recovery. They would state an assumption like: “I’ll treat this as a consumer order-volume decline in NYC over the last two weeks, and I’ll separate demand, supply, merchant, and product causes.”

The answer should be organized around four pillars. First, confirm the metric: check whether completed orders fell versus placed orders, because a cancellation spike is different from lower demand. Second, segment the decline by borough, cuisine, customer cohort, time of day, DashPass status, device platform, and acquisition channel. Third, map the funnel: app opens, restaurant impressions, menu views, cart starts, checkout starts, payment success, dispatch, and completed deliveries. Fourth, identify likely hypotheses: higher fees, worse ETA, restaurant closures, Dasher undersupply, weather, competitor promotions, app bugs, or local events.

One explicit tradeoff to flag is speed versus certainty. If the data shows late-night Manhattan orders dropped because ETA increased, you might quickly boost Dasher incentives or reduce long-distance restaurant exposure, but that could reduce margin or customer selection. The PM answer should recommend a short-term containment plan plus a longer diagnostic plan.

A strong close would be: “If I had more time, I’d quantify the contribution of each funnel step to the 10% decline, identify the largest controllable driver, and propose a city-level experiment or operational intervention with guardrails on contribution margin, Dasher earnings, and customer retention.”

A second angle

How would you design DoorDash for airports?

This is also an ambiguity case, but the primary challenge is not diagnosing a metric drop; it is validating whether a new use case is worth building. Start by defining the user: travelers with limited time, airport employees, flight crews, or merchants inside terminals. Then identify the core pain point: long lines, gate changes, tight connection windows, limited food choice, or inability to leave a post-security area.

The constraints are very different from a city delivery case: security boundaries, terminal access, pickup handoff, merchant capacity, and flight-time urgency. A good PM would propose a narrow pilot, such as mobile ordering from airport restaurants for gate-area pickup in one terminal, instead of assuming full Dasher delivery inside secure zones. Success might be measured by order completion rate, average wait time saved, repeat usage, merchant throughput, and operational defect rate.

Common pitfalls

Pitfall: Jumping straight to features before defining the user and goal.

A tempting answer is, “I’d add subscriptions, promos, and better recommendations.” That sounds product-y but ignores the actual problem. A better answer first says who the product is for, what pain point matters most, and which metric will prove the solution worked.

Pitfall: Treating DoorDash like a one-sided consumer app.

Many candidates optimize only for consumers: lower fees, faster delivery, more discounts. DoorDash PMs must show marketplace judgment by asking what happens to merchants and Dashers. If a consumer feature reduces Dasher earnings or overwhelms merchant prep capacity, it may degrade the entire marketplace.

Pitfall: Overusing frameworks without making a decision.

Saying “I’ll use RICE” or “I’ll segment the funnel” is not enough. Interviewers want to see prioritization under uncertainty. After laying out options, choose the most likely driver or highest-leverage bet, explain why, and name the risk you would monitor.

Connections

Interviewers can pivot from ambiguity cases into metric design, root-cause diagnosis, marketplace strategy, experimentation, or launch planning. Be ready to move from a broad product idea into concrete success metrics, segmentation, and rollout criteria without drifting into implementation details outside the PM role.