Research Spike: Fast Reconnaissance Before Commitment
A research spike is a time-boxed scout mission to answer one blocking question before the team commits. Use it when requirements are fuzzy. The footgun is letting the spike balloon into a full research project instead of a sharp go or no-go call.
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.
Interview question
Which scenario best exemplifies a properly executed research spike?
- a.The team runs a six-week diary study to understand the why behind complex user mental models
- b.The team launches a large-scale survey to reach statistical significance on a proposed pricing change
- c.The team spends three days auditing competitors to produce a comprehensive strategy map before choosing a design direction
- d.The team spends two days interviewing six customers to decide whether to commit to a three-month buildCorrect
Why? this is the answer
A research spike is a sharply scoped, time-boxed scout mission that trades depth for speed, as shown by the two-day interviews aimed at a single go or no-go decision. The competitor audit is a tempting distractor because it fits the time box and uses a valid spike method, but it violates the core constraint by ballooning into a comprehensive strategy project rather than a fast directional call.
Just read this? Test yourself on what you have been reading.
- #ux research
- #agile
- #product discovery
- #research operations
- #spike
Put your scrolling time to good use
Learn one idea, try a quiz and save useful cards for revision. Tezvyn makes it easy to learn and stay current in your tech field, a few minutes at a time.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on ux research — each one lists the topics its interview covers.
See open roles