What a brief is for
A naming brief is a decision tool, not a mood board. Its job is to make evaluation possible: when five candidates are on the table, the brief is what lets the team say why one fits and another does not, without relitigating taste each time.
The most common failure is a brief that describes outputs (“modern, clean, premium”) instead of the problem. Adjectives about style cannot settle an argument about fit. Sentences about the customer, the change and the criteria can.
Start with the customer and the change
Open with three sentences the whole team can repeat:
- Who the customer is, in plain language.
- What changes for that customer because of you.
- What stage the company is entering next, and why now.
Then add one sentence on the trigger for the review: the business change that makes this work necessary. “We moved from a self-serve tool to a platform sold to teams” is a trigger. “The logo feels dated” is a symptom, and worth separating from the trigger.
If you cannot write the trigger clearly, the brief is not ready—because the identity work would be standing in for a decision the company has not made yet.
Set evaluation criteria before options
Decide how candidates will be judged before anyone sees one. Useful criteria are testable in context: Can the team say it comfortably in a sales introduction? Does it carry the position without explanation? Is it distinct enough in the relevant market and search results? Can it sit in a product navigation bar and an event headline? What must be checked—linguistic, cultural, legal—before it could be adopted?
Write the criteria down and weight them. When options arrive, score against the written criteria first and discuss deviations second. This single habit removes most of the politics from naming decisions.
Separate requirements from preferences
A requirement is a condition the name must meet to do its job: “works in our two main markets”, “no collision with a direct competitor in search”, “survives the product expanding beyond its first feature”. A preference is a taste: “the founder likes six-letter names”, “we prefer names that end in a vowel”.
Both are legitimate inputs, but they must not carry equal weight. List requirements as pass/fail and preferences as tie-breakers. When a candidate fails a requirement, no amount of fondness rescues it; when two candidates pass everything, preferences may decide.
Name the constraints: markets, languages, category
Be explicit about the territory the name has to work in. Which markets and languages, now and plausibly next? Which category associations help and which would mislead—do you want to sound like the category or apart from it? What existing recognition, if any, is worth carrying forward?
Include the role of the address. If owning the plain .com matters to your introduction and email, say so now, while it can shape the name—read the .com decision for how to weigh it. If a prefixed or alternative address is acceptable, say that too, so the team is not silently optimising for something nobody required.
Constraints are not creativity-killers. They are what turn an infinite field into a searchable one.
Keep it to one page the team can remember
A useful brief fits on a page: the three opening sentences, the trigger, the weighted criteria, the requirements and preferences, and the constraints. Everything else belongs in an appendix nobody has to memorise.
Test it by reading it aloud to someone outside the project. If they can repeat back who the customer is, what changes and what “good” means, the brief works. If they remember only the adjectives, cut the adjectives.
When the brief is clear, the creative work has somewhere to land—and the decision at the end has somewhere to stand. If the review concludes the name itself must change, pair this brief with the rebranding guide and, before committing, test the leading candidates while change is still cheap.