The six sessions 🎯 · before a single screen is designed
The running situation is Ferry, a tool a Sunday-league football club wants so that eleven players are confirmed by Thursday night. Twelve features get proposed. Four of them serve no stated outcome at all, one of them duplicates something the cheapest feature already did, and the order they get built in turns out to matter more than the list.
The job, not the feature
"We need an app" is an answer wearing the costume of a problem. What somebody is actually trying to get done, who they are, and what they do today instead. The problem statement that every design course starts from, and nobody teaches you to write.
📣 Session 2 · easyWhat people ask for is not what they need
A request is evidence about a problem, not a specification for a solution. How to take a feature request seriously without building it, and why the loudest thing on the list is so often the one that serves nothing.
✂️ Session 3 · bench nightThe cut bench
One job, twelve features, and five ways to cut. You cut; the bench computes how much of the job still gets served, how many weeks are left, and the week anybody can first use the thing. One cut ships fastest and serves nobody.
🔢 Session 4 · easyOrder is a product decision
The same list, built in a different order, is a different product for twenty-eight weeks. First usable against finally finished, why a thing that works badly in week five beats a thing that works well in week thirty-three, and what that costs you.
🙅 Session 5 · mediumSaying no so it lands
Most product decisions are declines, and a decline that leaves somebody feeling dismissed costs more than the feature would have. How to say no to the thing, out loud, while saying yes to the person and the problem underneath it.
📄 Session 6 · mediumYour product on one page
The note that makes everything else usable by somebody who was not in the room: the job, who it is for, what is in, what is deliberately out, and how you will know. Final scorecard, and the door into designing the thing.
Your passport 🎫
Clear all three quiz questions in a session and it gets stamped. Six stamps means you can take "we need an app" and turn it into something worth building, in an order that works. Stamps live in this browser only.
What this is not, so you land in the right place 🧭
| If your question is | Go here instead |
|---|---|
| I have a problem statement. How do I design the actual screen? | Product Design & UI/UX ↗ |
| Which architecture should this be built on, and what does each choice cost? | System Design & Orchestration ↗ |
| How do I review a data product that already exists? | Data Product Heuristics ↗ |
| Where does the data actually go once somebody clicks the button? | Data Pipelines ↗ |
| How do I tell whether the change I shipped worked? | Experimentation ↗ |
| Somebody wants a thing built. What is it for, what goes in, and what do I cut? | you are in the right place |
This is the door into the system and product design shelf. It designs nothing and builds nothing. Everything here happens before the first screen exists, and every session ends by naming which course to take when you want the next step.
Choose your path 🗺️
Three doors into the same conviction: most of what gets built did not need to be, and the way to find out is cheaper than building it.
What is honest here 🧾
The bench in session 3 computes every number from its own feature list. The product behind it is invented, and the pages say so on every screen that quotes a figure.
| Claim | Status |
|---|---|
| Every figure in the cut table | Really computed from a feature-to-outcome graph: real weighted coverage, a real build-order walk, a real threshold |
| Ferry, the football club tool | Invented. Written so the five cuts behave differently from each other, not observed in the wild. Every number describes this backlog only |
| Which outcomes are core, and what each is worth | A judgement, shown rather than hidden. The bench makes the weights visible so you can disagree with them |
| What each feature would cost to build | Stipulated. Estimating build cost is a real skill and this is not the course for it |
| That order can be worth more than scope | Demonstrated here, not measured in the world. The bench shows the mechanism working; how often it bites in practice is a separate question |
| How much software gets built and never used | Stated only where a source could be read, with the tier shown. Session 2 takes the most-quoted figure apart rather than repeating it |
| The verdict line on the bench | A heuristic, badged as one on the widget |
The knowledge map 🧠
The whole course at a glance - hover a session to spotlight its concepts, click any node to jump in.