Where we start
The football club organiser has a job written down, a pile of requests grouped by the problem underneath them, a cut list that goes from twelve features to a handful, a build order that puts the first usable thing in week 5 rather than week 33, and four conversations where he said no without making an enemy. None of that is written anywhere. In three weeks a volunteer offers to help, asks what they are building, and gets a forty-minute verbal answer that contradicts itself twice.
★ What you walk out with tonight. One page, written by you, about something real: the job, who it is for, what is in and in what order, what is deliberately out with a reason next to each, and how you will know it worked. Plus a score out of twelve telling you which of the five earlier ideas your page has actually absorbed and which one it has skipped.
Five blocks, and one of them is the reason to bother
7 min liveThe page is short on purpose. It is not a specification, it is not a business case, and nobody has to read it twice. It exists so that the thinking already done stops depending on you being in the room.
LiveWhy "deliberately out" is the block that matters4 min▶
A list of what you are building is a plan. Anybody can write one, and plenty of people do. It answers the question you get asked once, at the start, by somebody who is already on board.
A list of what you decided not to build, with the reason attached to each line, answers the question you get asked every month, by a different person each time, usually the one who joined last week. Without it you re-litigate the same four decisions forever, and each re-run costs you the same conversation plus the credibility of having apparently changed your mind.
The football club's out-list has one line on it that does all the work. Native phone apps, for iPhone and Android, the thing absolutely everybody expected to be in there. Session 3 measured what they cost: 8 weeks of build, and the job-served figure moved by exactly 0, because the text-message link already met the same outcome. That line, written down with its reason, ends the conversation the first time somebody reopens it. Without it, the note just looks like somebody forgot the apps.
Self-studyHow long each block should be, and what to cut3 min▶
One page means one page. The discipline is not aesthetic, it is that a two-page note gets skimmed and a five-page note gets filed, and a filed note does nothing at all. If a block will not fit, the usual reason is that it is carrying two things.
The job block is one sentence per line, four lines. If it needs a paragraph you have either not found the job yet or you are describing more than one.
The in-order block is a list, not prose. Feature, week it lands, and nothing else. Any justification you feel the need to add belongs in the out block next to the thing it is being chosen over.
The out block is allowed to be the longest. It is the only block that grows over time, because every no you say afterwards gets added to it. Two columns work well: the thing, and what would move it in.
What to cut first: adjectives, background, and any sentence that begins with "as we all know". Anything that is true of every project is not information about yours.
Useful in six months, not merely tidy today
5 min liveMost notes are written to be agreed with. The useful ones are written so they can turn out to be wrong, because a note that cannot be wrong is a note nobody can ever check.
Self-studyDated, reasoned, and therefore falsifiable3 min▶
Three habits turn a tidy note into a useful one, and they are all about making it possible to find out later that you were wrong.
Put a date on it. Not for the filing. A dated note tells a reader how much the world has moved since, which is the single most important thing they need in order to decide whether to trust it. An undated note is either eternal truth or stale rubbish, and the reader cannot tell which.
Attach the reason, not just the outcome. "No native apps" is a conclusion. "No native apps, because the text-message link already meets the same outcome and the apps cost 8 weeks for 0 movement" is a decision. The difference is that the second one has a moving part in it, and moving parts can be watched.
Next to anything in the out block, write what would move it in. This is the habit that pays for the whole page. It converts every no into a tripwire. When somebody argues for the thing, you are not defending a position, you are asking whether the tripwire has been hit. And when it genuinely has been hit, you change your mind on the record, which costs you nothing and buys you a great deal.
Self-studyReading somebody else's one-pager2 min▶
The same skill pointed the other way, and you will use it more often than you use the writing half. Somebody sends you a page and wants a reaction. Resist the urge to react to the feature list, which is what the page is inviting you to do.
Ask the four questions instead. What is the job. Who is it for, specifically. What did you decide not to build. How will you know it worked. The third question is the one that changes the conversation, because a page with no out block has almost always skipped the thinking rather than done it and left it off.
You are not looking for the answers to be right. You are looking for whether the page can answer at all. A page that answers all four badly is a much better starting point than a page that answers two of them beautifully and cannot see the other two.
Where product thinking hands over
4 min liveOnce the page exists, the work in front of you is a different craft with different tools, and it is worth saying out loud which one, so you know what you are picking up next rather than guessing.
| The next question | Which craft answers it | What it starts from |
|---|---|---|
| What do the actual screens look like? | Product Design and UI/UX, at learn-product-design-with-phoebe | A problem statement. That is literally day one, and it is the thing you now know how to write |
| What do we build it on? | System Design and Orchestration, at learn-system-design-with-phoebe | A shortlist of outcomes and constraints, weighed against meters that pull in opposite directions |
| Is the thing we already have any good? | Data Product Heuristics, at learn-data-heuristics-with-phoebe | A product that already exists, and a review instrument to hold up against it |
| Did what we shipped actually work? | Experimentation, at learn-experimentation-with-phoebe | A stated outcome and a way to tell a real change from noise |
The handover is not a formality. Product Design starts at a problem statement and assumes you brought one. That assumption is why so many design projects produce something beautiful that nobody needed: the first block was skipped, and everything downstream was excellent work aimed at a target nobody had checked. Your page is the target, written before anybody starts aiming.
Self-studyWhat the page is not, and where that bites2 min▶
It is not an estimate. The weeks on the football club's list were stipulated so the arithmetic could be demonstrated. Producing honest build estimates is a genuine craft and nothing in the previous five sessions taught it. If your in-order block carries week numbers, mark where they came from, because a stipulated number and a costed one look identical on the page and behave completely differently in a meeting.
It is not a contract. The out block exists to be revisited when a tripwire fires, not to be held over somebody's head. A page used as a stick stops getting written honestly within about a month.
It is not evidence. Everything on it is your current best reading, and the date is there precisely to say so. The bench numbers you saw were computed on invented data to show a mechanism. How often that mechanism bites real projects is a separate question that nothing here answers.
Write yours, then score it
★ 22 min · one page, five blocksOne side of one sheet. Five passes, one per block, and then a scorecard that tells you which of the five earlier ideas your page has genuinely absorbed and which one it skipped.
Write the job. One sentence: what somebody is trying to get done, in their words, with the deadline or the condition attached. If you cannot write it without naming the thing they asked you to build, you still have a request rather than a job.
Write who it is for, and what they do today instead. A named role in a named situation, and the workaround they are currently using. The workaround line is the bar you have to beat, so it belongs on the page rather than in your memory.
Write what is in, in build order. Not the full list, the cut list. Then reorder it so the earliest thing on it is the earliest thing that is usable by the person who has the job, and write down which week that is.
Write what is deliberately out, and what would move each thing in. Every feature you cut, every request you declined, one line each: the thing, the reason, the signal that would change the answer. Start with the one everybody expects to be in there.
Write how you will know, and put the date on the page. The observation or number that would show it worked, written now rather than after the fact. Then score the card below, row by row, and be honest about the rows you cannot answer.
If you score low on row 5. That is the most common one to miss, and it is missed the same way every time: the out-block exists, but the reasons in it are about the requester rather than the problem. "Marketing always asks for this" is not a reason, it is a complaint, and it will not survive being read out loud by somebody else. Rewrite each line so the reason would still make sense if the person who asked were standing behind you.
After the course
30 min, then a habit- Send your page to one person who was not in the room and ask them the four questions back: what is the job, who is it for, what did you decide not to build, how will you know. Where they cannot answer from the page, the page is wrong, not them.
- Add a tripwire to every line in your out-block that does not have one yet. What would have to become true for that thing to move in. Some lines will turn out to have no honest answer, which means they were never really out, they were just unpopular.
- Put a date in your calendar three months out to reread the page. The only question that day is whether any reason in the out-block has stopped being true. Ten minutes, and it is the entire return on having written reasons down.
- Take the page into the next craft. Product Design starts at a problem statement and assumes you already have one. You do now, so start there rather than at a blank screen.
Three questions
Clear all three and session 6 gets stamped in your passport.
1 · Which block makes the one-page note worth writing, rather than merely tidy?
All four blocks earn their place, and the job block is genuinely the foundation. But the first, second and fifth blocks answer a question you get asked once. The out-block answers the one you get asked every month by a different person, and it is the block almost nobody writes.
2 · Your out-block says "No native phone apps." What single addition turns that from a conclusion into a decision?
A conclusion has no moving parts, so it cannot be checked and cannot be argued with except by reopening the whole thing. Attaching the reason and the signal that would change it means the line can be audited later, and when the tripwire genuinely fires you change your mind on the record.
3 · Somebody sends you their one-pager and asks what you think. What is the most useful thing to do with it?
The page is inviting you to react to the feature list, which is the least useful thing on it. A page that answers all four questions badly is a better starting point than one that answers two of them beautifully and cannot see the other two, and the third question is usually the one that changes the conversation.
What this session teaches, and where it came from
Session 6 cheat sheet · pin this
You have a page. What happens to it depends on which question is in front of you. Designing the actual screens is Product Design and UI/UX, at learn-product-design-with-phoebe, and it starts at a problem statement, which is the thing you now know how to write. Choosing what to build it on is System Design and Orchestration, at learn-system-design-with-phoebe. Reviewing a data product that already exists is Data Product Heuristics, at learn-data-heuristics-with-phoebe. And working out whether the thing you shipped actually worked is Experimentation, at learn-experimentation-with-phoebe. Take the page with you into whichever one you pick.