Back to Blog

Why Done Is Not Good Enough In Business

Why Done Is Not Good Enough In Business

In business, calling a task “done” is often discouraged—not because the word is wrong, but because it is too vague.

The word doesn't tell us the true status of the work.

When someone says:

“It's done.”

What exactly does that mean?

Did they finish writing it? Did they test it? Did someone review it? Was it approved? Was it delivered? Did it actually solve the business problem?

The same word can mean completely different things to different people.

Why “Done” Is a Problem

1. It has no clear meaning

Every person on a team can have a different definition of “done.”

For a developer, it might mean:

“I finished coding.”

For a tester:

“It passed testing.”

For a manager:

“It is ready to go to the client.”

For a customer:

“I can use it successfully.”

All four are different stages.

Yet one word—done—can make them sound identical.

2. It can hide skipped steps

A task may have been written, coded or completed from someone's perspective, but important steps may still be missing.

For example:

“The feature is done.”

But has it been reviewed?

Has it been tested?

Has it passed security checks?

Has it been deployed?

Has the customer validated it?

A task can be finished by one definition and incomplete by another.

3. It creates false confidence

This is perhaps the biggest business problem.

A manager hears:

“The project is done.”

and assumes:

“The project is ready for the client.”

But perhaps the work still needs testing, documentation, approval or deployment.

The word creates a sense of finality without necessarily providing evidence of completion.

And false confidence is expensive in business.

It can lead to:

  • premature releases
  • customer dissatisfaction
  • missed deadlines
  • rework
  • production incidents
  • unnecessary escalation

What Does “Done” Actually Hide?

When someone says “done,” a good business conversation should immediately make us ask:

  • Did you just stop working on it?
  • Has the work been reviewed?
  • Has it been tested?
  • Are there known issues?
  • Has it been approved?
  • Has it been deployed?
  • Has the customer accepted it?
  • Has the intended business outcome been achieved?

These questions turn a vague status into a measurable status.

Consider a Simple Business Scenario

A customer asks a company to build a new reporting dashboard.

The developer says:

“Dashboard done.”

The manager assumes the work is ready for demonstration.

But in reality:

  • development is complete
  • testing hasn't started
  • some data is incorrect
  • the UI hasn't been reviewed
  • the customer hasn't seen it

Nothing was necessarily wrong with the developer's statement.

The problem is that “done” communicated much more certainty than the actual situation justified.

A better status would be:

“Development completed. Ready for QA.”

Now everyone knows where the work actually stands.

After testing:

“Tested and ready for business review.”

After approval:

“Approved and ready for production.”

After deployment:

“Deployed and validated in production.”

Each statement communicates a specific state, rather than forcing everyone to interpret the word “done.”

Better Words Than “Done”

Instead of using one word to represent everything, describe the actual stage:

  • Ready for review
  • Development completed
  • Ready for QA
  • Tested and validated
  • Approved by the manager
  • Ready for deployment
  • Deployed successfully
  • Accepted by the customer
  • Issue resolved and verified

These phrases may sound slightly longer.

But they reduce ambiguity.

And in business, clarity is usually cheaper than ambiguity.

From Task Completion to Business Outcome

There is an even deeper lesson here.

A task-oriented person asks:

“Did I finish my task?”

An ownership-oriented person asks:

“Did we achieve the intended outcome?”

A developer can finish coding without solving the customer's problem.

A salesperson can finish 50 calls without creating a meaningful opportunity.

A support executive can close a ticket without actually resolving the customer's underlying issue.

A project team can deliver a system without making it usable for the business.

So:

Activity completed ≠ Responsibility completed ≠ Business outcome achieved.

“Done” becomes useful only when everyone agrees on what done means.

Perhaps the better question in business isn't:

“Is it done?”

but:

“What exactly is complete, what remains, and what evidence tells us it is complete?”

Because businesses don't create value by simply finishing tasks.

They create value by achieving outcomes.