Useful, Not Done
“Done” is a waterfall concept. Useful is continuous.
The traditional model: define requirements, build the thing, ship it, move on. The goal is completeness. You’re either done or you’re not.
This made sense when building was expensive. You had to get it right because you couldn’t afford to iterate.
Building is cheap now. The goal isn’t to finish — it’s to be useful as fast as possible and stay useful as things change.
The Shift
Done thinking: “We need to build a complete solution before we can launch.”
Useful thinking: “What’s the smallest thing we could ship today that someone would actually use?”
Done is binary. Useful is continuous. You can always be more useful, and you can start being useful immediately.
Why This Matters
Every workflow has a hundred small frictions.
“Where’s that file?” “What were the requirements on the last one?” “Did we do something like this before?” “What’s the deadline?” “Who’s the right person to ask?”
Each friction costs minutes. Some cost hours. Many happen multiple times a day.
You don’t need to build a system that eliminates all of them. You need to start eliminating them, one by one, continuously.
Remove one friction: useful. Remove ten: more useful. Remove a hundred: transformed.
The Math
If you want to double your output, don’t look for one thing that makes you twice as good. Find a hundred things that each make you 1% better.
Easier to find. Easier to implement. Less risk you’ll get it wrong. And they compound.
1.01^100 = 2.7x
A hundred 1% improvements nearly triples your output. And each one is useful on its own, from day one.
What This Enables
When “done” isn’t the goal, you can:
- Ship something rough that works and improve it based on real usage
- Pivot when you learn the problem is different than you thought
- Stop investing when something is “useful enough” and move to the next friction
- Run multiple small experiments instead of one big bet
The question changes from “is it ready?” to “is it useful yet?”
Implication
Stop waiting for done. Start shipping useful.
Every small improvement that helps someone do their job better is worth deploying. You don’t need permission to be useful. You don’t need a complete solution to start solving problems.
The goal isn’t a finished product. The goal is continuous usefulness that compounds over time.
Contrarian To
“We can’t ship until it’s complete.”
Completeness is a mirage. Requirements change. Users surprise you. The world moves on. Ship useful, learn, iterate. Continuous usefulness beats theoretical completeness every time.