Write a market research brief an offshore analyst can execute
How to turn a fuzzy research request into a scoped brief with a decision, a population, a source standard, and a usable deliverable.
Start with the decision the research must support
A research brief should name the decision it will inform before it lists any questions. The decision might be whether to enter a segment, how to position a launch, or which objections deserve a new enablement asset. Write the decision in one sentence and name the person who will make it. Without that anchor, the analyst can collect interesting material that never changes a choice.
Ask the requester what would count as a useful answer, including the evidence that would make them change course. Separate a fact-finding request from a validation request, because they need different sources and different levels of proof. Record the deadline and the meeting where the answer will be used. A brief with no decision and no date is a reading assignment, not a research project.
Define the population and the evidence bar
State the population in concrete terms, such as mid-market finance leaders at companies with fifty to five hundred employees. Include the geography, industry, company size, and role that matter to the decision. Name the sources that are acceptable and the ones that are out of scope. This prevents the analyst from substituting a convenient sample for the audience the team actually needs to understand.
Set the evidence bar before collection starts. Say whether a claim needs a primary document, two independent sources, or an interview with a named buyer role. Distinguish a published fact from an inference and require the analyst to label each one. A clear bar makes the review faster because the team knows what a finished note must contain.
Give the analyst a source log format
Require one row per source with the title, publisher, publication date, URL, and the exact claim it supports. Add a short note about the source type, such as regulator, vendor, trade publication, or interview. Keep the original language next to any summary so a reviewer can check the interpretation. A source log turns a pile of links into an auditable record.
Ask the analyst to mark missing evidence explicitly instead of filling gaps with plausible language. If a source is paywalled or unavailable, record that limitation and the date it was checked. When two sources disagree, keep both entries and explain the conflict. The log should make the uncertainty visible to the person making the decision.
Set the deliverable structure
Define the sections of the final note and the order in which they should appear. A useful structure starts with the decision, then the strongest findings, then the evidence, then the limits, and finally the recommended next step. Put the most decision-relevant finding in the first paragraph so a busy reader can act without reading every page. Finish the note with the decision the requester needs to make and the date by which they need it.
Cap the length and require a one-page summary with linked evidence. Tables work well for comparing competitors, segments, or buyer objections, but each table needs a stated purpose and a source note. Ask for a short list of open questions at the end. The deliverable should show what is known, what is not known, and what the team should do next.
Build a review step before synthesis
Review the source log before the analyst writes the final narrative. Check that each key claim has a source, that the source is current enough for the decision, and that the population matches the brief. Correct scope errors at this stage, because a polished report built on the wrong sample wastes more time than a rough note with the right evidence. The reviewer should sign the checklist before the analyst begins the synthesis so the evidence base is fixed.
Use a short review checklist with three questions: does the evidence answer the decision, is the interpretation separate from the fact, and are the limits stated plainly. Send corrections back with a specific instruction rather than a general request to improve the draft. The reviewer should approve the evidence base before anyone presents the conclusions. Record the reviewer and the date beside the checklist so the team can see who approved the evidence base.
Close the brief with a decision log
Record the decision that was made, the evidence used, and the assumptions that remained. Note who approved the decision and when it should be revisited. Link the final research note and any supporting files in one place. This turns a one-off project into a record the team can use the next time a similar question appears.
Review the brief after the decision to see which parts were useful and which were ignored. Ask the requester whether the scope was right and whether the evidence bar was too high or too low. Update the brief template with the lesson, not with more boilerplate. A research process improves when each completed project leaves a clearer starting point for the next one.
Keep the question set small and sequenced
Limit the brief to the questions that must be answered before the decision. Put the primary question first and the supporting questions underneath it. A long list of secondary questions encourages the analyst to spread effort evenly and miss the main point. Mark any question that can wait for a later phase. Put a time estimate beside each question so the analyst can plan the work.
Sequence the questions so an answer to one can change the next. For example, confirm the buyer segment before asking which competitors appear in that segment. If a question depends on an unavailable source, record the dependency and the fallback. A sequenced brief is easier to review and less likely to produce a broad report with no clear answer.