Design a one-week lean research plan for a high-risk decision

WHAT THIS TESTS: The interviewer wants to see if you can operate as a research strategist when resources are scarce. Senior product leaders must know how to reduce uncertainty quickly without defaulting to either analysis paralysis or gut-driven leaps. The core skill is assumption prioritization paired with method selection that fits a five-day calendar and a cross-functional team of non-researchers.

A GOOD ANSWER COVERS: First, isolate the decision and its riskiest assumption. If the decision is to build a new onboarding flow, the riskiest assumption might be that users actually want the promised outcome enough to tolerate friction. Second, map methods to days. Monday is generative: run three to five structured customer conversations or intercept interviews to understand mental models. Tuesday is synthesis and concepting: the team extracts patterns and sketches solutions using a design studio format. Wednesday is prototyping: build a clickable mockup or concierge test, not polished code. Thursday is recruitment and piloting: use personal networks, customer lists, or social channels to find five to eight participants who match the target behavior, not demographics alone. Friday is validation: conduct thirty-minute moderated usability or value tests, observing live and taking notes in a shared board. Third, justify compromises. Small samples are acceptable for directional signal on high-risk assumptions because the cost of being wrong exceeds the cost of a false positive. Bias from convenience sampling is acknowledged and bounded by focusing on extreme users or early adopters. Fourth, define the kill criteria before Friday so the team knows what evidence would reverse the decision.

COMMON WRONG ANSWERS: Proposing a six-week double-diamond process ignores the constraint. Suggesting an unmoderated survey with five hundred respondents trades volume for depth and cannot explain why behavior occurs. Saying you will just A/B test in production skips the generative phase and burns engineering time on unvalidated concepts. Claiming you need a dedicated researcher to talk to users signals that you cannot lead discovery yourself.

LIKELY FOLLOW-UPS: How would you handle a null result on Friday? What if leadership rejects the small sample size? How do you scale this if the decision affects a regulated or safety-critical domain? Would you still run the sprint if the risk is existential to the company?

ONE CONCRETE EXAMPLE: A B2B SaaS team must decide whether to add an AI assistant. The riskiest assumption is that busy managers will trust an AI with scheduling. Monday: interview five managers who currently delegate scheduling to humans. Tuesday: map trust triggers and sketch three interaction models. Wednesday: build a Wizard-of-Oz prototype where a human plays the AI behind a Slack bot. Thursday: recruit eight managers via LinkedIn with a fifty-dollar gift card. Friday: run fifteen-minute tasks; if fewer than five of eight delegate without requesting human confirmation, the team kills the feature and pivots to a transparency-first design.