Operator Philosophy

What 'Done' Actually Looks Like in Digital

Most projects are never actually done. They just run out of momentum.

Ask a founder if their website project is done. They'll usually say something like "mostly done" or "we're still tweaking it" or "there's a few things we want to fix." Ask them what done actually means. They rarely have a clear answer. This is the problem with most digital work. There's no definition of done. So work just keeps going indefinitely, with no sense of completion.

This matters because without a definition of done, you never have closure. You never know if you should move on to the next project. You never have evidence that something worked. You just keep optimizing and tweaking and improving and nothing ever ships in a complete state. The work becomes Sisyphean. You're rolling the stone up the hill forever.

I've learned to define done very specifically for every project. Not as a stretch goal. Not as a someday goal. But as a concrete endpoint with specific criteria. Once those criteria are met, the project is done. We stop. We move on. We learn from what we built. We build the next thing.

Done Is Not Perfect

The first thing to understand is that done is not perfect. Perfect is an infinite pursuit. There's always something you could improve. There's always another optimization. There's always another feature that could make the product better. If you're waiting for perfect, you'll be working forever.

Done is hitting a clear target. It's the website launching with the key pages built. It's the campaign launching with the core messaging. It's the product shipping with the essential features. It's defined in advance. It's achievable. It might not be perfect, but it's complete enough to launch and measure.

This is hard for perfectionists. Most founders are perfectionists. They want the site to be beautiful. They want the copy to be perfect. They want the product to be fully polished. But the cost of perfection is that nothing ships. The cost of done is that something imperfect ships and you learn from it.

Defining Done In Advance

The key to actually finishing projects is to define done before you start. Not after you're halfway through. Not when you're running out of momentum. Before you begin. Write down the specific criteria for what done looks like. Be specific. Be measurable. Be realistic.

For a website project, done might be: "The homepage, about page, pricing page, contact page, and one case study page are built and live. The site is mobile responsive. The site loads in under three seconds. The copywriting is reviewed by the founder and approved. The site is indexed by search engines." Not "the website is done," which means nothing. But specific criteria that can be checked off.

For a campaign, done might be: "The ad creative is created. The audience targeting is configured. The landing page is built. The performance tracking is set up. The campaign goes live and runs for thirty days. We collect at least 100 conversions and measure ROI." Clear criteria. Measurable. Achievable.

The Danger Of Undefined Scope

When done is not defined, scope creeps. Someone thinks of something else they want to add. The vision expands. The timeline extends. The project goes on and on. I've seen projects that were supposed to take eight weeks that are still going after two years. Not because they're fundamentally broken. But because there's no clear endpoint.

Undefined scope is the enemy of completion. It's also the ally of mediocre work. When the scope keeps expanding, you don't have time to do any one thing well. You're constantly pivoting. You're constantly adding and adjusting. By the time you finally stop (because you run out of energy or money), nothing is done properly. Everything is partially built.

The cure is ruthlessly limiting scope. You do one thing. You do it well. You complete it. You measure it. Then you decide what to do next. The constraint forces prioritization. It forces clarity. It forces completion.

Shipping Is Better Than Perfect

There's a compounding benefit to shipping completed projects. The first is that you get feedback. You launch the site. You see how people actually use it. You get data. You learn. You wouldn't have learned any of this if you were still in optimization mode never shipping anything.

The second is that shipping builds momentum. You completed something. You can point to it. You can say "we built that." This is psychologically powerful. It creates confidence. It motivates the team. It gives you evidence that you can execute. If nothing ever ships, the team gets discouraged. Nothing feels complete.

The third is that shipping enables the next project. You can't work on five things at once. You have to finish one. Ship it. Move on. The team can focus. Resources can be reallocated. You can actually make progress on multiple initiatives because you're completing each one before starting the next.

The Sunk Cost Fallacy In Digital Work

One reason projects never get done is the sunk cost fallacy. You've already invested two months in building this feature. You can't stop now. You have to make that investment worth it. So you keep going. But the problem is that two months is gone. Continuing to spend more time on it doesn't bring back the two months. It just wastes more time.

The rational decision at any point in time is: given what I know now, should I continue on this project or move on to something else? If the answer is no, you should stop. It doesn't matter how much you've already spent. If continuing is not the right decision now, stop. The time you've already spent is gone. Don't throw more time after it hoping to salvage the investment.

This is why clear definitions of done are so important. They let you know when to stop. You've hit the criteria. You're done. You move on. You don't keep going hoping to hit some mythical perfect state that doesn't exist.

Done Enables Learning

The real value of completing projects is not just that you have something built. It's that you can measure it. You can see if it worked. You can learn what works and what doesn't. This learning is critical for the next project. But you can't learn anything if nothing ever ships.

I've worked with founders who spent six months planning a product before building anything. Who spent months optimizing a campaign before measuring results. By the time they shipped, the market had changed. Their assumptions were outdated. They should have shipped faster, learned from the market, and iterated based on real data.

A shipped product, even if it's imperfect, generates data. An unshipped product, no matter how perfect it might be someday, generates nothing. The data is more valuable than the perfection.

Making Done Stick

The hard part is actually stopping when you hit done. The temptation is always to tweak a little more. To optimize a little more. To add one more feature. The discipline is to stop. To declare it done. To move on. This requires an external checkpoint. It helps to have someone else who agrees that done is done and stops you from continuing.

I often take on this role. I'm the one who says "we hit the criteria. This is done. Ship it." The founder wants to keep going. But the project is done. We measure the results. We learn from it. We start the next thing. The discipline of actually completing projects is uncommon and undervalued. But it's the difference between builders who ship and builders who tinker forever.

— Sam

Want me to look at yours?

Send your site. I will review where you are leaking customers and write you a real consultation. Free. No call required.

Request a consultation