Specs are not documents. They are commitments you can be held to.

If a sentence in your spec cannot be measured, tested, or disproved, a model will happily fill it in. And you will happily ship it.

A few years ago I sat next to a PM in a spec review who could not answer the question “what happens if this feature does not ship on time.”

Not “what is your mitigation plan.” Not “what would you cut.” The simpler question. What happens. To whom. When.

He had a 14-page spec. It was well written. It had a problem statement, a user journey, a success metric, three acceptance criteria, and a risks section. On paper, it was a good spec. In the room, it fell apart in one question, because the spec described a feature and did not describe a commitment.

A spec is not a document. A spec is a set of statements someone will be held to. If nobody can be held to any of the sentences in your spec, you did not write a spec. You wrote a wishlist with a table of contents.

The three sentences that actually matter

Take any spec you have ever written. Underline the sentences that meet all three of these tests.

One. The sentence names a thing that will either be true or not true by a specific date. Not “we will improve,” not “customers will feel.” True or not true. Date attached.

Two. There is a way to check whether the sentence turned out to be true, without asking the author. A number, a log line, a test result, a customer message. Something that survives your absence from the room.

Three. If the sentence turns out to be wrong, a named person carries it. Not “the team.” Not “product.” A person, who can point at the sentence, and say “I said that, I was wrong, here is what I got wrong.”

Sentences that pass all three are the spec. Sentences that pass two are context. Sentences that pass fewer than two are decoration. The mistake senior PMs make is treating the whole document as though it were the spec, when in fact the spec is the four or five sentences inside it that pass the test.

Why this got sharper this year

Ambiguity in a spec used to be free. If you wrote “we will improve the onboarding experience,” the sentence just sat there, harmless, next to the sentences that did real work. A reviewer might frown, ask for a metric, or let it slide.

Ambiguity is no longer free. When a model is drafting the spec, or the plan under the spec, or the code under the plan, every ambiguous sentence gets filled in by something that does not know what you meant. The model will pick a metric. It will pick a threshold. It will pick a definition of “improved.” It will pick confidently. And the artifact will look coherent, because models are very good at making incoherent inputs look coherent on the surface.

What used to be a soft sentence that a smart reviewer would catch is now a hard commitment that a machine made on your behalf. You just did not sign it. You just did not read the part where you signed it.

The cost of not writing a real spec used to be a slow launch. The cost now is a shipped product built on assumptions you never made, that you cannot defend when they show up in production.

The test I run before I approve anything

Before I sign off on a spec, mine or someone else’s, I do one thing. I read the doc top to bottom with a pen, and next to each substantive sentence I write one of three letters.

C for commitment. I would defend this in front of a room in six months.

A for assumption. I believe this today, and it might not hold. It needs a check, a date, and a name.

D for decoration. It reads well, it says nothing.

Any spec I approve has to have more C than A, and zero D. Not fewer D. Zero. If a sentence is decoration, it either becomes a commitment, becomes an assumption with a check, or it comes out.

The test takes about 20 minutes for a 10-page spec. It is the most useful 20 minutes I spend in a week.

What to do with this before Friday

Pull one spec you own. It can be a draft, a shipped one, or one you inherited. Read it with the three letters in your hand.

Count the C sentences. If you have fewer than five, you do not have a spec. You have a document. Rewrite the top five candidates into commitments, with dates and checks and a name.

Then send the spec to the one person on your team who is most likely to disagree with the load-bearing sentence, and ask them to try to disprove it. If they cannot, the sentence is stronger. If they can, you just saved yourself the launch review where somebody else does it for you, with more people in the room.

A spec is not what you wrote. A spec is what you are willing to be wrong about, in public, with your name on it.

Ship one this week.

See you next Tuesday.

Luiz

Views are my own and do not represent Microsoft.