DoorDash Grocery: Reduce Missing-Item Complaints, Then Test and Measure the Fix

DoorDash has just launched a grocery delivery service at a time when a worldwide supply chain disruption is leaving store shelves unpredictable. Customers are filing many complaints that items they ordered never arrived. The app currently gives customers no way to choose or accept substitutions. The one tool that already exists is an in-app chat connecting the shopper who picks the order in the store with the customer who placed it. You are the product manager. Explain how you would address the missing-item problem through the product, how you would test your solution, and how you would decide whether it worked. ### Clarifying Questions - Do the complaints come mostly from items that were genuinely out of stock at the store, or also from items the shopper could not find, skipped, or left out of the bag? - What happens to the customer's charge for a missing item today: is it refunded automatically, only after a complaint, or not at all? - Does the app receive any live inventory signal from partner stores, or only a static catalog? - Is the team's priority cutting complaint volume, keeping first-time grocery customers coming back, or protecting order value? ### Part 1 — Design the product fix Propose product changes that reduce the harm customers experience from missing items, given that the underlying shortages are outside the company's control. Choose who you are designing for, name their pain points, and decide what ships first. ```hint Separate the causes An item can go missing for different reasons, and each stage of the order (building the cart, shopping in the store, delivery) offers a different lever. ``` #### What This Part Should Cover - A clear goal and the user or users chosen across customers and shoppers, with a reason - Pain points tied to where in the order flow an item goes missing - Concrete features that build on the existing shopper-to-customer chat - A prioritized first release with the reasoning for its scope ### Part 2 — Test the solution Describe how you would validate the solution before and during rollout. ```hint Think about who the change touches The feature changes both the customer app and the shopper's workflow, and each shopper handles orders for many different customers. ``` #### What This Part Should Cover - A falsifiable hypothesis and the stages of testing, from pilot to controlled experiment - The randomization unit and how shopper-side spillover could bias results - Duration and sample considerations given weekly grocery shopping cycles - Launch criteria that combine the success metric with guardrails ### Part 3 — Measure success Define the metrics that would tell you whether the solution worked. ```hint Define a good order Decide what a "complete" grocery order means once substitutions exist, and how an unwanted substitute should count. ``` #### What This Part Should Cover - One primary success metric that captures orders arriving as the customer intended - Supporting metrics for the substitution flow itself - Guardrails on shopper time, delivery speed, and cost - How long-term grocery retention would be read ### What a Strong Answer Covers - Accepts that the product cannot end the shortages and focuses on reducing their impact on customers - Treats the shopper as a second user whose time and earnings the solution must respect - Handles substitution risks such as dietary restrictions, allergens, and price differences - Connects the feature, the experiment design, and the metrics into one consistent story - Prioritizes a focused first release instead of listing every possible feature ### Follow-up Questions - The customer does not respond in chat while the shopper is waiting at the shelf. What should happen, and who decides the default? - If a substitute costs more than the original item, who pays the difference, and how would you decide? - Your experiment shows complaints falling but shopping time per order rising sharply. Do you launch?