Good enough is a strategy

There is a product that does not exist. It lives in a Notion doc, or a Confluence page, or a shared drive folder that someone named "FINAL v3 APPROVED USE THIS ONE." It has been designed. It has been specced. It has been presented to stakeholders in a deck with a roadmap on the last slide, the roadmap showing a series of phases that get progressively vaguer the further right you look, until Phase 3 is just a shape and a date and a vague gesture toward the word "Scale." It has never been used by a single human being.

It is, by every internal measure, nearly ready. It has been nearly ready for seven months. The reasons it is not ready yet are documented, reasonable, and completely unfalsifiable — because the only way to falsify them would be to ship the thing, which would mean it was ready, which would mean the reasons were wrong, and that is not a conversation anyone in the room is prepared to have.

This is not a niche failure mode. This is the default. This is what happens when organisations confuse the absence of imperfection with the presence of value.

Perfect is a feeling, not a state.

This is the thing nobody tells you when you're three months into a build and the designer wants one more round of revisions and the product owner has just thought of an edge case that affects approximately 0.3% of users but which, if unaddressed, will apparently reflect badly on the team. Perfect is the feeling you imagine you'll have when the thing is done. It is always one more thing away. It recedes as you approach it. It is, in the precise clinical sense, a horizon.

The budget does not recede with it. The budget is a fixed line on a spreadsheet somewhere, and it is being consumed at a known rate, and at some point, not announced, not dramatic, just quietly, it will be gone. And the thing will still not be perfect. And the question of what to do next will be answered by accountants rather than product people, which is how you end up with a half-built system in production that nobody owns and everyone uses and which will, eighteen months from now, be described in a business case for a replacement as "legacy."

We have watched this happen. More than once. The slow burn of a project that could have shipped at month four, that waited until month nine, that launched at month eleven into a landscape that had quietly changed while everyone was polishing the corners.

There is a version of "good enough" that is lazy. We should name it, because conflating the two is how the perfectionist wins the argument.

Lazy good enough is shipping something broken and calling it an MVP. It is a form submission that doesn't validate. A mobile layout that nobody tested on an actual phone. A user journey with a step missing because the backend wasn't ready and someone decided to just see what happened. This is not a strategy. This is negligence with a startup vocabulary attached to it.

That is not what we're talking about.

What we're talking about is the discipline (and it is a discipline, it requires more courage than perfection does) of defining what "good enough" actually means before the build starts, and then holding that line when the inevitable pressure to exceed it arrives.

Because it will arrive. It arrives in the form of a stakeholder who has just remembered a requirement. A developer who wants to refactor something that works fine but offends them aesthetically. A manager who saw a competitor's product and wants to know why we don't have that feature, the one that took the competitor two years and a Series B to build.

Good enough is not the absence of standards. Good enough is the presence of a specific, defensible, agreed definition of what this thing needs to do in order to be worth putting in front of the people it's meant to serve. Everything beyond that definition is Phase Two. Phase Two is funded by the evidence that Phase One worked. That evidence only exists if Phase One ships. This is not a complicated argument. It is, somehow, a losing one in most rooms.

Here is what we've seen in public sector procurement, specifically, because public sector has a particular relationship with the concept of done.

A local authority commissions a resident-facing digital service. The service has a clear primary function, let's say it's a form. A form that replaces a paper form. The paper form works. It is slow and expensive and requires someone to manually process everything that comes through it, but it works. The digital version would be faster, cheaper, and would free up three people to do something more useful than data entry.

The digital version, at month six, can do the thing the paper form does. It does it well. It has been tested. Real users have used it. The feedback is good. It is ready.

It does not ship. It does not ship because there are additional features - a case management dashboard, an automated notification system, an integration with a back-office system that the back-office team are also currently replacing - that were included in the original specification and are not yet complete. The specification was written fourteen months ago by people who are no longer in the same roles. The features are not wrong, exactly. They are just not what the residents needed urgently. What the residents needed urgently was the form.

The form goes live at month eleven. By month twelve, the back-office system it was meant to integrate with has changed scope and the integration needs to be rebuilt. The case management dashboard is descoped to Phase Two. Phase Two is not funded yet. The three people who were doing manual data entry have been redeployed. One of them has left.

The form works. The form always worked. The form was ready at month six.

The founders are not innocent in this either.

We've worked with SME founders who have been building their product for two years. Bootstrapped. Serious people, smart people, people who know their market and have genuine insight into the problem they're solving. The product is good. It solves a real problem. There are potential customers who have expressed genuine interest, some of them more than once, some of them with actual budget.

The product is not ready to show them yet.

It's almost ready. There's a feature that needs finishing. There's an onboarding flow that isn't quite right. There's a pricing page that needs copy. There's a legal thing that someone mentioned once that might be an issue depending on how you interpret a particular clause. These things are real. They are not, any of them, the actual reason.

The actual reason is that shipping makes it real. Shipping means the customers can say no. Shipping means the feedback arrives, and the feedback might be that the thing you spent two years building solves a problem that people don't actually have, or have but would prefer to solve differently, or have and want solved but not at that price point. This is not information you can receive before you ship. It is only available after. The longer you wait to ship, the longer you wait to know.

Perfection is a very comfortable place to wait.

The perfect is the enemy of the good. Voltaire wrote it in 1772 and every product team since has nodded at it and then gone back to the revision cycle.

So here is the argument, plainly.

Ship the thing that works. Define "works" before you start, not after. Let the evidence from real users in the real world tell you what Phase Two should be, rather than deciding Phase Two in the same meeting where you decided Phase One. Treat every week between "ready enough" and "shipped" as a week of value destroyed. Not deferred. Destroyed, because the users who needed it didn't have it, and that cost is real even when it doesn't appear on the budget spreadsheet.

And when someone in the room says "but what about…", which they will, ask them one question. Is this something we're adding because users need it, or because we're not ready to find out if they don't?

The answer to that question tells you everything about whether you're building a product or a comfort blanket.

We work with organisations who are ready to ship and don't know it yet. If that's you, if the thing is sitting there, nearly ready, waiting for a sign-off or a feature or a feeling that may not be coming we'd like to talk. It won't be a long conversation. The answer is usually shorter than people expect.