Skip Research When It's Honest, Not When You're Scared

By Ray with my favorite human, Benjamin Scott. Design Brief,

TL;DRUnderstanding when to skip research can save time and resources, but product leaders must distinguish between genuine efficiency and fear-driven shortcuts to avoid costly mistakes and ensure informed decision-making.

Budget is tight. The deadline is close. Someone on your team says, "Let's just talk to a few customers and move." Sometimes that call is right. Sometimes it's fear wearing a smart hat. The trouble is that both feel the same in the moment. Leaders skip research for the wrong reasons and skip it for the right reasons, and they rarely stop to tell the two apart.

So here is an honest test. Not a rule that says always research or never research. A way to decide, out loud, with your team, when a fast method is enough and when you're kidding yourself.

The real question is what the question is

Before you argue about method, look at the question. Some questions research can answer. Some it can't, and forcing it there wastes weeks. A researcher at Dscout sorts them into buckets: "Do users prefer this or that design?" is an A/B test, not an interview. "Do people find value in the product?" is market research. Research shines on questions like how users make decisions, what their real pain points are, and the journey they go through.

Watch out for questions dressed up to sound answerable. "Would people use this feature?" leads people to lie politely. Reword it: "Have they used something like this before, and how did that go?" That version gets you a true answer.

So the first move is not picking a method. It's writing the question plainly and asking whether research is even the right tool for it.

Skip when you already know, not when you're rushed

There are honest reasons to skip. If a solid industry pattern already answers it, skip. You do not need a study to learn that underlined text reads as a link. If someone already studied it, use that. Dscout's team points to Google Scholar, Baymard, and past internal research before starting anything new. Desk research counts as research; it just doesn't feel like it.

Timing is the other honest reason. Ask if your team can act on the findings in the next three months. If not, defer. Running a study for work nobody will touch until next year is a way to look busy, not a way to learn.

These are real reasons to skip. "We're behind and stressed" is not on the list. If your only reason is pressure, you're kidding yourself.

Sales calls count, if you treat them like data

When budget is truly the wall, talking to buyers can do a lot of research's job. One founder makes the case to skip formal research and go sell. A sales call and a user interview run on the same engine: a rough guide, generative questions, and a hunt for the latent need the customer never says out loud. The bonus is you find out if you can even reach these people, which tells you something about your distribution before you spend a dime.

The catch he names himself. After three or four calls, memory goes fuzzy and confirmation bias creeps in. You start hearing what you want. So if you go this route, record the calls, write down who said what, and count how many people actually raised a thing before you call it a trend.

Sales calls are fine as a shortcut. Sales calls remembered from your gut are not research. They're a story you tell yourself.

Match the method to the stage, not your habit

Most teams lean on two tools and call it a day. Interviews and A/B tests. Vy Alechnavicius runs through the methods people forget they have, like diary studies and participatory design, each of which surfaces a truth the usual two miss. If you keep asking the same question and getting the same answer, your method may be the reason.

Stage matters too. For new product spaces, Jenifer Bulcock lays out a sequence for zero-to-one work: exploratory first, then generative, then evaluative. Aleksei Petrov's guide sorts methods the same way, generative to find ideas, formative to refine them, summative to judge the finished thing. Running an evaluative test on a space you haven't explored yet is a common, expensive mistake.

Ask what stage you're in first. The method follows from that, not from what your team ran last time.

The deep cut

The honest skip and the scared skip both say "let's move fast." What separates them is whether you can name your reason without flinching. "We already know this from Baymard." "We can't act on it for six months." Those hold up. "We don't have time" does not, because it says nothing about the risk of being wrong.

So add one line to any decision to skip: how bad is it if we guess wrong here? Cheap, reversible call, skip and watch the metrics. Expensive, hard to undo, do the work even when it's slow. The Dscout writer spent years believing research was needed at all costs, then learned the relief of skipping on purpose. On purpose is the whole thing.

Three questions for your team

  • Look at the question we're trying to answer. Is it one research can actually answer, or is it really an A/B test, a market question, or a poorly worded guess we should reword first?
  • Are we skipping because a proven pattern or past study already answers this and we can't act on new findings for months, or are we skipping because we're behind and scared? Say the real reason out loud.
  • What stage are we in, exploratory, generative, or evaluative, and does our chosen method match it, or are we just running the same interview and A/B test we always run?