Advocate for generative research over a complex feature request?

WHAT THIS TESTS: This question tests your ability to match research methods to the phase of product development and to translate user research into engineering risk language. The interviewer wants to see that you understand the NN/g three-dimensional framework, specifically that generative discovery belongs in the qualitative and behavioral dimensions with natural context. They also want evidence that you can advocate for research without being perceived as slowing down delivery, by framing it as a scope de-risking exercise rather than a purely academic exercise.

A GOOD ANSWER COVERS: First, reframe the single customer request from an attitudinal data point to a signal that requires behavioral validation, because what people say and what people do are often different. Second, name specific generative methods positioned correctly in the framework, such as field studies, emphasizing that these capture qualitative behavioral data in the natural context of product use rather than relying on self-reported information alone. Third, identify technical unknowns that generative research can resolve before engineering commits to architecture, including the real integration surface area with existing systems, whether the problem is frequent enough to justify a heavy solution, what data models and migration paths are actually needed, and whether a lighter workflow fix eliminates the need for new infrastructure. Fourth, propose a concrete decision gate, such as a problem-statement brief, that lets the team define build versus no-build criteria before writing production code.

COMMON WRONG ANSWERS: Proposing usability testing, A/B testing, or surveys to discover unknown needs is a method mismatch because these tools evaluate known solutions or gather indirect measurements rather than reveal unmet problems through direct observation. Another red flag is advocating for research without connecting it to release risk, such as failing to mention opportunity cost or irreversible architectural decisions. A third error is sounding dismissive of the customer request instead of treating it as a valuable but unvalidated signal that needs triangulation with other users.

LIKELY FOLLOW-UPS: The interviewer may ask how you would handle a product lead who still refuses the research, in which case you should describe a time-boxed lean experiment or a small field study sprint that runs in parallel with technical spikes. They may also ask how you would synthesize generative findings for an engineering audience, so be ready to explain how you translate observed behaviors into system boundaries and edge cases.

ONE CONCRETE EXAMPLE: Imagine a single enterprise customer asks for a real-time collaborative editing feature. Rather than immediately designing operational transform logic, you propose field studies observing how five other teams currently share and edit documents in their natural workflow. The research reveals that the real pain point is version confusion during handoffs, not simultaneous editing, and that teams solve this today with scheduled sync meetings. This behavioral finding answers critical technical unknowns, including whether you need sub-hundred-millisecond latency, how to handle conflict resolution, and whether the required WebSocket infrastructure is justified. The team opts for a lightweight comment-and-approval workflow instead, saving an estimated four months of engineering time.

Source: nngroup.com