You are about to hand something you have spent two years engineering to a team of people who have never seen it. You have read the case studies, the deck was good, and you still have the feeling that what comes back is going to be a hero image of a city skyline and the word “innovative” three times above the fold.
That feeling is well calibrated. It happens often enough that most technical companies have a story about it. And it is not usually a failure of effort on the agency’s part. Explaining an engineered product requires understanding the product, and a team staffed for general commercial work is not set up to acquire that understanding inside a normal engagement timeline. What gets written is copy around the product rather than about it.
The good news is that the outcome is largely determined by you, before the engagement starts. This guide covers what to put in the brief, where the right language already exists inside your company, how to test whether an agency actually understood the product, and what to do when the first draft comes back wrong.
What Belongs in the Brief
A brief is not a creative wish list. It is the transfer of everything your team knows and the agency does not. Assume nothing is obvious.
- State the problem before the product. Open with what goes wrong in the world when your product does not exist. Who suffers it, how much it costs them, and what they do about it today. Everything downstream is easier to write once this is settled and considerably more expensive while it is not.
- Name the buyer and the person they answer to. An engineer specifies your product and a director signs for it, and those two need different arguments. Say which one the material is for. Where both matter, say which pages serve which.
- Say what you are actually compared against. Not the market map. The three things that genuinely come up on calls, including the incumbent, the in-house build, and doing nothing. Doing nothing is usually the strongest competitor and it is almost never in a brief.
- Include the specification, and a plain-language version of it. Hand over the datasheet, the architecture diagram, the protocol list. Then write two paragraphs explaining what a non-specialist should take from it. The gap between those two documents is exactly the gap the agency has to close.
- Fix the vocabulary. List the terms that are correct, the terms that are wrong, and the terms that are legally loaded. If your industry has a settled name for a component, use it. Renaming a known thing to something prettier removes you from every search query that uses its real name, which is one of the mechanisms we cover in why technical products fail to rank.
- Separate what you can substantiate from what you would like to say. Give the agency the tested figures, the certifications you actually hold, and the claims your counsel has already refused. A writer who does not know where the line sits will either cross it or stay so far back that nothing specific gets said.
The Material That Already Contains the Right Language
The most useful part of a brief is usually not written for the brief at all. In our experience, effective positioning is already sitting in your support records rather than waiting to be invented, and handing over the raw material is worth more than another round of stakeholder interviews. It is where every positioning engagement we run starts.
- Support tickets, unfiltered. These are your customers describing your product in their own words, at the moment they care most. The recurring confusions tell you what your documentation fails to explain. The recurring praise tells you which capability people actually value, which is frequently not the one on the home page.
- Sales call objections. Ask your sales team for the five objections they hear every week and the answers that work. Objection handling is the highest quality copy in most companies, and it is almost never written down anywhere a marketer can find it.
- The emails your engineers keep answering. There is a small set of questions your technical staff answers by hand, repeatedly, for qualified prospects. Each of those replies is already a page, written in the right register, by somebody who knows the answer, for exactly the person you are trying to reach. Forward the whole thread, question and answer.
- Win and loss notes. Why the last three deals closed and why the last three did not. A loss to a competitor on one specific capability is a positioning instruction.
- A recording of a real demo. Not a polished one. A working demo to a real prospect, with the interruptions and the follow-up questions intact, tells a writer more about how the product is understood than any document.
Hand these over as they are. The temptation is to summarize them first, and the summary is where the specificity dies.
How to Test Whether They Understood It
Do this before creative work begins, while changing direction is still cheap.
- Watch what they ask during discovery. A team that is going to get this right asks narrow questions: how the device behaves when the network drops, why you chose one protocol over another, what the failure mode looks like on a customer site. A team that is not asks about your brand adjectives and which competitors’ websites you like.
- Ask for the product explained back, in writing, before any copy. One page. What the product is, who it is for, why the alternatives fall short. Give that page to an engineer and ask them to mark up anything wrong. The marks tell you precisely how much translation work is still outstanding, and it is far better to learn it now.
- Give them one hard question to answer publicly. Pick a genuine technical question from your support inbox and ask them to draft the answer using the material you supplied. This is the single most predictive test we know of. Anybody can write a home page. Very few teams can write a correct answer to a specific technical question.
- Ask who is holding the pen. Not who is on the pitch team. The named person writing the words, and what they have written before for a technical audience. Ask for three examples and read them.
- Check that they will implement, not just recommend. Technical SEO findings delivered as a document for somebody else to interpret tend to sit unimplemented for a year. Findings delivered as changes to the site get made. When you are shortlisting, listings on platforms like Clutch.co are a reasonable starting point, but the question of who actually ships the change is one you have to ask directly. There is more on how we structure that in our process.
When the Copy Comes Back Generic
It will sometimes come back generic anyway. The response that works is diagnostic rather than annoyed, because the same conversation is about to repeat on the next deliverable if you only fix the symptom.
- Mark up the draft with an engineer in the room. Not “this feels weak.” Mark the specific sentence that is factually wrong, the claim that cannot be substantiated, and the paragraph that would apply equally to any company in your sector. That third category is the real diagnosis.
- Ask what they were missing. Frequently the answer is that a question was asked and never came back from your side. Briefing is a two-way failure more often than anyone admits, and the fix might be an hour of an engineer’s time rather than a new agency.
- Replace an abstraction with a fact, once, and show them. Take one paragraph and rewrite it yourself using a real number and a real behavior. A single worked example teaches the register faster than a page of feedback.
- Set a hard rule for the next round. Every claim must be attributable to something in the source material. This is a straightforward standard to apply and it eliminates the entire category of confident, unfalsifiable sentences.
- Know when the gap is structural. If the second round is still written around the product, the issue is capability rather than communication, and no amount of further briefing will close it. That is worth establishing early rather than three months in.
The Standard Worth Holding Out For
Our position on this is straightforward, and it is the reason our technical marketing practice is staffed the way it is: the people writing about a product should be able to read its specification. Not skim it. Read it, understand the tradeoffs in it, and ask an engineer a follow-up question that the engineer finds worth answering.
Once that is true, everything else in this article gets easier. Positioning can be written from the technical reality instead of around it. Comparison material can be written honestly against a competitor’s actual specification. And the search visibility follows, because specific technical language is the only thing a specific technical query can match against, which is what we found working through organic search growth for a specialist retailer.
The brief is where that starts. Spend the day on it. It is the cheapest hour of the whole engagement and it decides most of what comes back.