1myone.page Install free

Free template

Product brief template (a Shape Up pitch on one page)

A product brief, or product one pager, that fits a feature on one page: the problem, how much time it is worth, the shape of the solution, the risks and what is out. Engineering, design and support review the same page, and it becomes the spec.

Use this template needs the free Obsidian plugin; it makes a new note from the outline.

Example · Offline mode · Product brief

Offline mode for the Fieldwise app.
Six weeks to zero lost inspections.

Product brief for the November cycle, written as a Shape Up pitch: the problem, how much time it is worth, the solution, the rabbit holes, and what is out. Owner: product. Reviewers: engineering, design, support. Comment and edit here; this page is the spec.

01Problemwhy now
23%
of inspections happen with no signal
1 in 40
inspections lost to a failed upload
31%
of support tickets are about sync
4
of the last 10 lost deals named offline as the reason

What users tell us "I finish a two-hour inspection in a basement, press submit, and it is gone. I write everything on paper first now." Facility inspector, interview 12.

02Appetitehow much time it is worth

Appetite: six weeks, one designer and two engineers. If it does not fit, we cut scope, not add time.

Done when: an inspector finishes and submits an inspection with no signal, and it reaches the office when the signal returns, with nothing lost.

03Solutionthe shape, not the screens
Open inspection→Work with no signal→Saved on the device→Signal returns→Synced, with a receipt
Element
Priority
In this cycle
Inspections save on the device as they are filled
P0
yes
Photos queue and upload in the background
P0
yes
A clear status: saved, waiting, synced
P0
yes
Two people edit one inspection offline
P1
yes, but last edit wins
Download all of next week's sites in advance
P1
yes
Offline reports and charts
P2
no
04Rabbit holesrisks we solve now, before they eat the six weeks
  1. Two people edit one inspection offline. The last edit wins, and the inspection shows who changed what. Real merging waits for a later cycle.
  2. Hundreds of photos on a weak connection. Uploads resume where they stopped, one photo at a time; the form never waits for them.
  3. Old Android phones with little storage. Photos are compressed on the device; a warning shows below 500 MB free.
05No-gosout of this cycle, on purpose
No offline sign-upNew accounts still need a connection.
No offline reportsCharts and exports need the server.
No merging editsLast edit wins in this cycle.

How we know it worked

  1. Lost inspections. From 1 in 40 to zero, measured by upload receipts.
  2. Sync tickets. Down by half within 60 days of launch.
  3. Adoption. 80% of active inspectors on the new version in 30 days.
November cycle
02.1109.1116.1123.1130.1107.1214.1221.12
Build
Local storage and queue
Photo upload queue
Status and receipts
Test in basements
Cool-down
Beta with 30 inspectors
Launch

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

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.

Questions

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

A product brief is short and decides whether and how to build something: the problem, the goal and the rough shape. A PRD (product requirements document) is longer and lists detailed requirements. Many teams now write the brief and skip the full PRD.

How long should a product one pager be?

One page, readable in five minutes. If you need more than about 600 words, the problem is probably two problems, or the solution is described at screen level when it should be described as a shape.

What is appetite in Shape Up?

Appetite is how much time the problem is worth, set before the solution: for example, six weeks for one designer and two engineers. If the work does not fit, the team cuts scope rather than adding time.

Who writes the product brief?

Usually the product manager, with input from a designer and an engineer before it is reviewed. The owner and reviewers should be named at the top so comments go to the right person.

Read next

Turn your next note into a page

Write in Obsidian as you do now. The free plugin shows the note as a page with stats, tables and charts, and shares it as a link your team can edit in the browser; their edits come back to the note.