Done Means Someone Used It
Merged is a midpoint. A feature is done when real people have used it and you know what happened — including when what happened was nothing.
The ask, the obvious response, and how it goes wrong
Every lesson starts where the work starts: someone asked for something, and the first response that comes to mind has a problem.
When is a feature actually done?
Sprint review. The engineer says: "Order tracking page — done. Merged, reviewed, deployed, QA signed off." The ticket moves to the Done column and the team moves on.
Done is merged, reviewed, tested and deployed. It is objective, the team controls every part of it, and it keeps the board honest. Whether customers use it is the PM's concern.
The tracking page is deployed behind a flag at 0%. It is "done", and no customer has seen it. Three weeks later someone notices the ramp never started.
- The tracking page is deployed behind a flag at 0%. It is "done", and no customer has seen it. Three weeks later someone notices the ramp never started.
- The page was built to cut "where is my order?" contacts to support. Nobody looks at that contact reason after launch, so nobody learns that the link for one carrier uses the wrong tracking-number format — and those contacts went up.
- Follow-ups die with the ticket. "Link the tracking page from the shipping email" was a comment on a closed ticket, and closed tickets do not get planned.
- A board that counts closed tickets rewards shipping, not learning. The team with the most cards in Done may have changed nothing, and the board cannot tell.
What is really going on
- There are two finish lines. Shipped is engineering's: merged, deployed and released to real users. The team controls it. Done is the product's: people used it, and the team knows what happened. The team does not control what happened, only whether it looked.
- Done does not mean it worked. A feature nobody used, written up as "nobody used it, here is our best guess why", is done. A feature that changed everything and that nobody has looked at is not.
- The gap between shipped and done is where outcomes get lost: the ramp that stalls, the metric nobody checks, the support reason nobody reads. Nobody decides to skip it; it simply has no column on the board (Outcome vs Output).
- Putting the look inside done gives it to the person with the most context. The engineer who built the tracking page knows which carrier format was fragile and which event would show it.
- Done needs a date, not an open-ended wait. Some outcomes show in a week, some in a season. The definition says when you will look and what you will write down, so tickets do not sit open forever.
Merged is a midpoint
Most boards end at the moment the team stops typing. Everything after that — the release, the first customers, the support contacts, the number — happens off the board, which means it happens if someone remembers.
Drawing the whole line makes the gap visible. The engineering half ends at shipped. The product half ends when someone has looked and written down what they saw.
Done means you know what happened
A definition of done that includes the look has to be short, or it will be ticked by habit. Three lines when the ticket is written and one paragraph at the end are enough for most features.
1### Shipped (engineering controls this)2- [ ] Merged, reviewed, tested3- [ ] Released to real customers (not a flag at 0%)4- [ ] Events for the signals below are live and checked once5 6### Done (someone used it, and we know what happened)7Used signal: tracking page opened from order page or shipping email8Helped signal: "where is my order" contacts per 100 orders, vs last 4 weeks9Look date: 2026-10-2010- [ ] Looked on the look date and wrote one paragraph below11- [ ] Flag, old path and temporary logging removed12- [ ] Follow-ups filed as new tickets (or "none")13 14What happened:The "What happened:" line starts empty on purpose. A ticket cannot be done while it is empty, and "nobody used it" is an acceptable thing to write there.
Saying it in the review
The change shows up first in how people report work. Two words — shipped and done — used consistently in reviews do more than any process document, because everyone hears the difference every week.
The team reviews the sprint with the PM and a support lead. The tracking page is the headline item.
"Order tracking page is done — merged Monday, deployed Tuesday, QA passed. Moving on to returns next sprint."
"Order tracking is shipped: live for all customers since Tuesday, linked from the order page. It is not done: we look at 'where is my order' contacts per hundred orders on the 20th, against the last four weeks. One early thing — support saw two tickets about a broken link for one carrier; that is fixed. Next sprint I will link it from the shipping email if the numbers justify it."
Done is not "it worked"
The most common way to break a good definition of done is to quietly turn it into a success criterion. Then features that did nothing never become done, the column fills with them, and people learn that looking is risky.
Ticket stays in Shipped for two months. Eventually someone moves it to Done during a board clean-up with no comment.
Looked on the 20th. Contacts per hundred orders unchanged. Page opened by very few customers — it is only linked from the order page, which most people never revisit. Next: link from the shipping email, look again in three weeks. If still flat, remove the page.
The second write-up turns a flat result into a specific next step and a stopping rule. The first loses the learning and leaves a feature nobody can say anything about.
When the look is months away
Some outcomes take longer than a sprint to show: a gift-card feature that matters in December, a B2B invoicing change used once a month. Holding the ticket open for a season makes the board useless. Moving it to done with nothing written loses the point.
The middle path is two looks. An early look at "used" — did anyone reach it, did anything break — closes the ticket. A scheduled later look at "helped" is its own small ticket, with a date, owned by a named person, and it is what the team reports on when the season comes (Running a Demo That Ends With a Decision).
How to do it
Most important first.
- Split the board: "Shipped" and "Done" as separate columns, or a checklist on the ticket that cannot be completed at merge time.
- When the ticket is written, add three lines: the signal that shows it was used, the signal that shows it helped, and the date you will look (Picking a Metric That Moves When the Product Gets Better).
- Count the release as part of shipped: merged behind a flag at 0% is not shipped (Feature Flags as Product Tools).
- At the look date, write one short paragraph — used or not, helped or not, what surprised you, what is next — and link it from the ticket (Decision Records).
- Include removal in done: the flag, the old path, the temporary logging the launch needed.
- Read the support queue for the area in the first week after release; it is often where the outcome shows first (The Support Loop, Qualitative Signals).
How to explain the decision
The sentences, the order, and what to lead with — for someone who did not make the call.
- In the review, report both lines: "Order tracking is shipped — live for all customers since Tuesday. It is not done yet: we look at 'where is my order' contacts on the 20th."
- When proposing the change to the team, start with something everyone has seen: "We have closed tickets that no customer ever saw. I want the board to show the difference."
- Be explicit about what done is not: "Done does not mean it worked. It means we know. 'Nobody used it' is a perfectly good done."
- With the PM, frame it as shared work: "You care whether it moved the number; I know how to find out cheaply. If the look is on my ticket, it will happen."
- "Our velocity will look worse." Velocity measures how fast tickets close. If they close without anyone knowing what they did, we are measuring the wrong thing faster.
- "Some outcomes take months — do tickets stay open all quarter?" No. The look date can be a month out, and the ticket moves to done with what we know then. If it needs a second look, that is a new, small ticket.
- "QA signed off, so it works." QA shows it does what the ticket said. Done asks whether what the ticket said was worth doing.
What can go wrong
- Done becomes a second bureaucracy: a long checklist ticked by habit, with a "learned" line that says "went well".
- The look date falls in a busy week and nobody owns it, so the ticket sits in Shipped indefinitely and the column turns into noise.
- Measuring the wrong "used": views of the tracking page, rather than whether customers who saw it contacted support less (What Dashboards Hide).
- Holding engineers accountable for outcomes they do not control. Done asks "did you find out?", not "did the number go up?"; mixing the two teaches people to avoid looking.
- "Done means the metric moved." Then nothing uncertain would ever be done, and people would stop shipping uncertain things. Done means you know.
- "This is the PM's job." The PM may own the goal; the engineer usually knows the fastest way to see whether it happened, and is the one who can fix the carrier bug the look uncovers.
- "Deployed at 0% is shipped, we just have not turned it on." Code no customer can reach has not been shipped; it has been stored in production.
Knowing whether it worked
- The Shipped column empties into Done regularly, each card with a paragraph, instead of piling up.
- Sprint reviews include at least one "we shipped this three weeks ago, and here is what happened".
- Follow-ups reach planning from done write-ups rather than from someone's memory.
- Flags and temporary code are removed as a matter of course, because removal is part of done.
- On a small team, the engineer who built it looks at the number personally. At 10x team size, done has to be visible on a shared board, or the look is lost between teams.
- At 10x customers, results arrive faster and the look can come sooner; low-traffic features may need a longer window before they show anything.
- At 10x features, done write-ups become the team's memory of what worked — often the only record that stops the same failed idea from being built twice.
- Tickets stay open longer and the board looks less productive, which some managers will read as slower work.
- Engineers spend time on something other than building: reading support tickets, querying events, writing paragraphs.
- It exposes features that did nothing. That is the point, and it is uncomfortable the first few times, especially for whoever proposed them.
Where this applies
Product advice is context-sensitive. These labels say what each claim is specific to, and where a different stage, team or product would differ.
- GENERALSeparating shipped from done applies to anything built for users. For purely internal technical work — an upgrade, a refactor — "used" means the system is running on it, and done can collapse back into shipped.
- TEAM-SPECIFICWhere a PM or an analytics function owns measurement, the engineer's part of done may be "the events exist and the PM has the query". Where nobody owns measurement, the engineer's definition has to include the look itself.
- PRODUCT-SPECIFICFor B2C checkout features the look can happen within a week. For B2B features used monthly, or seasonal ones like gift cards, the look date is weeks or months out and needs a scheduled reminder rather than good intentions.