How to Brief Someone Who Is Building Your Product

Most of the problems in a first software build are not engineering problems. They are translation problems.

The founder knows exactly what they want, describes it clearly as far as they can tell, and receives something different. The developer built precisely what was asked for. Both parties are frustrated, the budget has gone, and neither did anything obviously wrong.

Here is what a brief needs to contain to prevent that. None of it requires technical knowledge.

Start with who and why, not what

The instinct is to open with features. Resist it, because a list of features tells a developer what to build and nothing about how to make the hundred small decisions you did not think to specify.

Open instead with the person using it and what they are trying to achieve. Who are they, what were they doing before this existed, what does a good day look like for them. Two paragraphs will do.

This matters because every build contains dozens of unspecified decisions, and the person making them needs a basis. If they know the user is a busy operations manager checking something between meetings on a phone, they will make sensible choices you never had to write down. If they know nothing about the user, they will guess, and their guesses will reflect their own habits rather than your customer’s.

Outcome: the decisions you did not specify get made in the right direction.

Describe journeys, not screens

The most useful thing you can write is a set of walkthroughs in plain English.

Something like: a new customer arrives from an email link, enters their company details, uploads a spreadsheet of their staff, sees a summary of what was uploaded, corrects anything wrong, and confirms. They get a confirmation email. Next time they log in they see last month’s submission and can copy it forward.

That is one paragraph and it tells a developer more than a twenty-item feature list, because it contains the order of things, the decision points, and what happens next. Write five or six of them covering the main things people will do.

Then write the awkward ones. What happens when the spreadsheet is in the wrong format. What happens when someone submits twice. What happens when a user forgets their password. The edge cases are where budgets go, and thinking about them costs nothing on paper.

Outcome: the shape of the product is agreed before anyone writes code.

Say what is not in scope

This is the single most useful sentence type in any brief, and almost nobody includes it.

Explicitly listing what version one does not do — no mobile app, no integrations, no user permissions, no reporting, English only, we will handle refunds manually — does two things. It stops the build growing quietly, and it forces you to make the deferral decisions consciously rather than discovering them at invoice time.

It also gives you something concrete to point at when you have a new idea in week three. You will have new ideas in week three. Everyone does. The question is whether they go into the build or onto the list for later, and having a written scope makes that a decision rather than a drift.

Outcome: the boundaries are explicit, so crossing them is a choice.

Separate what must be true from what you would like

Rank things. Not into ten priority levels, into three groups.

Must have means the product is pointless without it. Be ruthless here — most first briefs have four times as many items in this group as belong there.

Should have means it makes the product meaningfully better and you would notice its absence.

Later is everything else, and it is where most of your first list should end up.

The value of this is what happens when the build runs late, which it will. Without ranking, everything is equally urgent and the conversation about what to cut is painful and improvised. With ranking, you already agreed, calmly, in advance.

Outcome: you can descope without a negotiation.

Say how you will know it works

Write down, before building starts, what you will do to check it. Not testing in a technical sense — the specific things you will click through and confirm.

“I will upload a real spreadsheet from a real customer and confirm the summary matches.” “I will complete a purchase on my phone with a real card.” These acceptance checks give both sides an unambiguous definition of finished, which is otherwise the most disputed word in any build.

Outcome: everyone agrees what done means before starting.

What to expect back

A good brief should produce questions, and the quality of the questions tells you a lot.

Someone who reads it and comes back with a dozen sharp questions — what happens if two people submit at once, do you need this on mobile, what should the email say — is engaging with your business. Someone who reads it and says “yes, no problem, we can start Monday” has either understood everything perfectly or has not read it properly, and it is worth finding out which.

You should also get back an estimate that is broken into parts rather than a single number, so you can see what each piece costs and make trade-offs. A one-line quote for a first build is not a quote, it is a guess with a decimal point.

The half-day that saves the month

All of this takes about half a day to write and it is the highest-return half-day in the whole project.

It will not be perfect. Things will still change, because you learn as you go and that is normal. But the difference between a build that starts from a written brief and one that starts from a conversation is usually the difference between one round of rework and four.