A product brief is the page that decides whether a feature gets built and in what shape. It is read by the engineers and designer who will build it, by support and sales who will live with it, and by whoever approves the work. A good one answers four questions on one page: what problem, how much time, what roughly, and what not.
This template follows the pitch from Basecamp's Shape Up method, which has five parts: problem, appetite, solution, rabbit holes and no-gos. It adds a short "how we know it worked" list and a timeline. The example above is a brief for offline mode in Fieldwise, a made-up app for facility inspectors.
What goes in each section
The headline
The feature and the outcome with a time limit: "Six weeks to zero lost inspections." Under it, name the owner and the reviewers. Mistake to avoid: a headline that describes the feature ("Offline support v2") but not what changes for users.
01 · Problem
Numbers first, then one real quote. Fieldwise shows that 23% of inspections happen with no signal, 1 in 40 is lost to a failed upload, 31% of support tickets are about sync, and 4 of the last 10 lost deals named offline as the reason. Then an inspector: "I finish a two-hour inspection in a basement, press submit, and it is gone." Mistake to avoid: starting with the solution. If the problem is not convincing on its own, stop here.
02 · Appetite
How much time the problem is worth, and who works on it: "six weeks, one designer and two engineers. If it does not fit, we cut scope, not add time." Add one sentence for done: "an inspector submits an inspection with no signal, and it reaches the office when the signal returns." Mistake to avoid: an estimate instead of an appetite. An estimate grows; an appetite is a budget.
03 · Solution
The shape, not the screens: a flow of five steps from opening an inspection to "synced, with a receipt", and a table of elements with priority (P0 to P2) and whether each is in this cycle. Offline reports are P2 and out. Mistake to avoid: wireframes this early. They freeze details nobody has tested and invite comments on button colour.
04 · Rabbit holes
The risks that could eat the time, each with how you will handle it now. Fieldwise names three: two people editing one inspection offline (last edit wins, with a change log), hundreds of photos on a weak connection (resumable uploads, one at a time), and old Android phones (compress on the device, warn below 500 MB). Mistake to avoid: listing risks without a decision. A rabbit hole is closed in the brief, not during the build.
05 · No-gos
What is out, on purpose: no offline sign-up, no offline reports, no merging edits. Then how you will measure success: lost inspections from 1 in 40 to zero, sync tickets halved within 60 days, 80% of inspectors on the new version in 30 days. Mistake to avoid: leaving no-gos implicit. Whatever is not written down will be asked for in week four.
How long, and brief versus PRD
Keep it to one page and 400 to 700 words; the rules in how to write a one-pager apply here too. Write it a week or two before the cycle starts, review it in one meeting or in comments, and update it when scope changes during the build. If your organisation needs a full PRD with every requirement and edge case, this brief is still the right first page: it is what people read, and the PRD can link from it. For more PRD examples and longer formats, ProductPlan and Reforge publish good collections. If the work is a project with a sponsor and a budget rather than a feature, use a project brief.
How to use this template
- In Obsidian: install the free myone.page plugin, run New page from template and pick Product brief.
- With AI: paste interview notes, ticket counts and your idea into ChatGPT or Claude with the prompt from myone.page/ai, or use the Claude skill.
- By hand: copy the Markdown of the example. It is a plain note.
Where myone.page helps
A brief only works if the reviewers actually change it. Shared from the plugin, the brief is one link: engineers and designers edit it in the browser without Obsidian, and their edits come back into your note, so the page stays the spec instead of a copy that drifts. If your team already lives in Notion or Confluence and comments there, keep the brief there.