The Tuesday problem
Nobody is going to read four specs before writing a paragraph.
In "What Went Into This Post" I laid out what a full spec assembly looks like — channel, feature, intent, brand — each block owned by someone who already knows their piece. It's a clean picture, and for a one-off artifact it actually works. You sit down, read the specs, think it through, build the thing, check it back.
Now picture Tuesday afternoon. Same kind of post, the tenth one this quarter. Someone opens a blank doc at 2pm and needs to ship by five. They're not going to consult four documents. They're going to remember what they remember, and write.
Not impossible. Just expensive. And expense, repeated, creates drift.
The four specs still need to exist. They just need to reach the work in a different form.
Spec and standard
The spec holds the choices — audience, angle, what the channel rewards, what the brand credibly says. It's where the argument lives. For one-off work, the spec is also what you use: read it, build, check back against it, done.
For work that repeats, you need something else. A standard is the spec compiled down to the decisions that matter for one specific recurring artifact. Not the whole spec — just the parts that turn into rules someone can follow without re-deriving. Standards aren't arguments. They're instructions, and they encode the argument.
The standard doesn't replace the spec. It sits alongside it, takes its cues from it, and gets re-derived whenever the spec changes.
An example: the What's New page
Let me show this with a concrete one, because it's the case I've been in most.
A What's New page is the thing a software product publishes with each release to tell existing users what changed — part announcement, part tour, part reason to stay.
Here's the spec for one, compressed to the minimum that lets it travel:
- People come here to sort before they read. They're not refusing to read — they just don't want to read everything. They want the parts that matter to them, fast.
- After skimming, they should feel where the product is going. Even from the first screen, they should sense the positioning — what this product prioritizes, what it stands for this release.
- When they stop on a feature, they should find what they need right there. How it works, why it matters, where to find it. No tab-hopping. No documentation detour.
That's the spec. Three lines. Everything else — the audience analysis, the belief shift, the editorial thesis, the positioning logic — lives upstream, in the full version nobody opens on a Tuesday afternoon.
Now the standard. Three rules, each compiled from one of the spec points above.
First rule: the first screen summarizes the key features in the release. Not a hero image. Not a welcome. A summary the reader can absorb in seconds and know whether to keep going. If they can't sort on the first screen, the page has already failed.
Second rule: features are grouped by story, not by technology. Take the position the product is making this release, cluster features under the arguments that prove it. If the position is "agents generate, developers decide what survives," then one story is the controls that let you review what the agent did. Another is the interfaces that keep you in charge while the agent works. Features slot under stories. Some serve multiple. Some serve none — and maybe those shouldn't lead. The grouping is the positioning. You don't need to tell people what the product stands for. The choice of stories tells them.
Third rule: below the first screen, every feature gets a name, a description, and a piece of media visible in one glance. The first screen is for sorting; this is where the actual reading happens. Name for triage. Description for "what does this do and why should I care." Media to show where the thing lives in the IDE. Read name plus description, decide whether to try it. Glance at the media, know where to find it.
Three spec points, three standard rules. The person building the page doesn't need to read the spec. They don't need to know what "narrative reinforcement" means or why grouping is positioning. They need: summarize on first screen, group by story, name plus description plus media per feature. Follow those three rules and the page compiles against the spec automatically.
The reasoning stayed home. The decisions came along.
This is how you get ten consistent What's New pages for ten different products without ten different arguments about layout. Each team plugs in their current position, follows the same standard, and the page assembles itself around it. Standard stays the same. Stories are different. Positioning does the work.
How it composes
Go back to the four specs from "What Went Into This Post": channel, feature, intent, brand & positioning. A What's New page needs all four. Channel decides the shape. Positioning decides the stories. Feature decides what fills them. Intent decides what leads.
What the standard does is pre-compile the channel spec. The rules about first screen, grouping, and per-feature components aren't re-derived every release — they're the stable part. The other three specs stay live. Positioning changes. Features change. Intent changes. The standard holds the slots. The rest of the assembly fills them.
That's the move. You compile the one spec that can be compiled, and let the others flow through. And without the spec underneath, a standard is just a template — you can follow it, but you can't tell if it's working.
Specs are for thinking. Standards are for shipping. Most weeks the thinking has already been done — and what you need, at 2pm on a Tuesday, is the part of it you can carry.