Capability template for product management
Roadmap tradeoff review
When a new priority arrives, the product owner sees what the roadmap would have to give up to hold it: the capacity gap by team, the work that could move, the commitments and dependencies that move with it, and the questions still open. The owner decides.
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
Someone asks for something new, and the answer stops being a feeling. The product owner has one page that says how much each team can take on, how much the request needs, how far short the plan falls, and which planned items could make room under rules written down in advance.
Nothing is hidden in the move. The page lists the commitments the displaced work carries, the later items that depend on it, and the dependencies of the request itself that nobody owns yet. It gives no date to anyone. The product owner takes it into the conversation with the person who asked, and into the one with the teams.
Who starts the work, and when
The product owner starts it when a request, a customer need or a new dependency would add work to a planning window that is already full, and before anyone is told yes. A product manager or a founder who holds the product role can run it the same way. It is not for a milestone that has already slipped, which is Schedule recovery options, nor for scoring a new initiative by role and month for a portfolio owner, which is Project intake and capacity review.
What they supply
- The roadmap export: each item with its team, status, window, remaining effort, dependencies, goal and any commitment attached.
- Each team's capacity for the window.
- The company's goals in rank order.
- The request: who asked, the goal it serves, each team's effort estimate and the dependencies it brings.
- A few settings, such as whether committed or started work may be offered.
What comes out
One page in a fixed order. It states the request and its effort by team, the capacity position of each team, a proposed set of displaced items with an alternative where one exists, the items that are not offered and why, the commitments touched, the dependencies left unresolved, a check against the goals, and the open questions with who can answer each. Displaced work gets no new date. It ends with the decision for the product owner.
An invented example
Illustrative example with invented data. An invented 30-person software company, Company X, is asked for single sign-on in the middle of its first quarter. Every name, item and figure below is made up. Effort is in person-weeks (pw).
What the product owner supplies
The request, as typed by the product owner
- Request: Single sign-on for business accounts. Asked by: Head of Sales. Serves goal: G2. Date the asker stated: none.
- Estimates: Platform team 6 pw; Web team 3 pw. Estimates from the Platform lead and the Web lead.
Dependencies the request brings (Dependency, Owner, Effort (pw), Needed By Team)
Security review of login changes,,,Platform
Identity provider test account,IT lead,0.5,Platform
Goals (Goal, Rank, Statement)
G1,1,Keep existing customers
G2,2,Win larger accounts
G3,3,Make first use easier
G4,4,Grow through referrals
Capacity for window Q1 (Team, Window, Capacity (pw))
Platform,Q1,45
Web,Q1,22
Roadmap export (ID, Item, Team, Status, Window, Effort Remaining (pw), Depends On, Goal, Committed To, Owner)
R1,Billing export v2,Platform,Planned,Q1,14,,G1,Customer A pilot,Platform lead
R2,Audit log,Platform,In progress,Q1,8,,G2,,Platform lead
R3,Referral API,Platform,Planned,Q1,9,,G4,,Platform lead
R4,Mobile onboarding refresh,Web,Planned,Q1,10,,G3,,Web lead
R5,Referral dashboard,Web,Planned,Q2,8,R3,G4,,Web lead
R6,Referral landing page,Web,Planned,Q1,4,,G4,,Web lead
R7,Team invite flow,Web,In progress,Q1,5,,G3,,Web lead
R8,Data retention settings,Platform,Planned,Q1,7,,G1,Customer B renewal,Platform lead
R9,Webhook retries,Platform,Planned,Q1,5,,G3,,Platform lead
R11,Public status page,Platform,Idea,Q1,6,,G3,,Platform lead
Settings: Product owner; goals ranking owned by the Head of Product; window Q1; date of the run 2 November 2026; roadmap export dated 2 November 2026; committed items may not be offered; started items may not be offered; margin to keep free: 0 pw.
What comes out
ROADMAP TRADEOFF REVIEW: Single sign-on for business accounts
For: Product owner. Window: Q1. Prepared 2 November 2026 from the roadmap export of 2 November 2026.
The request: Single sign-on for business accounts, asked by Head of Sales, serves G2 (Win larger accounts, rank 2). Effort by team: Platform 6 pw, Web 3 pw. Date the asker stated: none supplied. Left out of the figures: security review of login changes (effort not supplied); identity provider test account, 0.5 pw (IT lead, no capacity row).
Capacity by team (pw):
- Platform: capacity 45, committed 43 (R1 14, R2 8, R3 9, R8 7, R9 5), free 2, request 6, gap 4.
- Web: capacity 22, committed 19 (R4 10, R6 4, R7 5), free 3, request 3, gap 0. No margin left.
Proposed revision:
- Platform: displace R3 Referral API (9 pw, goal G4, rank 4). Covers the gap of 4 and frees 5 pw more. No new date is assigned; it needs its own decision.
- Web: none needed.
Alternatives that also cover the gap: Platform: R9 Webhook retries (5 pw, goal G3, rank 3), leaving 1 pw to spare.
Not offered (teams with a gap only): R1 (commitment: Customer A pilot); R8 (commitment: Customer B renewal); R2 (in progress). Not counted (Idea, Done, Cancelled or other window): R11 (status Idea); R5 (window Q2).
After the change (pw): Platform committed 40 of 45, free 5. Web committed 22 of 22, free 0. With the alternative instead: Platform committed 44 of 45, free 1.
Commitments touched: None. R3 and R9 carry no Committed To entry.
Dependencies unresolved:
- R5 Referral dashboard (Web, Q2, 8 pw, Web lead) depends on R3, which the proposal displaces. The alternative leaves R5 intact.
- Security review of login changes (needed by team: Platform): no owner and no effort supplied.
- Identity provider test account (IT lead, 0.5 pw): the IT lead has no capacity row.
Goal check: The request serves G2 (rank 2); the proposed displaced item serves G4 (rank 4). G4 still has R6 in Q1. Goals left with no item in the window: None.
Not known:
1. Who owns the security review of login changes, and how many pw it takes. Who can answer: Product owner.
2. Whether the IT lead can give 0.5 pw to the test account in Q1. Who can answer: IT lead.
3. Whether R5 keeps its Q2 window if R3 moves. Who can answer: Web lead.
Decision for Product owner: choose the proposal, an alternative, neither, or a smaller request, and set any new date for displaced work. Teams confirm their own estimates. Nothing is changed in the tracker, promised to anyone or sent.
How each figure comes from the inputs: Platform committed is 14 + 8 + 9 + 7 + 5 = 43 (R11 is an idea and R5 is in Q2, so neither counts and both are listed under Not counted); free is 45 − 43 = 2; the gap is 6 − 2 = 4. Web committed is 10 + 4 + 5 = 19; free is 22 − 19 = 3; the gap is 3 − 3 = 0, with free exactly equal to the request, so no margin is left. After the proposal Platform is 43 − 9 + 6 = 40. With the alternative it is 43 − 5 + 6 = 44. Web after is 19 + 3 = 22.
Where it fits
- Product management, where every yes to a request is a no to something already planned.
- Software and technology, where a customer deal or a platform need arrives mid-quarter.
- Hardware and physical technology, where a new priority competes with long-lead work that cannot simply be swapped.
- Consumer brands, where product changes pile onto a fixed launch calendar.
- Growth & scaling, when requests arrive faster than the plan can absorb them.
- Startups & new ventures, where one new priority can displace a third of the quarter.
What has to change for your company
Decide your planning window and your unit of effort. Set whether committed items and items already started may ever be offered, and the margin each team keeps free. Agree who ranks the goals and how often. Map your tracker's column names to the defaults in the template, or rename the columns in the export. Decide who may see the page before the product owner has decided.
What has been checked
Fully Powered AI wrote this capability template. It was editorially reviewed on 10 November 2026. It has not yet been tested in a client environment. It was tried once on its invented example in Claude on 10 November 2026; the record of that run is published with it, and lists the ambiguities it met.
Testing in your environment means running it on a past request whose outcome you already know, with the capacity and ranking as they stood then. The product owner checks every figure against the tracker and the capacity sheet before anyone relies on it. Decision log keeps the record once the owner has decided.
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: