Where we start
Session 1 turned a request into a job. Session 2 turned a pile of requests into a set of problems. Tonight those meet a backlog, and the backlog loses. The point is not that cutting is virtuous. It is that a cut is a decision with consequences you can compute rather than argue about, and once the consequences are on screen the argument usually ends in about four minutes.
★ What you walk out with tonight. A feel for what a cut buys and what it costs, one cut made on your own list with the tradeoff written down, and the specific knowledge that "ships soonest" and "usable soonest" are different things that can point in opposite directions.
One job, eight outcomes, twelve features
6 min liveThe club from session 1 got as far as a job. Then twelve things went on a list, the way twelve things always do.
LiveWhat the bench measures, and why those three numbers4 min▶
Job served. How much of the stated job the selection covers, weighted by how much each outcome matters. This is the number people think they are arguing about.
Weeks to build. The whole selection, added up. This is the number finance thinks it is arguing about.
Weeks to usable. The week the core outcomes are first all met, walking the build in the order the selection is actually built in. This is the number that decides whether the thing helps anybody this season, and almost nobody computes it.
There is a fourth, which is the count of selected features that serve no stated outcome at all. It is not a judgement about whether those features are nice. It is an observation that nothing anybody wrote down gets better when they exist.
One rule makes the whole thing work: an outcome is met to the best degree any single feature delivers it. Two features that both cover the same outcome do not add up. That is not a simplification, it is the thing most backlogs get wrong.
Self-studyWhere the weights came from, and why they are visible3 min▶
Which outcomes count as core, and how much each is worth, is a judgement. It is the club's judgement, arrived at by the organiser saying what Saturday actually requires, and it is the single most contestable thing on the bench.
That is why it is on screen rather than buried. A tool that hides its weights produces answers that feel objective and are not. A tool that shows them lets you disagree with the right thing: if you think collecting match fees is core, change it, and watch every conclusion move. The arithmetic is not the opinion. The weights are, and they should be argued about openly before anybody argues about the features.
The same is true of the build costs. They are stipulated numbers, not estimates anybody produced. Estimating build cost honestly is a real and difficult skill, and it is a different subject.
Five cuts, computed in front of you
★ 26 min · the main eventWork down the presets in order and read the four numbers each time before reading the verdict. Then cut it yourself with the checkboxes at the bottom.
Read it in this order. Job served, then weeks to build, then weeks to usable. The first two behave the way everybody expects. The third is where the surprises live, because it is the only one that depends on what you build first rather than on what you build.
What each cut actually bought
6 min liveEvery figure below came off the bench you just used. Nothing here is asserted; it is all computed from the twelve features and the eight outcomes.
| The cut | Job served | Weeks | Usable in | What it bought |
|---|---|---|---|---|
| Everything, loudest first | 96.7% | 34 | week 33 | Everything, eventually. The club gets through an entire season first |
| Everything, job first | 96.7% | 34 | week 5 | Nothing was cut at all, and the club has a working tool 28 weeks earlier |
| Cut to the job | 76.7% | 8 | week 5 | 26 weeks of work, for a fifth of the stated job, none of it core |
| Cut harder | 51.3% | 4 | never | The fastest build on the board, and a tool nobody can use |
| Cut to the job, plus native apps | 76.7% | 16 | week 5 | Nothing. Eight weeks, and not one number moved |
LiveThe row that ships fastest and fails3 min▶
"Cut harder" keeps the two features nobody could argue with: the yes/no link and the organiser's count screen. Four weeks of work, the shortest build on the board, and every instinct says it is the disciplined choice.
Core coverage lands at 77% against a bar of 85%, so weeks-to-usable comes back as never. What got cut was the one-week nudge to whoever has not answered, and without it the organiser can see that six people have replied and still has no way to chase the other fourteen except by going back to sending individual messages, which is the exact thing he asked for help with.
This is the honest shape of cutting: it has a floor, the floor is set by the job rather than by your appetite for discipline, and going below it produces something that ships sooner and helps nobody. A four-week build that nobody can use is worse than no build, because it also spent four weeks.
LiveEight weeks, and not one number moved3 min▶
Native iPhone and Android apps are the feature everybody assumes a real product has. On the bench they cost eight weeks, which is double the entire "cut to the job" build, and they move job served by exactly zero. Weeks to usable does not move either.
The reason is not that phone apps are bad. It is that the outcome they serve, "all of this works on a phone, standing up, outdoors", was already met by the two-week text-message link. The second feature covering the same outcome adds nothing, because an outcome that is met is met.
That is the general shape of the most expensive mistakes in product work, and it is almost invisible without the graph in front of you: the feature is not useless, it is redundant, and redundancy is much harder to argue against than uselessness because everybody can see what the feature does. The question that finds it is not "is this good?" but "which outcome does this serve, and is anything already serving it?"
Self-studyThe cheapest cut on the board, which nobody proposes2 min▶
Four of the twelve features serve no stated outcome at all: team chat, admin roles, the spreadsheet export and dark mode. Together they are seven weeks.
Drop all four from the full build and it goes from 34 weeks to 27, with job served unchanged at 96.7%. Seven weeks, for nothing given up against anything anybody wrote down.
It is worth asking why this cut is rarely the one proposed. Partly because those features are individually cheap and each one looks like a rounding error. Partly because two of them are among the most-requested things on the list, and volume feels like evidence. And partly because "serves no stated outcome" is only visible if somebody wrote the outcomes down first, which is what sessions 1 and 2 were for.
Four questions that do the same work on paper
4 min liveYou will not have an engine in the room. These four questions get most of the way there, and they are all askable in a meeting without sounding like an obstacle.
Which outcome does this serve? Not "why is it good" - which specific written-down outcome gets better. An item with no answer is not necessarily cut, but it is now visible, which is most of the work.
Is anything already serving that outcome? This is the redundancy question, and it is the one that finds the eight-week feature that moves nothing. Ask it before the item goes on the list, not after it is half built.
Is that outcome core? Meaning: if this outcome is not met, is the thing usable at all? Core and non-core are a different question from important and unimportant, and conflating them is how the floor gets breached.
In what week does this order first produce something usable? Walk the list top to bottom, adding up the weeks, and stop at the point every core outcome is met. That week is the number to take into the room.
Before session 4
25 min- Run the four questions down your own backlog. Write the outcome next to each item, and put a mark against every item where you cannot name one.
- Find your redundant feature. Most lists have one: two items serving the same outcome, where the cheaper one was already enough. Note what it would cost to build both.
- Work out your floor. Which items must exist before anybody can use the thing at all? That set is your "cut harder" line, and going under it is the failure in tonight's fourth row.
- Write down the week. In your current order, when does something usable first exist? Bring that number to session 4, because session 4 is about what happens to it when you change nothing but the order.
Three questions
Clear all three and session 3 gets stamped in your passport.
1 · On the bench, "cut harder" produced the shortest build of any option, four weeks, and reported weeks-to-usable as "never". Why?
Cutting has a floor and the job sets it, not your appetite for discipline. A build that ships fastest and leaves a core outcome unmet has spent the weeks and bought nothing, which is strictly worse than not starting.
2 · Adding native phone apps cost eight weeks and moved job served by exactly zero. What is the generalisable lesson?
The question that catches it is not "is this good?" but "which outcome does this serve, and is anything already serving it?" An outcome that is met is met, and a second feature covering it adds nothing however good it is.
3 · Someone objects that the bench's conclusions depend entirely on which outcomes were marked core and how they were weighted. Are they right?
The arithmetic is not the opinion; the weights are. A tool that hides them produces answers that feel objective and are not. Showing them lets the disagreement land on the right thing, and D overcorrects: a model whose assumptions are visible and contestable is more useful than one whose assumptions are invisible.
What this session teaches, and where it came from
Every fact on this page, and its verification tier, is recorded in the course's source map.
Session 3 cheat sheet · pin this
Look again at the first two rows of tonight's table. The same twelve features, the same thirty-four weeks, the same job coverage at the end, and a working tool in week five rather than week thirty-three. Nothing was cut to get that. Session 4 is about the only thing that changed, which is the order, and about what it actually costs to ship the early version rather than the finished one. Bring a plan of your own with more than five things on it.