Product & DesignFree
Product Portfolio and Effort Review
Your strategy deck allocated 100% of engineering across four pillars. The delivery history says 317 of 624 engineer-weeks went somewhere those four do not describe.
River's portfolio review reads the delivery history rather than the planning deck. Closed issues, epics, labels, teams and dates go in. What comes back is effort in engineer-weeks against each strategic pillar, next to the allocation the strategy promised, plus the categories the strategy never named. In the worked review, four pillars that were supposed to absorb 100% of a 624 engineer-week half-year absorbed 307 of it. The other 317 went to operational load, one-off customer commitments and work nobody tagged at all.
Counting tickets instead of effort produces the opposite answer, which is why most allocation charts are wrong in a consistent direction. The Kanban Guide is precise about what a count is: throughput is "the exact count of work items finished per unit of time". An escalation ticket and a quarter-long platform migration are both one item. In the worked review the median escalation took 0.12 engineer-weeks and the median enterprise-readiness item took 0.56, so counting rows understates the strategic pillars by roughly a factor of three and inflates the interrupt queue to half the company.
Built for the product or engineering leader who has to explain a year of delivery to a board that remembers the strategy deck, and for the quarter where somebody proposes moving headcount between teams. Run it before the quarterly planning cycle, which needs the measured interrupt figure this produces rather than the one everybody assumes, and before the roadmap pack commits the next set of dates. What survives the cut then gets ranked with the prioritization pack.
The largest line item is the one with no name
Every portfolio chart in circulation is a plan. It was drawn at the start of the period, it sums to 100%, and each slice belongs to a pillar somebody can defend. The delivery history does not sum to those slices. The difference concentrates in three categories no strategy document has a row for: operational load arriving through support, one-off commitments made to individual accounts, and work with no initiative tag at all. In the worked review those three came to 174, 88 and 55 engineer-weeks. The entire new-markets pillar came to 22.
Operational load is the one with a published benchmark, so it is the one worth measuring first. Google's SRE organisation runs an explicit cap: toil below 50% of each engineer's time, with quarterly surveys putting the actual average around 33%. The number matters less than the fact that it is measured at all. A team carrying 79% unplanned work against an organisation that thinks it is carrying 20% is not underperforming, and no amount of planning discipline will fix a gap that nobody has counted.
The customer-commitment slice is the one that changes behaviour fastest, because it has names on it. Eighty-eight engineer-weeks across eleven accounts is four times the entire new-markets pillar, and every one of those commitments was individually reasonable at the moment it was made. They are only visible in aggregate, which is exactly what a portfolio review is for. The untagged slice is smaller and more embarrassing: 590 closed issues, 55 engineer-weeks, and no way to say what any of it was for.
How it works
Send the delivery history
Any export with issues, epics, labels, teams and dates. Jira, Linear, GitHub, Azure DevOps or a warehouse query.
Name the pillars
Whatever the strategy said, in whatever form it said it. Percentages, priorities or a ranked list all work.
Convert to engineer-weeks
Every item is attributed and costed, with the conversion stated so anyone can check it against their own view.
Read the gap
Planned against actual per pillar and per team, with the unnamed categories sized next to the named ones.
What you get
- Effort per strategic pillar in engineer-weeks, not ticket counts or story points
- Planned against actual for every pillar, with the gap stated in weeks rather than percentage points
- The three unnamed categories broken out: operational load, one-off customer commitments, untagged work
- Allocation per team, which is where a single consumed team hides inside a healthy average
- The same chart drawn twice, once by ticket count and once by effort, because they disagree
- A sheet holding every attribution and conversion, so a disputed slice is read rather than rerun
Common questions
Why engineer-weeks instead of story points or ticket counts?
Because a portfolio question is a capacity question and only one of those three is a capacity unit. Points are not comparable across teams and were never meant to be. Counts treat a two-hour escalation and a quarter-long migration as equal, which in the worked review inflated the interrupt queue to nearly half the company.
Our tickets are not tagged to initiatives. Can it still work?
Yes, and the untagged share becomes a finding rather than a blocker. Items are attributed from epic links, labels, components, repository paths, assignee team and the issue text itself. Whatever cannot be attributed with confidence is reported as untagged with its engineer-week cost attached, because that number is worth knowing.
How does it convert issues into engineer-weeks?
From active time between status transitions, the number of distinct assignees, and the team's headcount over the period, calibrated so the total reconciles to the actual engineer-weeks available. The method and the reconciliation are both written into the sheet, so a leader who disputes one slice can check the arithmetic instead of relitigating the conclusion.
Is a large operational-load slice automatically bad?
No. Google's SRE teams treat operational work as expected and cap it rather than eliminating it, running a stated ceiling with measured averages beneath it. The problem in the worked review is not that operational load was 27.9%. It is that the organisation believed it was near zero, and the Platform team was carrying 79%.
What if the strategy never had percentages in it?
Most do not, and that is fine. A ranked list of pillars is enough to test whether delivery matched the order. Where a strategy names four priorities and the fourth received four times the effort of the first, the ranking alone settles the question without anybody having to defend a number they never wrote down.
Can it show allocation per team as well as per pillar?
Yes, and that view usually carries the real finding. A company average of 50.8% unplanned looked survivable in the worked review until the per-team split showed one team at 79% and another at 37%. Averages hide a consumed team, and a consumed team is a headcount decision rather than a planning one.
How often should this run?
Twice a year, or once before any planning cycle that reallocates headcount. It pairs directly with the quarterly planning pack, which needs a measured interrupt figure rather than an assumed one, and the measurement is only worth taking if the previous one is far enough back to have moved.
Product Portfolio and Effort Review
Fill in the form and your workspace opens with the work already underway.