Capability template for product management
Smallest useful release scope
A product owner or founder with more features than capacity gets one page: what is in the first release and what is deferred, all tied to one user outcome, with the reason for each cut. The owner decides the scope; no effort is estimated beyond what is supplied.
Listed under
Add it to a workflow in the Fully Powered Planner, beside the teams and roles that will run it. Book a fit call
The outcome
The feature list stops being a wish list and becomes a first release with a purpose. You state one thing a user should be able to do when the release ships, and every feature is placed against it: in because the user cannot get there without it, or deferred with a stated reason and what the user does in the meantime. Where the capacity you supplied is exceeded, the page says by how much and what each possible removal would cost, and leaves the choice to you.
Who starts the work, and when
The product owner, or the founder who does that work, starts it when the list of wanted features is longer than the time available and a release has to be agreed. Engineering reads the result before the owner approves the scope, to confirm what can be built in what order.
What they supply
- One user outcome, written as what a named kind of user can do, and the measure that would show it happened.
- The steps the user takes to reach it, in order.
- The feature list, one row per feature, with the step it serves, what kind of feature it is, the effort engineering has given it, what it depends on, and what people do without it for now.
- The capacity for the release, in the same unit as the effort.
- Any limits engineering has stated, in the owner’s words.
What comes out
One page: the outcome and its path, the features in scope with the reason each is in, the features deferred with the reason each is out and what happens meanwhile, a capacity check from the supplied figures only, the questions the page cannot settle, what engineering is asked to confirm, and a line for the owner’s decision. Blank effort is shown as not supplied, never filled in.
An invented example
Illustrative example with invented data. The product, the founder, the features, the efforts and the limit below are all invented. Brindle Rota is an invented rota app for small cafés. First come the inputs the founder supplied, in full, then the page the capability returned.
The inputs
1. The brief
Product: Brindle Rota
Owner: the founder
Outcome: A café manager can publish next week's rota to the team and see
who has confirmed their shifts.
Measure: The share of published rotas that at least 80% of the staff on
them confirm within 48 hours. Counting it needs the time of each publish
and of each confirmation.
Path:
1. The manager signs in and opens the week.
2. The manager places staff in shifts.
3. The manager publishes the rota.
4. Staff see their shifts and confirm.
5. The manager sees who has confirmed.
Capacity: 40 person-days
Limits: Engineering says texting staff needs the text provider's sender
registration, which takes about a week to be approved.
Review date: 10 November 2026
2. The feature list (exported from the founder's planning sheet)
id,feature,step,kind,effort,depends_on,outward,workaround
F01,Manager email sign-in,1,access,3,,,
F02,Weekly rota grid,1;2,core,8,,,
F03,Staff list: add and edit people,2,core,4,,,
F04,Drag shifts between days,2,usability,5,F02,,Pick the day from a menu
F05,Publish the rota and text every person on it,3,core,6,F02;F03;F16,yes,
F06,Staff sign-in link: one per person,4,access,4,F03,,
F07,Staff view of own shifts with a confirm button,4,core,5,F05;F06,,
F08,Manager panel showing who has confirmed,5,core,3,F07,,
F09,Correct and republish a rota after it is published,,recovery,3,F05,,
F10,Shift swap requests between staff,,other,9,F07,,Staff message the manager who edits the rota
F11,Payroll hours export,,other,7,F05,,Manager copies hours into the payroll sheet
F12,Staff availability preferences,2,other,8,F03,,Staff tell the manager in the group chat
F13,Several cafés under one account,,other,12,F01;F03,,One account per café
F14,Dark mode,,usability,2,,,
F15,Record the time of each publish and each confirmation,,learning,2,F07,,
F16,Connect the text provider,,other,4,,,
The output
SMALLEST USEFUL RELEASE SCOPE: Brindle Rota
- For: The founder. Prepared 10 November 2026 from 16 features and the owner's brief. Capacity: 40 person-days.
- The outcome: A café manager can publish next week's rota to the team and see who has confirmed their shifts.
- The measure: The share of published rotas that at least 80% of the staff on them confirm within 48 hours. Counting it needs the time of each publish and of each confirmation.
- The path: 1. The manager signs in and opens the week. 2. The manager places staff in shifts. 3. The manager publishes the rota. 4. Staff see their shifts and confirm. 5. The manager sees who has confirmed.
In scope: 10 features, 42 person-days.
- F01 Manager email sign-in. Why in: access, needed to reach step 1. Step: 1. Effort: 3.
- F02 Weekly rota grid. Why in: on the path, steps 1 and 2. Step: 1; 2. Effort: 8.
- F03 Staff list: add and edit people. Why in: on the path, step 2. Step: 2. Effort: 4.
- F05 Publish the rota and text every person on it. Why in: on the path, step 3. Step: 3. Effort: 6.
- F06 Staff sign-in link: one per person. Why in: access, needed to reach step 4. Step: 4. Effort: 4.
- F07 Staff view of own shifts with a confirm button. Why in: on the path, step 4. Step: 4. Effort: 5.
- F08 Manager panel showing who has confirmed. Why in: on the path, step 5. Step: 5. Effort: 3.
- F09 Correct and republish a rota after it is published. Why in: recovery for F05, which reaches people outside the team. Step: none. Effort: 3.
- F15 Record the time of each publish and each confirmation. Why in: needed to count the measure. Step: none. Effort: 2.
- F16 Connect the text provider. Why in: pulled in by F05. Step: none. Effort: 4.
Deferred: 6 features, 43 person-days.
- F04 Drag shifts between days. Why deferred: makes step 2 easier or richer; the workaround is supplied. Until then: pick the day from a menu. Effort: 5.
- F10 Shift swap requests between staff. Why deferred: serves no step on the path. Until then: staff message the manager, who edits the rota. Effort: 9.
- F11 Payroll hours export. Why deferred: serves no step on the path. Until then: the manager copies hours into the payroll sheet. Effort: 7.
- F12 Staff availability preferences. Why deferred: makes step 2 easier or richer; the workaround is supplied. Until then: staff tell the manager in the group chat. Effort: 8.
- F13 Several cafés under one account. Why deferred: serves no step on the path. Until then: one account per café. Effort: 12.
- F14 Dark mode. Why deferred: serves no step on the path. Until then: none supplied. Effort: 2.
Capacity check: 42 person-days in scope against 40: over by 2.
Removable, serving no path step and not pulled in: F09 (3 person-days; without it the release has no way to correct and republish a rota after it is published) and F15 (2 person-days; without it the release has no record of publish and confirmation times for the measure). Removing F15 alone closes the gap exactly (42 − 2 = 40). Removing F09 alone closes it with 1 person-day to spare (42 − 3 = 39). The owner may also narrow a path step.
Needs the owner: 1.
- F16: it serves no step on the path and is in only because F05 depends on it. If the founder would rather deliver the rota another way, F05 changes; say which.
Engineering to confirm: the text provider's sender registration, about a week to be approved as the founder typed it, touches F05 and F16. The effort figures are the ones supplied and were not checked here.
Flags: F14 is deferred and no workaround was supplied.
Decision for the owner: Scope approved / changed / declined: ______ Any removal chosen: ______
Draft for the founder's decision. Effort figures are the ones supplied; none was estimated. Nothing has been changed, sent, scheduled or assigned.
Where it fits
- Product management, where the first release is the first test of what customers value.
- Software technology, where the list is always longer than the sprint.
- Consumer brands, when a brand launches its first app or digital service.
- E-commerce and retail, when a store feature has to ship before a season.
- Startups & new ventures, where the first release is most of the budget.
- New business lines, when an established company builds a first version of something new.
- Growth & scaling, when requests arrive faster than the team can ship them.
What has to change for your company
Decide the unit of effort and use it everywhere. Choose who is the owner and who in engineering confirms. Keep or change the six kinds of feature, and decide which are always in or never in for your product, such as sign-in or a way to undo. Set how the measure is stated. Add the limits your team always carries into a release, such as an approval an outside provider takes time to give. It runs in ChatGPT, Claude, Copilot or Gemini from the brief and the list you type or paste; it needs no connection to any system.
What has been checked
Fully Powered AI wrote this capability template in its own words. It was editorially reviewed on 10 November 2026. It was tried once on its invented example in Claude on 10 November 2026; the record is published with it, and lists the small edits made afterward that have not been run again. It has not been tested in a client environment or as a packaged version in ChatGPT, Claude, Copilot or Gemini.
Testing in your environment means running it on a release you shipped before, with the list as it stood then and cases written in advance: a feature with no effort, a feature that depends on one you would defer, two outcomes in one brief, a list over capacity. The owner and engineering check every placement against the list before anyone relies on it. Scope change impact review takes over once the scope is agreed and new work arrives, and Project scope baseline records an agreed scope for a project.
The full capability template
Everything above is the outline. The complete capability template is the working version: the roles, the inputs, the procedure, the exceptions and stop conditions, the output format, the reviewer checklist, the acceptance tests, the instructions for an AI assistant and what to customize for your company. It comes with a download and the link to its folder in Fully Powered’s public repository.
Free with an account. Sign in by email: no password and no card.
Next step
Put this capability to work for your team: on your plan, or built with you in a sprint.
Build this in a sprint
In a sprint, Fully Powered adapts this capability template to your rules, proves it on your own work and puts it in the hands of the roles that own it.
Two ways to begin: