Success Criteria

For a long time, "done" meant "built." Every screen in the spec existed, no defects were open, the item was finished, and the team moved to the next one.

That leaves a question nobody can answer at the launch review. Asked whether this one went well, everyone goes quiet. It's clear the team built what it said it would build, but what should have changed afterwards was never written anywhere. So the conversation slides to whether the date held and how many defects came in, and the reason the item was built in the first place never comes back up.

Sometimes it surfaces in a worse way six months later. Someone digging through usage numbers for an unrelated reason notices almost nobody touches that feature. By then the person who built it doesn't remember why it was at the front of the queue.

Success criteria move that judgment to the moment the document gets written. Agree before the work starts and four weeks later you can open the same document and settle, right there, whether the bet was right or wrong.

Success criteria put a measured thing, a number, and a date in one sentence. Leave out any of the three and no judgment is possible. "Improve coupon usage" is not a criterion. "Four weeks after launch, a coupon is applied on at least 15 percent of completed checkouts" is one. The first sentence produces no conclusion on the day; the second is either true or false.

Five things belong in it.

1. What gets measured, written so it reads one way only. "A coupon is applied" gets pinned down as a completed checkout where a code was entered and a discount actually came off. Without that, someone counts the people who merely typed a code into the box.
2. The number, plus one line on where it came from. Today it's zero percent and comparable products land between 12 and 20 percent, for instance.
3. The date. Four weeks after launch, fixed. One week catches only the first-look reaction, and six months mixes in everything else that changed in between, which makes the cause impossible to isolate.
4. Where it gets checked. Which number on which screen, read by whom, on what day. Without this line, week four starts with someone building the query from scratch.
5. What happens if it falls short. Roll it back, watch it another month, or leave it and move on — decided in advance. Skip this line and a miss produces no action at all, and after that happens twice nobody fills the field in seriously again.

One or two criteria is the right count. Write five and the result comes back with three hit and two missed, which turns the judgment itself back into an argument. Make one the primary and demote the rest to numbers you watch alongside it.

Next to the number that should rise, write the number that must not get worse — something like: while coupons reach 15 percent, checkout failure rate does not go up. Conditions that aren't behavior, like response time or security, live in the non-functional requirements field, but a line this particular piece of work could break is more useful sitting right next to the criteria.

There are four places the field does work.

The first is writing the product requirements document, the doc that records what is being built, why, and when it's finished. Inside it, the functional requirements field — which states the behavior the product has to produce — carries what gets built, and success criteria carry why.

The second is cutting scope, the boundary around what's being built this time. With a number in hand you can ask of each candidate feature whether reaching that number needs it. If 15 percent is reachable without an admin screen for issuing coupons, the admin screen drops out of this round.

The third is prioritization. Items with the field empty go to the back, because "it would be nice to have" and "this much will change by this date" cannot go on the same scale.

The fourth is the review after launch. When the date arrives, the same document gets opened and the number filled in. That single check is what stops the team from building another feature of the same kind next quarter.

Customer success teams keep a success plan, which records a customer's goals and the path to reaching them. The names are close and the layers are different. This field measures whether what you built worked; that document describes what one customer is trying to achieve.

"I can't review this without success criteria. Write down what we'll look at in four weeks."

What gets built is on the page, and why it's being built isn't there in a form anyone can judge.

"The bar was 15 percent and we came in at 9. We're giving it another month."

The number missed, and the team picked one of the responses it had chosen before starting.

"That's a to-do list, not success criteria."

It lists what will be built and says nothing about what changes once it exists.

Pagedeck put the field in its document template and made a rule that a review doesn't open while it's blank. For the coupon-entry feature, Mia wrote two lines: four weeks after launch a coupon is applied on at least 15 percent of completed checkouts, and the checkout failure rate does not rise.

Week four came in at 9 percent. Theo split the usage logs and found that three in ten people who entered a code stopped at an error screen. Because "watch another month" was already written down as the response to a miss, the decision was to fix that screen instead of shelving the feature, and the next month it read 16 percent.

The most common mistake is thinking a higher bar makes a better document. Big numbers look ambitious and tend to sail through review. But the purpose of the field is not to display ambition; it's to make a judgment possible in four weeks. Put 40 percent down with nothing behind it and a result of 9 percent can't tell you whether the product was wrong or the number was, which sends the review back to trading impressions.

The second is reading a miss as a failure. The name invites it. What the field actually buys is speed of judgment, not a certificate. Finding out in four weeks that a hypothesis was wrong lets the next decision happen right there, which beats not knowing for half a year. Treat every miss as a failure and the team starts writing down numbers it's sure to clear, or leaving the field blank.