Product Brief Template: What to Agree Before the PRD

Key takeaways:

• A product brief is one page whose job is to get a decision made. Seven fields carry it, and every requirement belongs in the PRD that follows.
• The non-goals section is the one almost every product brief template leaves out, and it is the section that saves the most money.
• If your document contains user stories or acceptance criteria, it has stopped being a brief and become a PRD.
• Government service guidance is explicit that reframing a problem includes agreeing what is not part of it.

A good product brief does one job: it gets a decision made. One page, seven fields, and at the end of it somebody says yes, says no, or names the specific thing they object to.

That is harder than the format suggests, because a product brief template can be filled in completely without deciding anything. A document that avoids deciding is just a longer way of saying "let's build it."

This guide covers the brief for software and digital products. A product development brief template for a physical product can use the same fields, though the examples below will not transfer.

A brief is also the first of two documents, not the only one. Once the brief is agreed, the detail goes into a product requirements document, which is where requirements, acceptance criteria and edge cases belong. Keeping those two apart is most of what makes either one useful.

What a Product Brief Is, and What It Is Not

A product brief is a short document, one page in practice, that makes the case for spending money on something. Its audience is whoever approves the work, and its job is to get a yes, a no, or a specific objection.

That makes it a decision document rather than a description. The test is simple: if nobody could reasonably say no to what you have written, you have not written a brief, you have written an announcement.

Three things a brief is not, and each one is a common failure:

• It is not a requirements document. Requirements are what the PRD exists for, and putting them in the brief makes the brief too long to read and too detailed to argue with.
• It is not a business case with a financial model. A brief states the constraint and the expected outcome, not a three-year projection.
• It is not a design. A brief can say what the thing roughly is, but the moment it specifies screens, it has pre-empted the work it was supposed to authorize.

Keeping those three out is what lets a brief stay on one page, and one page is what gets it read.

The Seven Fields a Product Brief Needs

Across the briefs and templates in circulation, seven fields appear consistently enough to count as the core. Everything else is a house preference.

The first field is the one most briefs get wrong, and it is worth being strict about it. The UK's Government Digital Service gives a clean example of the difference in its discovery phase guidance. Saying you need to build an interactive map showing people where your offices are is not a problem, it is a solution someone has already picked.

The problem underneath it is how to make it easier for people to find their nearest office when they need an appointment. Stating it that way is what the guidance asks for.

That reframing is not pedantry. A map is one answer to that problem, and a postcode search box might be a better and cheaper one, but you can only discover that if the brief left the question open.

The same requirement written twice, and only one version leaves a second answer available.

The second field rewards the same strictness. Naming one concrete group beats listing every audience, and the customer personas you already have are where that name comes from.

The Constraint Is Part of the Problem

Most templates file time and money under "budget and resources," near the bottom, as administration. That placement is backwards, because the constraint is what determines which solutions are even eligible.

Basecamp's Shape Up calls this the appetite, and makes the point directly in the chapter on writing the pitch: you can think of the appetite as another part of the problem definition. Six weeks and three months are different problems, not the same problem with different funding.

Writing the constraint into the brief up front does something a budget line never does. It converts "what should we build?" into "what is the best thing we can build in six weeks?", which is a question a team can actually answer.

State it as a ceiling rather than an estimate. A brief that says "we are willing to spend about six weeks on this" is making a decision. A brief that says "estimated at six weeks" is making a prediction, and predictions get argued with instead of acted on.

Non-Goals: The Section Almost Every Template Skips

Of the product brief templates in general circulation, almost none carries a non-goals field. That is the single biggest gap between the templates people download and the briefs that actually work.

A non-goal is not a negated goal. Malte Ubl draws the distinction carefully in his account of design docs at Google: a non-goal is not something like "the system shouldn't crash," it is something that could reasonably have been a goal and has been explicitly chosen not to be one.

That gives you a test you can apply to every line. If nobody would ever have asked for it, it is not a non-goal, it is noise. If a sensible person would plausibly have expected it, write it down.

The clearest worked example sits in the same chapter, under no-gos. Building a payment form, the team ruled out any WYSIWYG editing of the form itself: customers could supply a logo and customize the header text on a separate page, and nothing else. The reasoning was explicit, that WYSIWYG might be better in some people's eyes, but given the appetite it mattered to mark it as a no-go.

