For most of my career, I treated “finished” as something that happened at the end of a process – a period, not a decision.
When a project wasn’t quite done, the common reflex was to keep going: add another module, revise that section, improve the visuals, respond to feedback, optimise for visibility.
In that world, “finished” was less a destination and more an aspiration you never quite reached.
It took several incomplete projects for me to notice the pattern: things rarely finish because nothing ever decided they should.
The work simply accumulates. It stays alive because there’s always something that feels worth improving, or worth defending.
It wasn’t until I was building Info Product Build that I began to treat finished as a choice, a design decision made early and respected consistently.
That shift didn’t come from a checklist, a framework, or external advice. It came from recognising the pattern in unfinished work and how it had become psychological baggage in my own process.
Designing for finished means asking a different question up front:
What would this need in order to be truly done?
Not “What else could be added?” Not “How might this evolve?” Not “What happens after launch?” But:
Where, exactly, does this stop? And what would make that stop feel sufficient?
Once you ask that, so many other pressures fall away.
- Scope becomes something you define, not something that drifts.
- Revision stops being a default and becomes a conscious choice.
And the project, for the first time, lives inside a frame that can actually contain it.
Of course, there’s tension in that.
Defining edges invites the question: What if I’m shutting down too soon?
It takes practice to hold a boundary without second-guessing it.
But over time, I found that the quality of the work improved precisely because it wasn’t subject to constant iteration.
Finished is not an outcome that arrives at the end of effort. Finished is a decision you make at the beginning, and honour every step thereafter.
This idea, of choosing finished, became the backbone of how I approached every major decision in Info Product Build.
