Define done before you define the model

An engineering lead at an adtech firm told me about the meeting that changed how he runs AI projects. His team was twelve weeks into building something and stuck in a circular argument about whether it was done. Half the room thought it was working. The other half thought it was nowhere close. They were both right, because they had never agreed what done meant. They had agreed on a model in week one, jumped straight into building, and left the definition of success for later. Later arrived, and there was nothing to check against.

His rule since then is simple and it feels backward to people the first time they hear it. Define done before you define the model. Agree what “shipped and working” means in plain language, for this specific feature, before anyone chooses a technical approach. The model serves the definition of done. If you pick the model first, you have quietly let the tool define success, and the tool always defines success as whatever it happens to do well.

Done is a feasibility question, not a finish line

The reason this ordering matters is that done tells you whether the project is even possible with what you have. He gave me an example. A team wanted a model to predict which ad creative would perform for a new advertiser. Sounds like a modeling problem. But when he made them define done, the answer was that the prediction had to be right often enough to place real spend behind it on day one, for an advertiser with no history. Once done was written that way, it was obvious the data to reach it did not exist yet. The definition of done exposed an impossibility that the model choice would have hidden for three months.

Done drives feasibility because it tells you the bar, the inputs, and the moment of use all at once. What does the feature have to produce, how good does it have to be to count, who acts on it, and what do they need to see. Answer those, and you can look at your data and your constraints and say honestly whether the thing can be built. Skip them, and you will build a model, measure it against a bar you invented after the fact, and discover the mismatch at the worst possible time.

Write done in words a user would accept

His format for done is deliberately non-technical, because the point is to describe the outcome, not the method.

What the feature produces, described as the user experiences it.
The bar it has to clear to be worth shipping, agreed by the person who owns the outcome.
Who or what acts on the output, and what they see when the model is unsure.
The condition under which you would say it is not working and stop.

Notice there is no model in that list. There is no mention of an approach, an architecture, or a technique. That is on purpose. Done is a statement about the world the feature changes, and it should read the same whether you end up building a model, buying a tool, or writing a rule. He said the number of times the honest definition of done turned out not to need a model at all surprised him. AI features usually need to clear about 85 percent accuracy before their mistakes stop compounding, but you cannot even ask whether that bar is reachable until done tells you what the bar is for.

A friend who leads data science at a media company told me she refuses to let anyone name a model in a kickoff. Her first hour is spent writing the acceptance sentence, the one line a user would sign off on. She says the model conversation is easy once that sentence exists and impossible before it, because without it every technical choice is a guess at a target nobody drew.

How we approach it at Density Labs

In the AI Opportunity Assessment, our fixed two-week engagement at $2,500, we write the definition of done before we discuss a single approach. We describe what shipped and working looks like to the person who uses it, agree the bar with whoever owns the result, and only then ask what it would take technically to get there. Ordering it this way is how we catch the projects that cannot reach their own definition of done, and we would rather find that in two weeks than in two quarters.

Agree what done means before you pick how to get there. The model is a way to reach done, and you cannot choose the way until you have drawn the destination.