Decide · Lesson 3 of 8
Writing the one sentence your product has to keep — and deleting everything that isn't it.
4 min read
Before the next lesson
You have an idea. It is currently a cloud — a general sense of a thing that would be good. Clouds cannot be built. The next two hours turn the cloud into a sentence, and the sentence into a list short enough to finish.
One sentence, in this shape:
It takes X and gives you Y.
Take a photo of a receipt and give you a filled-in expense line. Take a job description and give you five interview questions. Take a repository URL and give you a one-page summary a new hire can read.
Rules for the sentence: no "and", no "also", no adjectives doing structural work. If you need two sentences, you have two products, and today you get one. If the sentence contains "manage", "organise", or "platform", you have not finished cutting.
Write it at the top of a file called SCOPE.md in the repo. It is the thing you will read at hour sixteen when you are trying to talk yourself into one more feature.
Underneath the promise, write every feature you have thought of and are not building today. Accounts. Saved history. Export. Settings. Dark mode. Teams. The list is not a backlog and it is not a compromise — it is a record of decisions already made, so that each one costs you nothing to re-decide later in the day.
A well-cut sprint usually has a kill list three times longer than the build list. If yours is short, you have not been ambitious enough about what you are refusing.
Three questions decide whether something stays:
Does the promise break without it? Not "is it worse" — does the sentence stop being true? Keep only what the sentence requires.
Does it cost more than an hour? Anything that does, on a first pass, is a candidate for a hardcoded stand-in. Real authentication takes hours. A shareable link with a random ID takes ten minutes and, for one day, is indistinguishable to the user.
Does the first-time user meet it? Features behind a state the user cannot reach on day one — the second visit, the tenth item, the empty account — do not exist yet. Build the first ten seconds properly and let everything after it wait.
There is a difference between a shortcut and a mess. A shortcut is a real decision, written down, with a visible seam: one config file of fixed values, one clearly-named TODO_REAL_DATA constant, one route that returns a fixture. A mess is the same shortcut scattered through nine files where you will never find them.
Keep the seams in one place. Tomorrow-you replaces a file; tomorrow-you does not perform an archaeology dig.
Read your promise out loud, then read your build list. If someone could look at the list and not guess the promise, the list is wrong. If the list has more than about eight items, it is still a two-day project.
Cut until the list is boring. Boring lists get finished, and a finished boring product beats an unfinished interesting one every single time — the interesting version does not exist, and the boring one is live.