Let the person who uses the output define good enough

A content operations lead at a media company built an AI feature to draft article summaries. She cared about writing, so she held the drafts to a writer’s standard. Clean prose. Right tone. Nothing she would be embarrassed to publish under her name. She kept tuning, because by her bar the summaries were never quite good enough, and the project dragged.

Then she watched how the summaries actually got used. They fed an internal dashboard where editors skimmed them to decide which articles to promote. The editors did not care about prose. They wanted the gist in one glance, accurate on the facts, and they did not read past the first line most of the time. Her writerly polish was invisible to them. The one thing they needed, dead-accurate facts in the opening clause, she had not been optimizing for at all, because she was busy being a good writer at an audience that was not reading like one.

She had defined “good enough” from the builder’s chair. The people who consumed the output had a different definition, and theirs was the only one that mattered.

“Good enough” is not a property of the output

It is tempting to think quality lives in the artifact. A summary is good or it is not. But quality is always relative to a use. The same summary is excellent for an editor skimming a dashboard and inadequate for a reader who will publish it verbatim. Nothing about the text changed. The consumer changed, and the bar moved with them. So “is this good enough” is not a question you can answer by reading the output. You answer it by knowing who uses it and what they need from it.

This is why builders drift. Left alone, you optimize for your own taste, your own idea of quality, your own sense of what a good version looks like. Your taste is real, but it is not the spec. The consumer’s need is the spec. When those two diverge, and they diverge constantly, following your taste means overbuilding in the directions you happen to care about and underbuilding in the direction the consumer actually depends on.

Get the bar before you scope

The fix is to find the consumer of the output and ask them, in concrete terms, what good enough means, before you write the spec. Not “do you want it to be high quality.” Everyone says yes to that. Ask what they do with the output, what they check first, what would make them stop trusting it, what they would happily ignore. Their answers set the real targets, and the real targets are usually narrower and more specific than your instinct. The editors needed factual accuracy in the first line and nothing else. That is a scope you can build to and test against. “Good writing” is not.

There is a mirror-image failure worth naming. Sometimes the consumer’s bar is higher than the builder’s, not lower. A risk analyst at a bank told me about an AI feature that flagged suspicious transactions. The builders thought a good-looking flag was enough. The analysts who lived with the output needed to know why it fired, because they had to defend every decision to a regulator. Without the reason, a technically accurate flag was useless to the one person who used it. The consumer wanted more than the builder thought to give. Same lesson, opposite direction. You cannot guess the bar. You have to ask the person who lives with the result.

The practical habit

Before scoping, name the consumer of the output and get their definition of good enough in their words. Turn that definition into the acceptance bar for the feature. When you are tempted to polish something the consumer never mentioned, stop, because that polish is for you, not for them. When the consumer names a need you were about to skip, that need is not optional. It is the point.

How we approach it at Density Labs

In the AI Opportunity Assessment, our fixed two-week engagement at $2,500, we do not let the team building the feature set the quality bar alone. We interview whoever consumes the output and pin down what good enough means to them, in specifics, and that becomes the standard the feature is scoped and tested against. It saves teams from the two classic misses at once: polishing what nobody reads, and skipping what the one real user cannot work without.

Quality is not something you judge from the builder’s seat. Ask the person who uses the output where the bar is, then build to that bar and no higher.