The habit is documented downstream too. Atlassian's guidance on requirements documents lists clear out-of-scope items among the elements of an effective PRD, alongside goals and assumptions. That is the feature-level cousin of the same instinct, and the two lists are not interchangeable, which is a distinction worth holding on to.

Government service guidance puts it most plainly of all: reframing the problem also includes agreeing what is not part of the problem. Agreeing, not assuming.

How to Write Non-Goals That Hold

A non-goal only works if it survives contact with the person who wanted the thing. Three rules make that likely.

Name the thing specifically, not the category. "No reporting" invites a fight; "no custom report builder in this release, the five fixed reports only" does not.

Give the reason in the same sentence, and make the reason the constraint rather than taste. "Out of scope given the six-week appetite" is harder to reopen than "we decided not to."

Say where it went, if it went anywhere. A non-goal that is genuinely deferred should say so, because "not now" and "not ever" are different promises and people will remember whichever one suits them.

Where the Brief Stops and the PRD Starts

The cleanest boundary test in circulation is about artifacts rather than length. If your document contains user stories and acceptance criteria, it is a PRD. If it has a problem and a success measure but no user stories, it is a brief.

That test is useful because it catches the most common drift. A product manager writes a brief, keeps adding helpful detail, and ends up with a six-page document that is too specific for an approval conversation and too vague for an engineer.

One nuance is worth stating because the sources genuinely disagree. Non-goals appear in both documents, and they are not the same non-goals.

The two lists sit at different levels, and that is what keeps them apart.

The brief's non-goals are business-level: the outcomes and audiences you are choosing not to serve. The PRD's out-of-scope list is feature-level: the specific functionality this release will not ship. Writing both is not duplication, and collapsing them into one list is how a business decision gets quietly reopened as a feature discussion.

Product Brief Example

Here is the template filled in. The subject is a fictional internal tool, and the numbers are illustrative rather than drawn from a real engagement, which is worth saying because a product brief sample with invented client results is worse than no example at all.

Notice how much the non-goals row is doing. Without it, "a web tool that outputs run sheets" could reasonably be read as including driver notifications, and that reading would surface in week four.

Both halves of that row start from a number the team already has.

The success measure is the other row worth copying. It names a number somebody already tracks, which is what separates a measure from a wish, and the fastest route to one is talking to users first rather than guessing at the baseline.

How to Write One in Five Steps

The order matters more than the formatting, because each step constrains the next.

Step 1: Write the Problem Without the Solution in It

Draft the problem in two or three sentences and then delete every noun that is a thing you would build. If the paragraph collapses, you were describing a solution. Our own framing on whether a problem is worth solving is the test to apply before going further.

Step 2: Name Who Has It, Specifically

Replace "users" with a group you could go and talk to this week. Three dispatch coordinators is a group, and the market is not. If personas already exist, name the single one this is for rather than listing all of them.

Step 3: Set the Constraint Before the Solution

Decide what the problem is worth before deciding what to build, and write that number down. Doing it in this order is what stops the solution from setting its own budget.

Step 4: Write the Non-Goals From the Objections You Expect

List the things a reasonable colleague would assume are included, then rule out the ones you are not doing and say why. This is faster than it sounds, because you usually already know which three questions will come up in the meeting.

Step 5: Get It Signed, on a Date

A brief that circulates without approval is a memo. Name the person who approves it and record the date they did, because that date is what you point at when scope reopens in week five.

The five steps take an afternoon, which is cheaper than the week four conversation they prevent.

Why the Brief Is Worth the Afternoon

Poor definition is not a soft problem. PMI's 2014 research on requirements management puts inaccurate requirements management behind 47 percent of projects that miss their goals, which is close to half of every failure it studied.

That figure is about requirements rather than briefs specifically, and the mechanism is the same one: work that was never pinned down precisely enough to build against.

At VAULT the briefs that save the most money are the ones that scope two things at once. Take Neuropeak Pro, where the deliverable was a sports-performance belt and the app it talks to. The belt runs on Movesense, an open-source hardware platform, and what it has to report is breathing and heart rate variability, captured in real time and combined into a usable score.

