How to structure a product improvement answer in PM interviews
Work through a grocery-delivery case: clarify the problem, compare improvements, test the choice and respond to new evidence.
PMMockr.comA product improvement answer starts with a decision
Clarify the product goal, choose a user situation, identify the problem and compare ways to address it. Explain what the evidence supports, what you assume and what would change your recommendation. A named framework can organize the answer, but it cannot establish that users have a problem or that a feature will solve it.
The grocery-delivery case below is an original AI-assisted teaching example published by PMMockr. The product, research findings and proposed release are hypothetical. It is not a verified employer question, customer study or account of a shipped feature. No survey percentages, measured results or fixed experiment sample sizes are claimed.
The case: improve a grocery delivery app
Illustrative prompt: how would you improve a grocery delivery app for customers who need to be home to receive their order?
Assume the product already shows a delivery window and order status. The company wants dependable order receipt while keeping delivery costs sustainable. Ask whether the main problem is a missed delivery promise, uncertainty about an otherwise accurate window, or something else. Ask about existing customer controls and dispatch constraints before proposing live tracking as a new feature.
For this walkthrough, suppose we are investigating customers coordinating receipt around other commitments. That situation defines the segment; it is not a claim that a demographic group behaves uniformly. Other possible needs include accessible handoff, substitutions and managing the grocery budget. We focus on receipt coordination because it is the decision in this case, not because invented research proved it is the largest problem.
Distinguish a late delivery from uncertainty about delivery
Request evidence that can separate the causes: promised and actual arrival times, failed handoffs, permissioned customer interviews and timing-related support reasons. Review what the customer saw when deciding to be home. Support contacts alone may miss people who abandoned the service or could not reach support.
A late delivery requires attention to the service promise or operations. A delivery arriving inside an accurate window can still be difficult to coordinate. An unclear status message can create unnecessary uncertainty. These are different problems, so an answer that immediately adds a map may solve none of them.
State the working hypothesis: under the assumption that arrival estimates are reasonably dependable but the current status is unclear, better preparation and notification could help. If that assumption fails, the recommendation must change.
Compare three options before recommending a feature
Option A clarifies the existing arrival window and offers an optional arrival notification. It may reduce uncertainty with limited interface complexity, but depends on a reliable estimate and reachable notification channel.
Option B adds live driver location. It may provide detail, but can expose unnecessary location information and encourage customers to treat a moving dot as a delivery guarantee. Consider what genuinely useful information it adds beyond an accurate arrival estimate.
Option C changes scheduling or dispatch so the delivery promise becomes more dependable. It may address actual lateness, but can affect route efficiency, capacity and cost. A tighter paid slot is not a dependable promise merely because the customer paid for it.
Under the stated communication hypothesis, I would first test clearer status and an optional notification. Keep the existing receipt controls available and explain estimate uncertainty. If operations cannot provide useful estimates, prioritize the promise and dispatch investigation rather than polish inaccurate communication.
Give a concise possible interview answer
“I would focus on customers who must coordinate being home for a delivery. I first want to distinguish actual lateness from uncertainty about an accurate window. Assuming the estimate is dependable and customers find the status unclear, I would compare clearer status and optional notifications, live location, and tighter scheduling.
I would start with clearer status and a notification because it targets coordination without requiring a detailed driver map or an unproven tighter delivery promise. The estimate needs to communicate uncertainty, and customers need a fallback if notification delivery fails. I would check successful receipt and timing-related burden while monitoring lateness, failed handoffs, support load and delivery cost.
Before expansion, I would compare against the current experience using an appropriate assignment unit and an agreed observation window. If actual late arrivals explain the problem, I would change the recommendation to operational diagnosis. More status views alone would not convince me that receipt improved.”
This is one defensible answer under explicit assumptions. The recommendation changes when the evidence changes.
Choose validation that matches the uncertainty
First test whether customers understand the current and proposed status messages through consented research or a prototype. That can establish a comprehension problem; it cannot prove that a production release improves receipt rates. Separately evaluate whether the estimate and notification delivery are dependable.
If an online experiment is appropriate, define eligible orders, the comparison experience, assignment unit and success criteria before looking at results. Account for repeat customers and shared dispatch operations. Customer-level assignment may avoid showing inconsistent experiences to a repeat customer; an operational change may require a different design because orders share capacity. Discuss that choice with the responsible analyst and operations team.
Define successful receipt over all eligible orders in the observation window. Keep canceled orders, missing completion information and failed notifications visible rather than silently excluding them. Monitor late arrival, failed handoff, accessibility, support burden and cost alongside the primary outcome.
Choose the sample and duration from the baseline, minimum useful effect, outcome variability, assignment design and relevant operating cycles. A round number such as a fixed user count is not a sample-size justification. An inconclusive test is not evidence that the problem does not exist.
Follow-up: dispatch data now shows unreliable arrival estimates
Interviewer follow-up: the proposed notification frequently arrives before a route is reassigned, so the displayed arrival estimate becomes misleading. What changes?
I would pause expansion of that notification behavior, investigate estimate stability with operations and engineering, and show a more honest window where precise estimates are unsupported. Compare improving the prediction, notifying later with a reliable signal, and offering better rescheduling or handoff controls. Keep customers informed about uncertainty.
The goal remains dependable receipt. Faster notifications or more map visits do not substitute for it. Explain who owns the next check and what result would let the team safely revisit the communication proposal.
Weak answer, stronger answer and self-review
Weak answer: “Add real-time tracking because busy customers want it, then launch to a large sample.” This assumes a need, chooses a feature before finding a cause and names a sample without a measurement plan.
Stronger answer: “I would distinguish unreliable delivery from unclear communication. Under the communication hypothesis, compare status and optional notification with a map and operational changes. Test comprehension first, then evaluate successful receipt with the relevant guardrails. Change the recommendation if lateness is the actual driver.”
- Did I distinguish observed evidence from the assumptions in the case?
- Did I name a user situation and compare plausible alternatives?
- Does my metric describe the user outcome rather than feature activity?
- Did I define eligibility, missing outcomes and the main guardrails?
- Can I explain the next check and what would reverse my decision?
Try the reasoning on another product
Practice prompt: improve a video meeting tool for teachers who need students to rejoin after a connection interruption. State what the product already supports, distinguish connection failure from difficulty rejoining, compare alternatives and explain a first validation step. Do not invent interviews or measured completion rates.
After your first answer, add a constraint: some students cannot receive push notifications. Revise the recommendation and explain which part of the success definition stays the same. Use the public product-design question collection for another prompt, then review the reasoning before choosing a timed case.
FAQ
What if I do not have customer research for a product improvement answer?
State the uncertainty, name a working hypothesis and explain how you would check it. Do not present an invented survey result or a demographic stereotype as evidence. Make the recommendation conditional on the facts that matter.
Should every product improvement be tested with an A/B experiment?
No. Choose validation for the uncertainty: research for understanding a need, prototype work for comprehension and usability, engineering checks for feasibility, and a suitable controlled evaluation for causal outcome claims. Some harmful changes should not be exposed to users for the sake of an experiment.
How many users should I include in an experiment?
There is no universal user count. Define the baseline, minimum useful effect, outcome variability, assignment unit and operating cycles, then plan the sample and duration with the responsible analyst. Explain the required inputs rather than inventing a fixed sample.