What Does Done Mean in a Startup?

Four people can look at the same work and declare it done for four different reasons.

The developer says it works. Operations says it has been released. The founder says it can be demonstrated. The customer may still have no reason to care.

All four statements can be honest. They are simply describing different states.

This difference matters in any project. In a startup, it can become costly very quickly. A team can complete a great deal of work without reducing the uncertainty on which the venture depends.

The restaurant test

Years ago, while developing Scrum for Startup, I used a restaurant to explain the problem.

To the chef, a dish may be done when the recipe is ready. To the cook, it is done when the food has been prepared. To the kitchen manager, it is done when it has been served. To the owner, it may not be done until the customer has paid and is satisfied.

In my earlier Scrum for Startup material, I called this a Unified Definition of Done, or UDoD. It was my working term for bringing technical, operational, commercial, and customer perspectives into one shared conversation about completion. I do not claim to have originated the phrase. What I would add today is a completion contract for the current startup bet: the evidence it must produce and the decision that evidence should make possible.

The underlying discipline came from Scrum's Definition of Done: people doing shared work need a shared understanding of what acceptable completion means.

Scrum's definition has a specific boundary. It describes the state of an Increment when the required quality measures have been met. I would not stretch it to include demand evidence, payment, or customer satisfaction. The completion contract is adjacent to Scrum's term, not a redefinition of it.

That distinction matters.

Payment and satisfaction do not belong inside the definition of every completed task. A team cannot command either one into existence. Nor must every experiment produce revenue. But a startup should not call a learning cycle complete unless it produces the evidence the cycle promised.

Five states hiding inside done

Instead of forcing every kind of completion into one terminal definition, I now see five useful states:

1. Built: The thing exists.
2. Usable: It works in the situation for which it was intended.
3. Exposed: A real stakeholder or customer has encountered it.
4. Evidenced: The encounter has produced decision-relevant evidence about the hypothesis.
5. Valuable: The evidence shows value worth continuing. Depending on the bet, that may appear as payment, adoption, retention, changed behavior, or another agreed outcome.

These states are not a maturity model. They are a way to stop one kind of completion from impersonating another.

Built is not the same as usable. Usable is not the same as exposed. Exposure is not evidence. Evidence does not always prove sufficient value.

The distinction lets a team make an honest claim: this is what we completed, this is what we learned, and this is what remains unknown.

Define done for the bet

Before it becomes a stable business, a startup rests on consequential hypotheses. Its work should therefore do more than create outputs. It should make the next decision better. This is consistent with the Customer Development distinction between searching for a business model and executing one, and with current business-testing practice that asks teams to make hypotheses explicit before choosing experiments.

For each meaningful bet, the team can establish a small completion contract:

• What evidence must this cycle produce?
• Who is qualified to judge that evidence?
• Which state must we reach: built, usable, exposed, evidenced, or valuable?
• What decision will become possible when we reach it?

An early technical experiment may be complete at usable. A demand experiment may need to reach exposed or evidenced. A pricing bet may need evidence of value expressed through a real commitment.

The required state depends on the uncertainty being reduced. The integrity of the cycle does not.

If the team promised customer evidence and delivered only working software, the work may be technically done, but the bet is not complete.

The whole team owns the learning boundary

Specialists naturally see completion through their own responsibilities. That is necessary, but insufficient.

The developer protects technical integrity. Operations protects reliability. The founder protects the coherence of the venture. Commercial and customer-facing colleagues protect contact with the market. Customers reveal whether the problem and solution matter outside the team's own reasoning.

No single perspective should silently define done for everyone else.

The completion contract makes those perspectives meet before work begins. It does not erase specialist accountability. It connects each contribution to the evidence the venture needs.

This is also why the startup backlog cannot be treated as a fixed feature inventory. It is an evolving order of assumptions, problems, opportunities, and experiments. When evidence changes the hypothesis, the backlog should change with it.

Fast evidence, not fast failure

Startups are often advised to fail fast. I prefer a more demanding standard: produce evidence fast.

Failure alone does not teach. Activity alone does not teach. Even customer contact can leave the important question unresolved if the experiment was poorly framed.

In my earlier material, I called the desired result a validated increment of the startup's hypothesis. I would use more careful language today. A completed learning cycle produces evidence. That evidence may strengthen an assumption, weaken it, change it, or give the team enough reason to retire it.

That is the real pull I would retain from Scrum: bounded commitments, visible work, shared expectations, inspection, and adaptation. These are the disciplines I described in What Scrum Still Gets Right, grounded in the longer history of When Scrum Mattered. None of them is the solution. They are useful when they help people confront reality soon enough to create a better one.

The question is not whether the team followed the process.

The question is: what became decidable because this work was done?

Sources

• The 2020 Scrum Guide, Ken Schwaber and Jeff Sutherland.
• A startup is not a smaller version of a large company, Steve Blank.
• Designing strong experiments, Strategyzer.