Blog

Turn research into a meeting brief

The meeting is on the calendar. You have a folder of research: a job post, two engineering articles, a few names, a funding note. The risk now is walking in with all of it, in no order, and spending ten minutes looking for the point.

A meeting brief fixes that. It is one page, built from your research, that you read in the last five minutes before the call. This article shows what goes on it, how to build one for a deal with several technical people, and how Repclose makes one from a sourced plan. It assumes you already have research. If you don't, start with how to research a technical account.

What the brief has to answer

Four questions, in this order:

  1. Who will be in the room, and why would each person care?
  2. What changed at the company recently?
  3. What do I not know yet, and what will I ask?
  4. What do I bring?

A fact that answers none of them stays in the folder.

Who will be in the room, and why they care

A complex technical deal has several people, and they want different things. In many deals you meet some mix of these:

PersonWhat they tend to care aboutWhat to find out
An engineer who feels the problemLess pain in their own week, and a tool that works with what they run now.What breaks, how often, and what they use today.
The lead of that teamWhether their team can take on one more tool, and what it replaces.What the team is trying to ship or fix this quarter.
A security or platform reviewerWhere data goes, who can reach it, and how it fits the company's rules.What a new vendor has to pass before a trial.
Whoever holds the budgetWhether it is worth the money and the effort next to other work.How the company buys, and who else signs off.

Treat the table as a starting guess; your research should correct it. For each person you expect, write three short lines: their role in this deal, the problem their team owns, and one dated fact that shows it. For example: "Director of platform engineering. Owns on-call design. Posted a first staff reliability role on October 6."

Two checks keep this honest. First, confirm each person still works there, and write the date you checked. Second, if you can't say what a person has to do with the deal, don't invent a reason. Put them under questions: "What is your part in choosing a tool like this?"

What changed recently

This is the part that tells the room why you called now. List changes newest first, each with its date:

  • A new leader started, or a team was reorganized.
  • Job posts show a migration or a first hire for the role that owns the problem.
  • The company launched something, or published a long engineering article about a problem you solve.
  • The status page shows a run of incidents.

Keep only changes that bear on this meeting, and be plain about age. A post from last week is news. A post from last year is background, and you should say so instead of presenting it as new. If a source has no date, write "undated" and treat the point as a lead to check. The article on buying signals covers which changes hold up.

Then test each line. If the sentence would work for any other company, cut it. "They are growing fast" fails. "They posted their first staff reliability role on October 6" passes.

Questions to ask

Every gap in your research is a question, and the best questions come from three places:

  • Gaps. Something you looked for and did not find, like who owns the budget or what they use for alerting today.
  • Guesses. Something you inferred and want confirmed. "I read the job post as a sign you plan to split on-call across teams. Is that right?"
  • Next steps. What has to be true for the group to take the next step, and who else needs to see this.

Write five to seven questions at most, and put the most important first. Make them open. "How do you handle on-call across teams today?" teaches you more than "Are you having alert fatigue?", which invites a yes and a shrug. Ask about their situation before you describe yours.

This list is not a script. It is what you need to learn, so you can listen when they answer.

What to bring

  • The one page. Print it or keep it on a second screen. One page forces you to choose.
  • Sources with dates. If someone asks where you saw something, "a job post from October 3" is a good answer. "I read it somewhere" is not.
  • Your guesses, marked as guesses. You will say a few things you have not confirmed. Know which ones.
  • One outcome you want. For example, a technical review with the platform team. Add a smaller fallback, such as a name of the person who should join next time.

Leave out the research dump, and any feature that doesn't connect to a problem you can source.

An example

Here is a brief for an invented company, Harbor Analytics, for a first call with two people.

Example brief: Harbor Analytics (an invented company)

Who
Director of platform engineering: owns on-call design, listed on the team page (checked Oct 24). Staff reliability engineer: spoke at a meetup about alert noise (Sept 28).
Why they care
The director's first staff reliability role lists on-call design as the main duty. The engineer's talk described pages that nobody acts on.
What changed
Reliability role posted Oct 6. Engineering article on moving to Kubernetes (Sept 12).
Ask
How do you split on-call across teams today? Who else would review a tool like this? Guess to confirm: they may already have an alerting tool, since the job post names none.
Bring
This page, with sources. Goal: a technical review with the platform team. Fallback: the name of the person who owns tooling.

Where Repclose fits

Repclose builds the research that feeds this page. You upload your accounts and a sales profile, and it ranks the accounts against that profile. It researches people for the top-ranked accounts only (the top 10 by default), lists about 10 people at each, and gives the top 5 a profile check and a short card on why they might care. The plan has sections such as At a glance, Top meeting plays, Why now, Green flags and Supporting sources. Each point links to its source, with the publication date where one is available.

From a finished plan, the Export menu has a one-page meeting brief. It holds six short answers: how the company makes money, who its customers are, who to talk to, why now, why they care, and black swans, which are recent events in their industry that could shift their priorities. Under "who to talk to" it lists up to five people with why they care, their pain, proof and an opener from the plan. Each line shows up to two sources. A source reads "Published" with its date. If Repclose has no publication date for it, the source says "undated"; the brief never shows the day Repclose read the page in place of a publication date. If research found nothing for an answer, the brief says "Not found yet" instead of filling the space. In the plan, a "Not found yet" item comes with a question you can ask.

The brief leaves out anything you hid, along with your own notes and what a customer told you, so you can forward it. You can copy it as Markdown or print it or save it as a PDF. The plan's Markdown and plain-text exports go further and tag each researched point as high, medium or low confidence. The word comes from how many sources back the point, how recent their publication dates are, and whether the point is stated or inferred. It is not a measure of whether the point is correct, so open the links before you rely on a point.

Repclose gives you a sourced starting page; you decide who matters and what you want from the meeting. See what one looks like in the sample brief, or run your own accounts.