The Last 20 Percent Is the Product
A claim keeps surfacing about AI-assisted product work: the tool gets you 80 percent of the way there.
It sounds like a productivity story. Generate the interface, connect a few interactions, clean up the code, and finish the remaining 20 percent. The difficult work looks like a smaller piece at the end.
Then you try to make the thing real.
The empty state does not help someone recover. The generated component almost matches the design system, but behaves differently in one important state. The happy path works with sample data and falls apart with a long name, a slow response, or an expired session.
Every screen looks plausible. The experience still does not hold together.
Teams call that remaining work polish. I think that understates it.
The last 20 percent is where the team decides whether the product fits its system, survives real conditions, and deserves a person's trust. It may be the smaller share of visible output. It is not the smaller share of judgment.
A Plausible Draft Can Look Closer Than It Is
AI excels at producing the recognizable shape of a product. A prompt becomes a tidy flow. The flow becomes a working prototype. The prototype includes familiar controls, reasonable copy, and enough interaction to make the idea feel concrete.
That is useful. Teams can explore more options, test a direction earlier, and move from conversation to something observable without waiting for every discipline to complete a separate artifact.
But visible completeness is a poor measure of product readiness.
A generated interface may contain most of the expected screens while carrying little understanding of the environment around them.
It does not automatically know why one component exists instead of another, which data can be trusted, what a returning user already understands, or which failure creates the most risk. It can reproduce the pattern without carrying the decision that shaped it.
This is the same reason I argued that designers should get closer to code without trying to become engineers. A product becomes real through behavior, constraints, and connected systems—not through the apparent completeness of an artifact.
The 80 percent draft is genuinely valuable. It is also the easiest 80 percent to see.
The Remaining Work Is Not One Thing
Calling the rest “polish” suggests a final pass: tighten the spacing, refine the copy, smooth the transition, and ship.
Some of that work is polish. Much of it is product definition that the first draft exposed but did not resolve.
I separate the remaining work into four questions:
- Does it fit the system? The experience needs to use the product's components, language, permissions, data, and technical conventions without creating a parallel version of them.
- Does it handle real conditions? Real content varies. Networks slow down. People arrive with partial information, make unexpected choices, leave, return, and need to recover.
- Does it communicate clearly? The interface has to keep people oriented, show what changed, explain what the system needs, and make the next action understandable.
- Can the team trust it? Someone needs to verify the important behavior, inspect the implementation, consider accessibility and privacy, and decide what evidence is enough to release it.
These are not decorations added after the product exists. They determine whether the product works.
The distinction matters because teams plan differently when they mistake visible coverage for completed work. The prototype looks nearly finished, so the schedule reserves a small amount of time for cleanup. The unresolved decisions then arrive late, when changes are more expensive and the team has already started defending the date.
AI did not create that planning problem. It made the early artifact more convincing.
Define Done Around Conditions, Not Screens
One way out is to stop measuring progress by how much of the intended interface has appeared.
Before generating or building the first version, name the conditions the product needs to satisfy. Not every edge case. Just enough to describe what “working” means beyond the happy path.
For a new workflow, I would ask:
- What does the person know when they enter?
- What information can the system reliably use?
- What happens when required information is missing, late, or wrong?
- Which existing pattern should carry each part of the interaction?
- How does someone recognize success and continue?
- What can they do when the recommended path does not fit?
- Which behavior would create the most harm if we misunderstood it?
- What evidence will make us comfortable releasing the change?
Those questions give the AI better boundaries. More importantly, they give the team a shared review standard.
The usability heuristics from Nielsen Norman Group remain useful here because they describe durable interaction qualities: visibility of system status, consistency, error prevention, recognition, recovery, and help. A generated product does not graduate from those requirements because it arrived quickly.
A list like this also changes the conversation around progress. Instead of saying, “The screens are 80 percent done,” the team can say, “The main path works, but we have not resolved interrupted states, permission differences, or recovery.” The second statement may sound less complete. It is much more actionable.
Review the Seams, Not Just the Center
AI-generated work shines in the center of a familiar pattern. That is where examples are plentiful and the intended path is easiest to infer.
The seams carry more information.
Look where generated work meets an existing component, a service response, a permission boundary, a different device size, or the next step in someone's workflow. Look at the moment after submission and the moment before recovery. Use realistic content instead of the short labels that made the layout easy to generate.
This is where design, product, and engineering need to review the same thing together.
Design can inspect clarity, continuity, and whether the interaction protects the intended experience. Engineering can expose system constraints, implementation risk, and behavior the prototype does not show. Product can connect those decisions to scope, customer value, and the consequence of getting the behavior wrong.
Nobody needs to wait for a formal handoff. A generated prototype or working branch can become the shared object earlier. The important move is to treat it as a question the team can inspect, not an answer the tool completed.
The same principle applies to verification. As I wrote in AI-Generated Tests Need to Earn Your Confidence, a passing result matters only when the check can detect the failure you care about. Product review needs the same discipline. Do not ask only whether the generated path runs. Ask what conditions would reveal that the experience is wrong.
AI Changes the Cost of a Draft, Not the Standard for a Product
Getting to a plausible first version faster gives teams real leverage. It gives teams more room to compare directions, test assumptions, and involve the people who will build or use the experience.
But speed at the beginning does not remove judgment at the end. It moves judgment closer to the center of the work.
That should change where teams invest. Less time reconstructing standard interfaces from scratch. More time defining the behavior that matters, reviewing the seams, testing real conditions, and deciding what quality means for this particular product.
It should also change what we value in designers, engineers, and product managers. Producing the first version gets easier. Seeing what the first version missed matters more.
80 percent can be both a remarkable acceleration and a dangerous illusion. It depends on whether the team sees the remaining work as cleanup or as the place where the product earns its coherence.
AI can make the draft arrive sooner.
The team still has to make it belong, make it hold up, and make it trustworthy. That is not the work after the product.
That is the product.