Research Spike: Fast Reconnaissance Before Commitment

WHY IT EXISTS: Product teams constantly face uncertainty about user behavior, technical constraints, or business rules. Building the wrong feature wastes design cycles, engineering sprints, and opportunity cost. A research spike exists to buy information cheaply and quickly so the team can decide whether to invest, pivot, or kill an idea before committing to a full solution.

THE MENTAL MODEL: Think of it as sending a scout ahead of the main army. The scout does not fight the battle; they verify the path, spot obstacles, and return fast so the commander can choose the route. A research spike is exactly that reconnaissance loop applied to product discovery. It trades depth for speed and certainty for calendar time.

HOW IT WORKS: A spike starts with a single, sharply scoped question such as do users understand this pricing model or can they complete this workflow on mobile. The researcher picks the fastest method that can answer it, which might be five user interviews, a heuristic evaluation, a competitive audit, or a quick card sort. A hard time box is set, often between a few hours and three days. The output is not a polished report but a brief decision document stating the answer, the evidence, and the recommended next step.

WHEN TO USE IT: Use a spike when the team is blocked by an unknown and cannot move forward without a directional signal. Common triggers include conflicting assumptions about user needs, a new target segment with no existing data, or a design proposal that carries high implementation cost. It is also useful when a stakeholder is pushing a feature and the team needs fast evidence to validate or challenge the bet.

WHEN NOT TO USE IT: Do not use a spike when the question requires statistical significance, longitudinal behavior tracking, or deep generative insight. If you need to understand the why behind complex mental models, run a proper ethnographic or diary study instead. Also avoid spikes when the decision is already made; using research to rubber-stamp a preselected path is theater, not discovery.

ONE CANONICAL EXAMPLE: A SaaS team wants to add an AI writing assistant to its docs product. Engineering estimates three months of model integration work. Instead of committing, the designer runs a two-day spike with six existing customers, showing them a low-fidelity prototype hooked to a manual backend. Four participants find it useful but all six say they would not trust AI-generated text without inline citations. The team pivots to a citation-first design and avoids building the wrong thing.