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 iteration was slow.
Building is cheaper now. The goal is not to finish once. The goal is to become useful quickly and keep getting more useful as the work changes.
The Shift
Done thinking: “We need a complete solution before anyone can use this.”
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 output, do not look only for one thing that makes you twice as good. Find many things that each make the work a little better.
They are easier to find, easier to implement, and easier to correct. They compound.
1.01^100 = 2.7x
A hundred 1% improvements nearly triples output. Each one can be useful on its own.
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 considering. You do not need a complete solution to start solving the problem.
The goal is not 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.