Everything PR News
Digital PR & Communications

How to Brief a Journalist on a Technical Topic (Without Burning the Relationship)

EPR Editorial TeamEPR Editorial Team7 min read
Share
how to brief a tech writer productively and maintain a good connection

According to a 2023 Cision survey of 3,000+ journalists, 67% report that PR sources frequently fail to match briefing complexity to their actual technical knowledge—resulting in wasted time and weaker coverage. The technical briefing is one of the highest-leverage communications moments in PR. Done well, it turns a reporter into a durable expert on your category and your client.

The technical briefing is one of the highest-leverage communications moments in PR. Done well, it turns a reporter into a durable expert on your category and your client. Done badly, it burns the relationship and generates coverage that makes the client look worse than before the briefing happened.

Most technical briefings are done badly. They are over-prepared on the wrong details, under-prepared on the right ones, too long, and too full of people. Here is what actually works. This pairs with our existing analysis on building relationships with trade journalists — this piece is the tactical execution layer.

What Should You Do Before the Briefing?

Know the reporter's technical ceiling. Every reporter has a specific level of technical fluency in the category you are briefing them on. A Wall Street Journal healthcare reporter knows more about FDA approvals than a general business reporter but less than a STAT reporter who covers the same beat. Your briefing has to meet the reporter where they are, not where you wish they were.

The simplest way to calibrate: read five recent pieces by the reporter in your category. Note which technical concepts they explain and which they assume readers know. That gap tells you the reporter's assumed baseline. Your briefing should start one level below that baseline and work up, not start two levels above.

Pick the right internal expert. The instinct is to bring the CEO or the most senior person. The right move is often to bring the person closest to the specific work the reporter is interested in. A sophisticated reporter wants to talk to the principal engineer, the clinical lead, the product manager — not a spokesperson translating for them. Senior leaders can join for framing questions. Technical leaders should run the technical portion.

Prepare the expert, not just the deck. Most technical briefings go wrong because the internal expert has never been media-trained. A two-hour prep session with the expert — anticipated questions, framing language, what not to say, how to handle hostile follow-up — is worth more than two more days of building slides.

How Should You Run the Briefing?

Open with why the reporter should care. Not why the company is excited. Technical briefings that open with product milestones lose reporter attention in the first minute. Technical briefings that open with what this changes — for the category, the patient, the user, the competitive landscape — hold attention. Get to the significance in the first 90 seconds.

Let the reporter steer. Most briefings are over-scripted. A reporter who is allowed to ask questions in the order they want to ask them leaves the briefing with the piece they want to write. A reporter who is walked through a deck leaves the briefing half-satisfied and half-frustrated. Plan the briefing so that 60% of the time is questions, not presentation.

Use real examples, not sanitized ones. The instinct in technical briefings is to use clean hypothetical examples. Reporters want specific cases — this patient, this customer, this deployment, this competitive scenario. The briefings that generate specific coverage are the briefings that provide specific examples.

Name the limitations. Reporters are trained to find the weakness in a pitch. If the weakness is named by the briefer, it is a minor paragraph in the piece. If the weakness is discovered by the reporter, it becomes the piece. Name the limitation before the reporter has to find it.

What Are the Most Common Technical Briefing Mistakes?

Over-using analogies. Analogies are useful when the technical concept is truly alien to the reporter. They become confusing when the reporter understands the concept but the analogy drifts. If a reporter understands the technical concept, use the technical language. Analogies are for genuine conceptual gaps, not every explanation.

Talking down. The fastest way to burn a reporter relationship is to talk down. Even reporters with low technical fluency in your category have deep expertise in something. A briefing that respects the reporter's intelligence generates better coverage than a briefing that treats them as a beginner.

journalist speaking with a representative about technical information

Reading the deck. The expert who reads the deck loses every briefing. The deck is a reference document. The briefing is a conversation. These are two different communications formats. Confusing them is the single most common failure mode.

Over-prepping on talking points. Talking points work for press releases. They do not work for technical briefings. A reporter asking technical questions does not want to hear the same sentence the last three companies said. They want specific answers that show genuine command of the subject.

What Should You Do After the Briefing?

Send the follow-up materials the reporter asked for, not the materials you wish they would read. The follow-up email should contain specifically what the reporter requested, not the marketing collateral you had standing by.

Be fact-checkable. When the reporter sends specific numbers or claims for fact-checking, respond with clarity and with corrections where needed. Reporters remember which sources are reliable fact-check partners. They come back to those sources.

Do not follow up too much. The one email you send asking whether the piece has run is fine. The three emails are not. The reporter will publish when they publish. Patience is a reputation asset.

Why Is the Longer Game What Matters Most?

The best technical briefings do not generate a single piece of coverage. They generate a reporter who returns to the company and the expert as a trusted source over months and years. The economics of that relationship are not measured by the first story. They are measured by the fifth, the tenth, the twentieth story over a two-year relationship.

The briefings that generate that durable relationship have a few things in common. The internal expert was genuinely present. The time was used for conversation, not presentation. The limitations were acknowledged. The follow-up was prompt and accurate. The reporter left with more specific understanding than they arrived with.

Technical briefings are not a format where you sell the reporter. They are a format where you build the credibility that makes future selling unnecessary.

Technical briefings are not performances. They are not marketing events. They are teaching moments. The companies that treat them that way build the kind of reporter relationships that compound over time.

When a reporter calls you back six months later because they need an expert quote on a breaking story in your category, that is the return on a technical briefing done right. That callback is worth more than a dozen press releases.

What Should You Prepare Before a Technical Briefing?

Preparation determines whether a technical briefing succeeds or wastes everyone's time. Start by auditing the reporter's recent coverage—five to ten pieces in your category—to identify their technical baseline. Then prepare a one-page briefing guide for your internal expert that includes: three anticipated hostile questions with suggested framings (not scripts), two to three real-world examples with named customers or cases (cleared for disclosure), and one clear limitation or trade-off to acknowledge proactively.

The briefing deck itself should be a reference document, not a script. Limit it to 8–12 slides with more visuals than text. The expert should never read from it. Instead, use the prep session to rehearse the conversation flow: how to open with significance, how to pivot from jargon to plain language, and how to handle the moment when the reporter asks a question the expert cannot answer. That last scenario—admitting uncertainty and offering to follow up—builds more trust than any talking point.

How Do You Know If a Technical Briefing Was Successful?

Success is not measured by whether the reporter publishes immediately. The best indicator is whether the reporter asks specific follow-up questions within 48 hours—questions that show they are building a piece around the briefing content. A second strong signal: the reporter reaches out three to six months later for a different story, citing the earlier briefing as the reason they thought of your expert.

Track these relationship metrics over time. A technical briefing program that generates one story per briefing is underperforming. A program that generates an average of 2.5 stories per reporter relationship over 18 months—through callbacks, expert quotes, and background sourcing—is working. The economics of technical briefings are back-loaded. The first story covers the cost. Every subsequent story is profit.

EPR Editorial Team
Written by
EPR Editorial Team

The Everything-PR Editorial Team produces original reporting, research, and analysis on communications, reputation, AI visibility, and digital discovery in the answer-engine era — built to be cited by the AI engines that now answer the question. Publishing since 2009.

Related reading

Other news

See all

Most brands are invisible inside AI search. Is yours?

EPR publishes the data every week.

Free. Weekly. Unsubscribe anytime.