Desk Research

There was a time when any open question sent a team straight out to meet people. Curious about how teams organize their folders? Recruit participants and sit down with eight of them. Two weeks later the answer often turned out to be nearly identical to what was already sitting in last quarter's support inbox.

The cost was rarely the research itself. It was the calendar. Recruiting people who match the criteria eats a week on its own, and the date for deciding whether to build the feature keeps coming. When someone in a meeting said "didn't we look into this last year?", nobody knew where it had been written down, so the team started over.

Desk research exists to strip that waste off the front of the process. Finish what can be done at a desk first, and what comes out of it narrows the questions for everything that follows. Delete the questions that already have answers, ask people only what's left, and the same two weeks buy a much narrower and deeper conversation.

Write the question as one sentence, collect material, sort what's trustworthy from what isn't, and separate what got answered from what didn't. Five steps.

1. Write down what you want to know as a question that can actually be answered. "Understand the market" doesn't tell you what to open. "What per-seat monthly price do document collaboration tools cluster around for teams of five or more?" tells you immediately.
2. Decide where to look. Inside the company there are support tickets, usage logs, old research reports, and the loss reasons sales writes down. Outside there are industry reports, government statistics, competitors' published price pages and help docs, and app store reviews. Start inside — that material measured your own users, so it can be used as is.
3. Record the source and the date next to every number you keep. Someone will ask where a figure came from, and a figure you can't trace gets thrown out of the meeting whole.
4. Sort by how much each source can carry. Look at three things: who made it and why, when it was measured, and how many people it covers. A vendor's report showing that teams using its tool perform twice as well isn't evidence on its own. Find another source and see whether it points the same way.
5. Split answers from gaps. Sort the questions into three piles — answered by the material, contested because sources disagree, and impossible to answer from published material at all. The last two piles become the next study, and what goes into a customer interview or a survey is decided right here.

It fits questions someone else already answered, and questions your own records already contain. Market size, price bands, which features competitors shipped and when — most of that is public, which is why nearly all the raw material for competitive analysis comes from here. Internal records work the same way. Counting last quarter's 400 support tickets by reason takes a day; learning the same thing by recruiting users takes two weeks.

It also fits the sketching stage of a research plan. A proto-persona, drawn from assumptions before anyone has met a user, misses badly when the assumptions are thin. Lay industry material and support tickets underneath it and those assumptions get one notch firmer.

The limits come straight from where the material came from. Numbers someone else produced measured someone else's users. An industry study saying 60 percent of collaboration tool users open documents on mobile does not say that your users do. Timing bites too: a price band from a report two years old may already have shifted because of products that launched since.

Above all, material that doesn't exist can't answer anything. No report says which screen in your product people stall on. That comes from watching them in a usability test or asking in qualitative research. Desk research is where research starts, not the whole of it.

"Before we book interviews, give me two days of desk research."

Filter out the questions that already have answers so the interviews cover less ground and go deeper.

"That number came out of desk research, but the source is a vendor white paper, so we can't use it as is."

Whoever produced the material has a stake in the result, so it needs a second source.

"Desk research takes us this far. Why people set it up and then stop using it isn't in there."

Published material is exhausted and it's time to talk to actual users.

At Pagedeck, Mia runs this step before every quarterly plan. Deciding whether to rework team pricing was no exception — she spent two days on it before anyone called a user. She put six competitors' public price pages into one table, pulled six months of support tickets mentioning price and counted them by reason, and got the team-size distribution of accounts that converted from the free plan out of the logs.

What she brought to the meeting two days later was three answers and one question. The market's price bands, where the product sat inside them, and the most common pricing complaint were settled. What remained was why teams delay paying as they add seats, and that single question was what six users were asked.

The most common mistake is treating it as a light task — a few searches and you're done. The motions do look like searching. But the weight of the method sits in the sorting, not the finding. Out of ten documents on a topic, two are usually usable, and writing down why the other eight were dropped is part of the work. Skip that and whatever number appeared on the first page of results ends up in the spec, and six months later, when it turns out to be wrong, nobody can say where it came from.

The other mistake is assuming enough material means you can skip users entirely. A report dense with figures feels like knowing. But public material is material your competitors read too, so a decision built only on it tends to match theirs. Finish a decision on desk research alone and you ship the same feature half a year later than everyone else, while the place your own users were stuck stays exactly as it was.