Templates · Product
Feature brief template
Short brief aligning team on a feature before design
Start with this template →Sign in
Opens on reph with the template ready to start. No account needed; sign in to keep your document.
Filled example
The template filled in for a made-up company, so you can see what good looks like.
Bulk edit for inventory items
Author: Jonas Weber · Date: 2026-09-22
Summary
Let Shelfwise users change price, category or reorder level on many items at once. Today every change is one item at a time, and our largest customers are leaving the app for spreadsheets to do it.
Customer problem
Shop managers with more than 500 SKUs run seasonal price changes several times a quarter. They export to CSV, edit in a spreadsheet and re-import, which breaks whenever a column is renamed. Import errors are now our third largest ticket category.
"Every January I spend a full Saturday re-pricing 1,200 items. One bad import last year zeroed our stock counts." (support ticket 48213, Copperleaf Outfitters)
Related tickets per month
86
▲ +18%
Proposed experience
From the item list, a manager selects items with checkboxes or a filter ("all items in Winter Jackets"), picks Edit selected, chooses a field and an operation (set to, increase by %, decrease by amount) and sees a preview of old and new values before confirming. Every bulk change can be undone for 24 hours.
Scope
In
- Bulk edit of price, category, reorder level and supplier
- Preview before apply, and a 24 hour undo
- Up to 5,000 items per operation
Out
- Bulk edit of stock counts (needs an audit trail design first)
- Scheduled changes ("apply on January 1")
- Mobile app support in the first release
Success metrics
| Metric |
Baseline |
Target |
| CSV import tickets per month |
86 |
Under 30 within one quarter |
| Accounts over 500 SKUs using bulk edit monthly |
0% |
60% |
Open questions
Timeline
| Milestone |
Rough date |
| Design review |
2026-10-06 |
| Dev start |
2026-10-20 |
| Target ship |
Late November, ahead of the January re-pricing season |
The template
Show the blank template
Feature brief
Author: [your name] · Date: [date]
Summary
Two or three sentences: what this feature is and why it's worth a design pass.
Customer problem
The evidence, not the theory: a support quote, a session recording note, a metric. If you're guessing, say so.
"Quote from a customer or support ticket" (source)
Related tickets per month
0
▲ +0%
Proposed experience
The shape of the solution at a level design can react to, not prescribe. Sketches or a rough flow are fine here; polish comes later.
Scope
In
- What this brief commits to
Out
- What's explicitly deferred: the thing everyone will otherwise assume is included
Success metrics
The number that tells you this was worth building, with a baseline and a target.
Open questions
Timeline
Rough milestones (design review, dev start, target ship), enough to plan around, not a committed date.
| Milestone |
Rough date |
| Design review |
|
| Dev start |
|
| Target ship |
|
Questions
- How long should a brief be?
- One page. If it needs more, it is ready to become a PRD
- Should it include designs?
- Rough sketches or a flow at most, so design can still shape the solution
- Who reads it?
- The PM, designer and tech lead who will decide whether it gets a design pass
Fill it with your agent
Connect Claude to reph over MCP, then paste this. The draft arrives as suggestions you accept or reject section by section. How to connect Claude.
Find my reph doc "Feature brief" with search_docs, then read it with read_doc. Draft summary, customer problem and success metric from the support tickets, interview notes and usage dashboards linked in the doc, quoting customers verbatim with source. Scope only what evidence supports; put deferred items under Out. File it with suggest_edit, one replace_section op per section (heading line kept) so each can be accepted alone. Ask each open question (claims with no evidence yet) with add_comment quoting that section's heading line, then call request_review with a one-line summary.
Related templates
PRD / requirements doc
Problem, users, requirements, success metrics and scope for a feature
Product managerEngineerDesignerExperiment (A/B) plan
Hypothesis, variants, metrics, sample size and decision rule
Product managerResearcherEngineerLaunch checklist
Everything to ship a feature: eng, docs, support, marketing
Product managerManagerRelease notes
What shipped, what changed, and how to upgrade
EngineerTech leadProduct managerCustomer product newsletter
Release highlights, a how-to and one call to action for your customers
Product managerMarketerFounderCustomer successAnalytics request
Brief for a data or analytics request: the decision it informs, the exact question, metric definitions, segments, timeframe, sources, due date and output format
Product managerResearcherMarketerExecutiveOperationsAnyoneStart with this template →Sign in