The MVP that paid for itself in six months

There is a specific moment when a digital transformation programme dies. It is not the moment the budget gets cut. It is eight months earlier, when someone decides the first release should cover "the full journey" — and the finance director quietly stops asking how it is going.

I have watched this happen, and I have watched the alternative work. The alternative is boring and it is this: make your first release generate money while it is still visibly incomplete.

Revenue is the only slice that survives contact with the org chart

Every organisation has a portfolio of digital ideas ranked by how exciting they are. That ranking is almost never the right build order. The right build order is: which of these produces a number that a non-technical executive can repeat in a meeting?

When I scoped an online booking flow for a business that had run entirely on phone calls and spreadsheets, the exciting version included dynamic pricing, a loyalty tier, and a mobile app. The version we shipped did one thing: let a customer reserve and pay online without a human touching the request.

It was missing most of what people asked for. It also produced real revenue inside the first six months, which changed the conversation permanently. After that, nobody asked whether the programme was worth funding. They asked what was next on the roadmap.

What "MVP" actually has to mean

The word has been diluted into "version one, but rushed." That is not it. A useful MVP has three properties:

• It closes a loop. Someone outside the company can start and finish something of value without internal intervention. Half a loop is a demo.
• It has a number attached before you build it. Not a vanity number. Revenue booked, hours removed, errors avoided. You commit to the number in advance so the result is not up for interpretation.
• It is embarrassing in ways you chose. You should be able to list what is missing and why each thing was deferred. If you cannot, you did not scope — you ran out of time.

The hardest part is not technical

Shipping a thin slice means telling stakeholders their feature is not in release one. That conversation is the actual work of product management, and no framework does it for you.

What helps is giving people a mechanism instead of a promise. "Not in this release" lands badly. "Here is the roadmap review where we re-rank based on what release one teaches us, and here is the date" lands fine — as long as the review actually happens and the ranking actually changes.

The credibility you build by shipping something small and true is the currency you spend to build something large.

The compounding effect

The second release of that booking system was easier to fund than the first. The third was easier still, and by then we were adding capabilities that would have been laughed out of the room during the initial business case — because the business case was no longer a projection. It was a report.

That is the whole argument. Not that small is better than big, but that proof is cheaper than persuasion, and shipping is the only way to buy it.