What research validates a three-sprint feature without delaying engineering?

What's really being asked

The interviewer wants to know if you can balance rigor with speed. They are looking for familiarity with Lean UX principles, specifically how to run research in parallel with engineering rather than in a separate waterfall phase. The core skill is de-risking a large investment by validating problem-solution fit before three sprints of code are written, without adding calendar delay.

The full answer

First, time-box a one-week problem-validation sprint that includes five to eight targeted user interviews and a lightweight fake-door or landing-page test to gauge demand. Second, schedule a solution-concept test in week two using a low-fidelity prototype or storyboard to validate usability and value, running this concurrently with engineering spikes that explore technical feasibility and architecture. Third, define clear kill criteria before the research starts, such as fewer than forty percent of interviewees ranking the problem as a top-three pain point, or prototype task-success rates below sixty percent. Fourth, synthesize findings into a one-page decision memo with go, no-go, or pivot recommendations before sprint planning so the engineering timeline is either confirmed or redirected without wasted capacity.

The mistakes people make

A red flag is proposing a full discovery phase with ethnographic field studies, journey mapping, and extensive surveys that pushes engineering start by two to four weeks. Another mistake is suggesting research only after an MVP is built, which defeats the purpose of de-risking the three-sprint estimate. Candidates also err by omitting kill criteria, making the research feel like a box-checking exercise rather than a decision-making tool.

What usually comes next

The interviewer may ask how you would handle stakeholders who insist on the full feature regardless of negative research findings. They might also probe how you would adapt this approach if user access is limited, or how you would measure confidence levels with a sample size of only five to eight users.

A concrete example

Imagine a B2B SaaS team wants to add an advanced analytics dashboard estimated at three sprints. In week one, you interview six power users and run a fake-door email campaign to the broader user base; the campaign gets a two-percent click-through rate and interviews reveal the problem is real but not urgent. In week two, you test a clickable prototype focused on the top three requested metrics while engineering spikes on data-pipeline latency. The prototype shows users cannot interpret the visualizations without training. You recommend pivoting to a simplified auto-generated report for one sprint, killing the full dashboard and saving an estimated sixty percent of the original engineering capacity.