Speed Without Research is a Liability, Not An Advantage

The useful part

If you ask for more time to research, you risk being seen as the person slowing the launch down. If you skip the research to hit the deadline and something goes wrong after launch, everyone asks why the team didn't catch it earlier. When deadlines get tight, research is often the first thing teams cut because cutting it appears to save time.

How it works

• For example, a team that does very little research can move straight into design and development.
• If the first team ships the wrong feature, creates a workflow users avoid, or launches something that damages trust, the work continues after launch.
• Now the team has to redesign, rebuild, retrain users, handle more support issues, or convince customers to try the product again.
• You move faster at the beginning by accepting a higher chance that you will have to redo the work later.
• Too much research can slow a team down just as easily when the question is small, the decision is reversible, or the evidence will not change what the team does.

What to take from it

A team that stops to test an important assumption, if they discover a problem, they may delay the build until it knows what to change.

Example or evidence

• That is why skipping UX research can create the illusion of speed.
• The goal is to know which decisions need research, how much ev...

Details worth keeping

If you only compare release dates, the first team looks faster. The few weeks saved before launch can turn into months of work afterward.