Improve a DoorDash Feature, Pick Its Success KPI, and Respond When It Stays Flat

You are a product manager at DoorDash. The interviewer wants you to pick one feature to improve, say how you would judge whether the improvement worked, and then respond to a disappointing result. Work through the three parts in order. ### Clarifying Questions - Can the feature serve any side of the marketplace (customers placing orders, Dashers delivering them, or merchants), or should it be customer-facing? - Is there a company goal the improvement should support, such as how often customers order, growth beyond restaurant delivery, or profitability? - Should the KPI be a single number the team owns, or a primary metric backed by supporting metrics? ### Part 1 — Choose the feature and the improvement Choose one existing DoorDash feature, explain why it is worth improving now and for whom, and describe the change you would make. ```hint Start from where orders go wrong Look for a step in the DoorDash experience where orders fail, stall or disappoint, so that the change you propose leads to a behavior you can measure later. ``` #### What This Part Should Cover - A reason for choosing this feature, tied to a goal and a defined user segment. - The specific problem and how you know it is real and sizable. - A concrete change, with at least one alternative considered. ### Part 2 — Define the success KPI Name the KPI that will decide whether the improvement succeeded, define it precisely, and explain how you would measure the effect. ```hint Make it move if the change works Prefer a metric that the change can shift within a few weeks and that is hard to inflate, then link it to the business outcome it should eventually drive. ``` #### What This Part Should Cover - One primary KPI with an exact definition and a reason it reflects this change. - Supporting input metrics and guardrails for customers, Dashers and merchants. - How the effect will be measured: comparison group, expected size and duration. ### Part 3 — The KPI is flat three months later Three months after the change shipped, the KPI has not moved. Explain what you would investigate and how you would decide what to do next. ```hint Question the comparison first Before judging the idea, check what "flat" is measured against, and whether the people who actually encountered the change behaved differently from those who did not. ``` #### Clarifying Questions for this Part - Was the change tested against a randomized holdout, or is the team comparing the KPI before and after launch? - Is the KPI flat in every market and segment, or only in aggregate? #### What This Part Should Cover - Checks that the rollout and the measurement are sound before judging the feature. - Separating "people did not use it", "people used it but nothing changed" and "it worked but something else offset it", using the right comparison. - A decision (iterate, retarget, expand or roll back) with clear criteria, without redefining the KPI after the fact to claim success. ### What a Strong Answer Covers - A consistent thread from the chosen problem to the KPI to the diagnosis, so the KPI measures what the change actually affects. - Awareness that DoorDash serves customers, Dashers and merchants at once, and that a gain for one side can cost another. - Sound experimental reasoning: a counterfactual comparison, statistical power, dilution across orders the change cannot affect, and time for lagging outcomes. - A clear recommendation at each stage, including when to stop investing. ### Follow-up Questions - Your analysis shows the KPI improved in some cities and fell in others. What do you do with that? - Leadership wants to keep the change because customers say in surveys that they like it, even though the KPI is flat. How do you respond? - Knowing how this turned out, how would you have chosen the KPI and the test duration up front?