The Last Ten Percent Bites

The work looks done.

Then someone tries to use it.

The link is wrong.

The welcome email never fires. The mobile view folds in half. The handoff needs a password nobody wrote down. A small question arrives, and the person who built the thing has already moved on.

Suddenly, the last ten percent has teeth.

This is where smart people make a flattering diagnosis. The project was harder than expected. The team needs more time. The launch needs more polish.

Maybe. But the uglier answer is usually simpler: you counted making the thing and forgot to count making it usable without you standing beside it.

Starting is generous. It gives you a blank page, a clean branch, and a hundred ways to feel clever. Finishing is rude. It asks whether the promise survives contact with another human.

So the first stretch gets a name, a plan, and the best hours of the day. The final stretch gets called cleanup. That word makes real work sound like crumbs on a counter.

It is not cleanup. It is where the private artifact becomes a public result.

The Finish Was Missing From the Plan

A task such as “build the page” quietly ends when the builder feels finished. The buyer does not care about that moment. They care when the page loads, reads clearly, works on their phone, sends the right data, and leaves them with a next step.

Those are different finish lines. One measures production. The other measures release.

Agile teams use a definition of done to make that edge explicit. Atlassian describes it as an agreed set of criteria a work item must meet before it is considered complete. The useful part is not the jargon. It is the refusal to let “done” remain a private feeling. A shared finish standard makes hidden work visible before the deadline finds it for you.

This matters far beyond software. A proposal is not done when the PDF exports. It is done when the buyer can understand the choice and make it. A workshop is not done when the slides look sharp. It is done when the room knows what changes Monday. A delegation is not done when the message is sent. It is done when the next owner can move without a rescue call.

You may hear that and reach for a giant checklist. Resist it. A checklist can turn a small finish into a customs inspection. The cure for forgotten edges is not permanent bureaucracy.

GitLab's minimum viable change principle pushes work toward the smallest useful improvement, then iteration. That is different from shipping a half-kept promise. Small scope is healthy. Missing ownership is not. The point of a minimum viable change is to reduce what must be finished, not to rename unfinished work.

The Builder Has Already Left

The most dangerous moment comes when the main work feels complete. The reward arrives early. You can see the design. Run the feature. Read the draft. Your brain collects the win and starts looking for the next fresh problem.

What remains is less glamorous: access, edge cases, support, proof, documentation, follow-up. Each piece looks too small to deserve an owner. Together, they decide whether the work lives.

Then the familiar theater begins. Everybody is “just waiting on” one last thing. Nobody names who owns the crossing from nearly ready to safely used. The task passes through several hands, gathering delay but no judgment.

The UK Government Service Standard gives this problem a clean test: a service should solve a whole problem for users. The phrase “whole problem” is merciless. It does not care which team's box was checked. It follows the person trying to get the result. That is why its guidance asks teams to solve the whole problem, including the parts that cross organizational seams.

Your customer does not experience your seams as an org chart. They experience them as friction. Every missing instruction, broken path, and ownerless question says the same thing: the burden has crossed the counter.

Give the Finish a Gate

Before work begins, write a Finish Gate. Keep it short enough to use and sharp enough to embarrass vague plans.

• Promise. What can another person now do, receive, or decide?
• Proof. What visible evidence shows that the promise works outside the builder's hands?
• Edge. Which failure, access issue, or handoff is most likely to strand the result?
• Owner. Who carries the work through that edge and confirms the finish?

The Promise stops the artifact from becoming the goal. The Proof forces a real test. The Edge finds the bite before the user does. The Owner prevents five helpful people from producing one abandoned finish.

Notice what is missing: a demand for perfection. A finish gate should not smuggle every future improvement into today's release. It should defend the result you actually promised.

If you promised a working booking page, test the booking. Do not delay it for a grand redesign. If you promised a decision memo, make the choice legible. Do not add twelve pages of research to prove you worked. If you promised a handoff, watch the next person begin without you.

Stop Celebrating Nearly

There is a reason unfinished edges multiply. Organizations celebrate the reveal. The new page gets applause. The prototype gets a meeting. The strategy gets a polished deck. Quiet reliability arrives later, usually without witnesses.

Change the witness. Review work when the promised result crosses into someone else's hands. Praise the person who closed the loop, not only the person who made the visible center.

This will feel slower at first because you are finally counting work that was always there. That is not lost speed. It is an honest bill.

Tomorrow, open the project everyone calls almost done. Do not ask for a percentage. Ask what promise another person can use, what proves it, where it can strand, and who owns the crossing.

Then finish the finish. Let someone use the work without calling you over. Watch the last loose edge go quiet.

The teeth are gone.