Quick answer: the only brief that matters is the product description, and it carries five things: who it is for, the problem, how it works, the result, and the proof. The quality of every asset downstream is set by this input; a vague brief cannot be rescued at the design stage.

Why the brief is the bottleneck

Most launch problems are diagnosed at the wrong end. The graphic looks generic, so the assumption is that the design failed; the caption feels flat, so the copy is rewritten. In both cases the upstream input was abstract — "a modern tool for teams" — and no amount of composition can extract a specific claim from a generic sentence.

The brief is where the information lives. It is also the only place where the founder's knowledge is complete, which makes it the cheapest place to do the work.

The five parts

Part What it answers A good version
Audience Who is it for A named role in a named situation
Problem What is broken The specific cost of the current way
Mechanism How it works Steps, not adjectives
Result What changes The outcome the user can point to
Proof Why believe it A number, a customer, or a demo

Audience before feature

The audience line is the one that determines the rest. "For developers who maintain internal APIs" sets the vocabulary, the scenes, and the claims; "for everyone" sets none of them. When the audience is too broad, the safest move is to write the brief for the primary buyer and note the others separately.

Mechanism beats adjectives

"Fast" and "simple" are conclusions, not material. The mechanism is the material: what the user does, what the product does, what comes back. Three steps in plain language give the how-it-works angle everything it needs; adjectives give it nothing.

Proof is the scarce part

Most founders can write the first four parts and stall on proof, because early products have few numbers. The honest options are narrower than they look: a before/after measurement, a recorded demo, a named early user, or a comparison against the manual way. Invented proof is the one input that cannot be used.

Length and format

The brief fits in a screen: three to five paragraphs, or a short list. It is not a marketing document, so it should not be polished; it should be specific. A rough sentence with a real detail beats a polished sentence with a generic one.

The production workflow

A complete brief is the single input that makes asset generation mechanical, and Neatico takes it as the source of truth — the audience, mechanism, and proof in the brief become the angles, with no second interview.

Frequently asked questions

What should a product description include? The audience, the problem, how it works, the result, and the proof. Specifics over adjectives; the brief is internal, not polished.

How long should a product brief be? A few paragraphs or a short list, fitting on one screen. Length is not the issue; missing parts are.

What if I have no proof yet? Use a measured before/after, a demo, or a named early user. Never invent numbers. The product description guide has the writing mechanics.

Can the brief be updated after the set is built? Yes. Update the source and regenerate the affected frames rather than editing the files one by one.