Research you can run in a week

The phrase "we should do research" tends to summon an image nobody has time for: recruitment, screeners, a moderated study, a deck. So the decision gets made from opinion instead, and the opinion of whoever is most senior usually wins. The alternative is not a smaller version of that study. It is a different shape of work entirely.

Start from the decision, not the topic

Write the decision you are about to make and the two options you are choosing between. If you cannot, you are not ready to research — you are ready to think. A decision-shaped question ("do we split this flow in two or keep it on one screen?") can be answered in days. A topic-shaped question ("how do users feel about our onboarding?") absorbs any amount of time you give it and ends in a document nobody acts on.

Write next to it what you would do differently under each answer. If the answer changes nothing, you have found a question not worth researching, which is itself a useful result — and a common one.

Day one: spend it in data you already own

Before scheduling anyone, spend an afternoon in the things nobody reads. This is the cheapest research in the building and it usually reframes the question you were about to ask.

• Support tickets from the last 90 days, ranked by volume, then read the long tail for language.
• In-product search queries — the most honest statement of intent your product collects.
• Fields people leave blank, and forms they abandon mid-way.
• What people export, and how often. Exports reveal the job the product is not doing.
• Sales call recordings, specifically the objections that recur in the same words.

Keep a running list of phrases customers use for things you have named differently. That vocabulary gap explains a surprising share of "usability" problems, and fixing labels is cheaper than fixing flows.

Days two to four: five conversations, same script

Five is enough to hear a pattern for most interface decisions. The value comes from asking all five the same questions in the same order, so the differences are about them and not about your interviewing. Ask what they did last time rather than what they would do next time; recalled behaviour is imperfect but speculation is worthless.

1. 01Ask them to walk you through the last time they did the thing, in order, out loud.
2. 02Ask what happened immediately before and after — that is where the workarounds live.
3. 03Ask what they did when it went wrong, and whether that was typical.
4. 04Only then show anything you have made, and watch rather than explain.

Recruit from support tickets and recent signups before touching a research panel. People who contacted you last week are motivated, contextually relevant, and free. Stop the session when you have heard the same objection three times — you have your answer.

The mistake that wastes the week

Demoing. The moment you explain your intended solution, you convert a research conversation into a sales conversation, and the participant switches into being polite. Show late, say little, and let the silence do the work.

Day five: write the answer, not the findings

The output is one page: the decision, the answer, the three pieces of evidence that most support it, and the strongest evidence against. That last section is what makes the document trustworthy six months later, and it is the section that survives the next disagreement.

The goal is not certainty. It is to stop the most expensive wrong assumption before it reaches code.

A week of this beats a month of debate, and it leaves the team with something better than a verdict: a shared picture of who they are building for, in the customer's own words.