“Write me an email to customers” is the most common first message we see, and the one that most often ends with someone deciding the assistant is not very good. The assistant did exactly what it was asked. It was asked for a topic.
A topic is what the result is about. A brief is what the result is for, who reads it, what it must say and what it must not. People do not notice the difference because a colleague fills the gap from context — they know the customers, the product and last month’s email. The assistant knows only what is in the message and the project profile.
What a short request leaves out
Take “write me an email to customers”. To write a good one, a person would need to know:
- which customers — all of them, new ones, the ones who have not ordered in a year
- what the email is for — an announcement, a reminder, an apology, a thank-you
- what must be in it — a date, a price, a link
- what must not — a discount you cannot give, a promise you cannot keep
- how long it should be, and how formal
None of that is in the request. So the assistant picks the most likely answer to each question, and the most likely answer is the average one. You get an average email.
The four-line brief
You do not need a template or a form. Four lines cover almost every job:
- Goal and reader. “An email to customers who ordered in the last six months, to tell them about new opening hours.”
- Must include. “The new hours from 1 November, the reason in one sentence, a link to the booking page.”
- Must avoid. “No discounts, no apologies, no exclamation marks.”
- Shape. “Under 150 words, two short paragraphs, friendly but plain.”
That takes a minute to write and usually saves three rounds of corrections.
Why the profile matters
Some of those lines are the same every time: the tone, the words you never use, the facts about the business. Writing them into every request is tedious, so most people stop doing it — and the answers drift back to average.
The project profile exists for exactly this. What is in the profile is read before every request in the project, so the brief only has to carry what is new. If you find yourself typing the same instruction twice, it belongs in the profile.
Correcting without starting over
When a draft misses, say what is wrong rather than asking again from scratch. “The second paragraph is too long, and do not mention the parking” keeps everything that worked and fixes what did not. Starting over throws the good parts away with the bad ones.
And when a correction is something you will want every time — “never call them clients” — add it to the profile. The next draft will already know.
The short version
A request names a topic; a brief describes a result. Give the assistant the goal, the must-haves, the must-nots and the shape, keep the permanent rules in the profile, and correct drafts instead of restarting them. The first project guide walks through the same idea with a full example.