Capturing both at once is the success measure, and the constraint sat right beside it: the setup being replaced had cost users upwards of $2,500, so a cheaper device that captured only one of the two would have failed the brief rather than partly met it.

One plan had to carry both electrical and software engineering. When firmware and an app ship together, the non-goals are what stop either side quietly annexing the other's schedule.

The brief also tells you what to go and learn before building. Government guidance on discovery is unambiguous that you should not start building during it, and puts four to eight weeks as a typical length for a genuine discovery phase. A good brief names the open question; discovery answers it.

Product Brief Template in Word, Docs, or Notion

The format matters far less than it is usually given credit for, and a product brief template in Word has no advantage over any other container. The seven fields, plus the open-questions and sign-off rows, work identically as a two-column table in Word, Google Docs, Notion or a plain text file, and the version above pastes into any of them.

What does matter is that the document is commentable and versioned. A brief gets its value from disagreement, so a format where the operations director can leave a note in the margin beats a locked PDF every time.

One warning on template galleries. Several of the most downloadable product brief templates are built for marketing launches and carry pricing strategy and competitive positioning fields, which are the wrong prompts for an internal software build. Delete the fields that do not apply rather than filling them in to be thorough.

Product, Marketing, Design and Development Briefs

Four documents share the word "brief" and get confused constantly, usually because someone downloaded the wrong template.

A product marketing brief template will ask for positioning, channels and launch dates, and a product design brief template will ask for references, tone and accessibility constraints. Neither prompt belongs in the document that decides whether to fund the work at all.

A new product development brief template, in the manufacturing sense, covers tooling, materials and unit cost, and those fields have no equivalent in software. If that is the document you need, the structure here will help with the problem and non-goals sections and nothing else.

The useful rule is that the product brief comes first and the other three inherit from it. A design brief written before anyone agreed the problem will produce a beautiful answer to the wrong question, which is why our design work starts by reading whatever brief already exists and asking what it decided.

What to Do With the Brief Once It Is Signed

Hand it to whoever is writing the PRD and keep it. The brief is the thing you reread in week five when someone asks for driver notifications, and its value at that moment is entirely in the non-goals row.

Answering the open question comes next. A brief that names one unknown and gets it resolved before the build starts is worth more than a brief that reads as though nothing is uncertain, because the second one is not true.

A brief sitting in a doc with nobody willing to approve it usually means the problem is not yet specific enough to argue about. Talking to a handful of the people who actually have it unsticks that in about a week.

Contact us if a second read would help before it goes out for approval.

FAQs

What is the difference between a product brief and a PRD?

A brief argues that something is worth doing and says what is out of scope, in about a page, for whoever approves the spend. A PRD specifies what gets built, for the team building it, and runs as long as the detail requires.

The practical test is artifacts rather than length. If the document contains user stories or acceptance criteria, it is a PRD.

What should a product brief example actually contain?

Seven fields carry the weight: the problem, who has it, why now, the success measure, the rough approach, the constraint, and the non-goals. Open questions and a sign-off line are worth adding.

Anything beyond that tends to be house preference, and anything that specifies screens or fields has crossed into PRD territory.

Is there a product brief template for Word specifically?

Nothing about the structure is Word-specific. A two-column table of fields and answers pastes cleanly into Word, Google Docs or Notion, and the version in this article is written to do exactly that.

Pick whichever format your approvers will actually comment in, since the brief's value comes from the disagreement it surfaces.

How long should a product brief be?

One page, and treat that as a constraint rather than a guideline. The length cap is what forces the document to decide things instead of describing them.

If it will not fit, the usual cause is requirements that belong in the PRD rather than a problem that is genuinely complicated.

Who writes and who signs the product brief?

Whoever owns the problem writes it, which is often a product manager and sometimes an operations lead who lives with the pain daily. Whoever controls the budget signs it.

Separating those two roles is the point. A brief signed by its own author has not been agreed with anyone, and validating the idea first makes the signature mean more.

Need a Second Read on Your Brief?

A brief is easiest to improve before anyone has committed to it. Contact us and we will read yours, tell you which field is doing the least work, and name the non-goal we think is missing.