Product & DesignFree
Product Feasibility and Scope Assessment
Every line of the estimate gets attached to the requirement that forces it, so the trade-off conversation starts from arithmetic instead of a single number.
River reads what engineering actually wrote instead of asking you to summarise it. The estimate, the design doc, the constraint notes and the thread where somebody said this part is hard all go in. Back comes a sheet that splits the estimate into work items and attaches each one to the requirement that forces it. Beside it sits a short document stating every constraint in product terms: what it rules out, what it makes expensive, and what it leaves alone.
An estimate handed over as one number can only be accepted or disputed, which is how these conversations turn adversarial. Google's site reliability engineering book states the underlying shape plainly: cost does not increase linearly as reliability increments, and an incremental improvement may cost a hundred times the previous one. Freshness, coverage and history behave the same way. The templates ranking for this query offer a scoring grid with columns for effort and impact, and no method for filling either column in.
Built for the product manager holding a date and an estimate that disagree, and for the engineering manager who is tired of being heard as obstructive. Reach for it once the spec exists and before anyone commits to the date. The spec it prices is the PRD template, the constraints become stories with acceptance criteria downstream, and the account numbers on the impact side come out of feedback triage, which is where the request counts already live.
Why one number cannot be negotiated
Fennick sells warehouse software, and sixty-six accounts asked for stock levels that match their ERP. Engineering came back with twenty-three engineer-weeks, which is eleven and a half calendar weeks for the two people available. Splitting that estimate into six work items and attaching each to the requirement behind it changes the conversation immediately. Write-back is six engineer-weeks, twenty-six percent of the whole build, and twelve of the sixty-six accounts asked for it. Nothing about that is visible in the phrase eleven weeks.
The sharper finding sits in the freshness requirement. Fifty-three of those accounts run a vendor-hosted ERP that can push a change event, and thirteen run one on their own infrastructure with no inbound path, so the only way to see a change is to ask. Meeting a sixty-second target across both groups costs three engineer-weeks for the fifty-three and four and a half for the thirteen. That is six times the engineering per account, spent on a target only four of the thirteen actually need.
Eleven and a half calendar weeks assumes two engineers stay on it and nothing serialises, which is the optimistic reading of a number that was already optimistic. Flyvbjerg's work on reference class forecasting attributes forecast error to optimism bias and strategic misrepresentation, and both are present in a room where a date is already public. So the brief states the assumption in the same sentence as the number, and reports the option that fits the date as fitting by one working day rather than as fitting.
How it works
Hand over the estimate
The engineering estimate, the design doc, the constraint notes, and whatever the spec currently says.
Split and attribute
Each work item priced, and traced to the requirement that would disappear if the item did.
Translate the constraints
Each technical constraint restated as what it rules out, what it makes expensive, and what it leaves alone.
Price the options
Scope options compared on effort, calendar weeks and accounts served, with the assumption behind each date.
What you get
- Every work item in the estimate attached to the requirement that forces it to exist
- Each requirement priced as a share of the estimate and set against the accounts wanting it
- Scope options with effort in engineer-weeks, calendar weeks under a stated assumption, and accounts served
- The cost per account of each cut, so the cheapest thing to drop is arithmetic
- Constraints restated in product terms: what is ruled out, what is expensive, what is untouched
- The work nobody asked for, flagged separately from the work customers named in writing
Common questions
Does this second-guess the engineering estimate?
No. It takes the numbers engineering gave and rearranges them, so nothing is re-estimated and no number is disputed. What changes is that each figure now sits next to the requirement that produced it. Engineers usually welcome that, because it moves the argument off whether the estimate is right and onto whether the requirement is worth it.
What if engineering only gave me one number?
Then the first output is the split it would take to produce, written as a proposal rather than an assertion, with the work items it expects and a question against each. Handing that back is a faster way to get a breakdown than asking for one, because correcting a wrong list is easier than writing a list from nothing. For an integration, start from its failure cases instead.
Where do the account numbers come from?
From whatever you paste in: the requests, the deal notes, the renewal risks. If you have none, the impact column stays empty and says so rather than filling itself with a guess. An empty impact column is a finding, because it means a date is being defended without anybody knowing who is behind the requirement. Where the requests are still a pile, reduce them to needs and requesters first.
Will it tell me which option to pick?
It recommends one and shows the arithmetic, which matters more. Cutting the two-year backfill strands two accounts and saves two and a half engineer-weeks. Cutting write-back strands twelve to save six. The backfill buys more time per account stranded, which is the reverse of the order most teams cut in.
Is this just a RICE or WSJF score?
No. Those score a list of candidate items against each other. This decomposes one committed item into the parts that carry its cost, which is a different operation and happens later. Use a prioritisation framework to decide whether to build the thing, and this to decide what shape of the thing you can afford.
What about the work nobody asked for?
It gets flagged, not cut. In the worked example, per-warehouse sync status is two engineer-weeks and no account named it, because customers do not request observability until after the first silent failure. The brief marks items like that as unrequested and says who will need them, which is usually support in week one.
Can I use this to push back on a date?
That is the point, though not by arguing. The brief converts a date argument into a scope choice with a price on each option, and hands the choice to whoever owns the date. In the worked example the question stops being whether nine weeks is realistic and becomes whether twelve accounts justify three calendar weeks of the quarter's capacity.
Product Feasibility and Scope Assessment
Fill in the form and your workspace opens with the work already underway.