How to Turn a Vague Topic Into a Research Question Worth Answering

Most research requests start the same way: "I need something on [broad topic]." Supply chain blockchain. Remote work productivity. The history of a regulation. That's a subject, not a question — and the difference matters more than people think, whether you're briefing a human analyst, an AI tool, or yourself at 11pm before a deadline.

A subject tells a writer where to look. A question tells them where to stop. Without a real question, you get a summary of everything moderately related to the topic, organized by whatever structure felt natural to write — history, then current state, then "future outlook." It reads fine. It usually doesn't help you do anything, because you didn't actually need an overview; you needed an answer to something specific that triggered the request in the first place.

Here's a practical process for narrowing a vague topic into a question that produces a brief you can actually act on.

Start with the decision, not the subject

Before you write down a topic, write down the decision it needs to inform. Not "I want to understand remote work productivity research" but "I'm deciding whether to recommend my company keep its current hybrid policy or go full-remote, and I need to know what the actual evidence says about output, not just satisfaction surveys."

That second version already contains a question: does the research distinguish between self-reported satisfaction and measured output? If you can't name the decision, you're not ready to commission a brief yet — you're still exploring, which is a different (and fine) activity, but it calls for a different kind of request: "give me a map of what's out there," not "answer this for me."

A quick test: if someone handed you the finished brief tomorrow, what would you do differently depending on what it said? If the honest answer is "nothing, I'd just know more," that's still a legitimate use of a research brief, but say so explicitly in the request so the writer doesn't waste space building toward a recommendation nobody asked for.

Name the reader, even if it's just you

A brief written for a technical cofounder and a brief written for a non-technical board member look different even if the underlying facts are identical. The technical reader wants precision and is comfortable with unresolved uncertainty flagged honestly. The board member wants the uncertainty translated into "here's what we're confident about and here's what we're not," with technical terms defined inline rather than assumed.

If you're the only reader, say that too — it changes the brief. You can skip background you already know and go straight to the parts you're less sure about. A huge amount of wasted word count in generic research output is spent re-explaining things the requester already understood, because the request didn't say who was reading it.

Split "what's true" from "what should I do"

This is the single most common source of disappointing research output. A good brief should keep facts and interpretation clearly separated: here's what's established, here's what's genuinely contested or uncertain, and here — clearly marked as a separate layer — is analysis or framing to help you think about it. What it should not do is quietly blend "here's what three studies found" with "and therefore you should," because that's a recommendation wearing a research costume, and it hides the actual evidence quality behind confident-sounding prose.

If you want framing or analysis, ask for it explicitly, and ask for the uncertainty to stay visible rather than smoothed over. If you just want the facts as currently understood, say that too, so the writer doesn't pad the brief with speculative implications you didn't request.

Give sub-questions, not just a scope

"Cover the history, current state, and future of X" is a scope, and scopes produce surveys. Sub-questions produce answers. Compare:

• Scope: "the history of remote-work productivity research"
• Sub-questions: "What did pre-2020 studies find about remote work and output, and how (if at all) does that evidence differ from what's been measured since 2020? What are the two or three biggest methodological problems with measuring 'productivity' in this research, and how much should that limit how confident we are in any of it?"

The second version is longer to write, but it's five minutes of your time against potentially hours of reading an unfocused summary later. It also tells the writer exactly where to spend the word budget — on the comparison and the methodology problem, not on padding with a generic history nobody asked to have repeated.

Decide what "done" looks like before you ask

A useful trick: write one sentence describing what the last paragraph of the brief should let you say to someone else. "I can tell my manager whether the evidence supports our hybrid policy or not, and what the strongest counterargument is." "I can explain to a non-technical cofounder what this protocol's governance model actually controls, in plain language." If you can write that sentence, you have a real brief request. If you can't, spend five more minutes narrowing before you send it anywhere.

A short template

If you want a repeatable format, this covers most cases:

1. Decision or use: what this needs to help you do, or say explicitly it's for general understanding.
2. Reader: who's reading it and what they already know.
3. Sub-questions: 2-4 specific questions, not just a topic scope.
4. Facts vs. framing: say whether you want interpretation/analysis included or facts only.
5. Done looks like: one sentence describing what you should be able to say or decide afterward.

None of this requires special tools or expertise — it's five minutes of thinking before you ask, and it's the same five minutes whether the brief comes from a colleague, a freelancer, or an AI service. The quality ceiling of any research output is set less by the writer's skill and more by how precisely the question was framed going in.

If you'd rather skip straight to the output, Lucid Desk's Custom Research Brief turns a well-framed question like the ones above into an 800-1200 word brief with organized sections and a key-takeaways list, usually delivered within minutes of payment — and the sharper the question you give it, the more useful the brief will be.