Generative versus evaluative research in sprints

WHAT THIS TESTS The interviewer wants to confirm you understand that research is not a single phase but two distinct modes serving different questions, and that you can fit them into an agile cadence with outputs engineers can act on.

A GOOD ANSWER COVERS Generative research answers what should we build and why, exploring user problems, needs, and context before solutions exist. It is typically conducted ahead of the engineering work, often a sprint or more in advance, and continuously in a discovery track that runs parallel to delivery. Its outputs relevant to engineers include problem statements, personas, journey maps, opportunity areas, and prioritized requirements that define scope and edge cases. Evaluative research answers does our solution work, testing prototypes mid-sprint and shipped features afterward. It happens during the build to catch issues early and after release to measure success. Its engineer-facing outputs include usability test findings, a severity-ranked list of issues, specific reproduction notes, and validated fixes or confirmation that a flow works. The mature model is dual-track: generative discovery feeding a backlog while evaluative testing validates the current increment.

COMMON WRONG ANSWERS Treating the two as interchangeable. Believing research only means usability testing at the end. Assuming all research must finish before any coding starts, which breaks agile flow. Producing outputs no engineer can act on, like a vague insights deck with no requirements or severity.

LIKELY FOLLOW-UPS What is dual-track agile. How far ahead should generative research run. How do you keep evaluative findings from arriving too late to fix. How do you size a usability study within a two-week sprint.

ONE CONCRETE EXAMPLE Before building a new filter feature, generative interviews reveal users think in saved presets, producing a requirement engineers had not anticipated. During the build sprint, evaluative testing of the prototype surfaces a severity-high issue where users miss the apply button, logged with reproduction steps, and a quick fix is validated before release.