Product and MVP Engineering

Design it, prove it, then build it to last.

Talk to us
Runs against
One hypothesis, then one product
Each stage
Can end the work, on purpose
You get
A tested concept and an architecture that bends

Three ways products fail between idea and second release

Most products fail somewhere between the idea and the second release: the concept was never tested with a customer, the MVP became the architecture, or the architecture could not absorb the first real change.

They are three different failures and they want three different answers, but they share a cause — a decision taken at the stage where it was cheap to test, and tested at the stage where it was expensive to undo. The prototype that nobody showed a user becomes the MVP’s spec. The MVP built to answer one question becomes the production system by default, because it was there.

So we run the work as four stages with a real gate between each, and the gates are allowed to stop it.

Four stages, with a gate that can stop the work Work moves down four stages: a hypothesis, a prototype tested with users, an MVP, and finally a system built to last. A gate sits between each pair, asking in turn whether the hypothesis is still true, whether users wanted the thing, and whether the design will absorb change. A scale down the left shows that being wrong is cheap at the top and expensive at the bottom, which is why the early gates have to be real ones. The star marks the prototype tested with users: a tested concept, which you keep. Find out early, while it is still cheap Hypothesis Prototype with users MVP A system that lasts The MVP is a question, not a version one. cheap expensive is it still true? did users want it? absorb change? Four stages, with a gate that can stop the work Work moves down four stages: a hypothesis, a prototype tested with users, an MVP, and finally a system built to last. A gate sits between each pair, asking in turn whether the hypothesis is still true, whether users wanted the thing, and whether the design will absorb change. A scale down the left shows that being wrong is cheap at the top and expensive at the bottom, which is why the early gates have to be real ones. The star marks the prototype tested with users: a tested concept, which you keep. Find out early, while it is still cheap Hypothesis Prototype with users MVP A system that lasts The MVP is a question, not a version one. cheap expensive is it still true? did users want it? absorb change?
The gates are the product. A stage that cannot end the work is not a gate, it is a milestone, and a milestone has never stopped anyone building the wrong thing.

How the engagement runs

Four stages, each ending in something you keep — including, at the early ones, a decision not to continue. No weeks are attached: each stage is gated on what the last one learned, and a fixed calendar would contradict the method.

  1. Stage 1 Frame The hypothesis, the customer it is about, the one thing the product has to prove, and — the part usually skipped — the result that would tell you to stop. You get: a written hypothesis with a kill criterion against it.
  2. Stage 2 Prototype and test Something clickable in front of real users, built to be thrown away. This is the stage where being wrong is cheap, which is the entire reason it exists. You get: what users actually did, as distinct from what they said they would.
  3. Stage 3 MVP Only the features that test the hypothesis, shipped to real users. Scope is set by the question, not by the wishlist, and the wishlist is written down rather than argued with. You get: a product in front of users, and an answer to the question.
  4. Stage 4 The system that outlives it The architecture that absorbs the first real change instead of being rewritten by it — microservices where a boundary is real, and not where it is decorative. You get: a decision record per boundary, so the second release is a change and not a rewrite.

How the work is run

  • A hypothesis with a kill criterion Written before the work starts, because a hypothesis that cannot be falsified is a plan with a research costume on.
  • Research with users, not stakeholders The people who will use it, doing the thing, rather than the people who commissioned it describing it.
  • Design built to be discarded, then kept Disposable at stage two and durable at stage three, which are different briefs and should not be the same file.
  • Scope set by the question Features that test the hypothesis ship; features that do not are recorded and deferred rather than negotiated in.
  • A decision record per boundary Why each architectural seam is where it is, so the next team can move it deliberately instead of discovering it.
  • Microservices where the boundary is real Distribution is a cost paid for independence. Where there is no independence to buy, we do not pay it.
  • Access to real users, arranged first Five of your actual customers, booked before stage two starts. This is the thing that quietly does not happen, and when it does not, the prototype gets shown to colleagues and the hypothesis stays untested.

And the caveat under all of it: a gate only works if someone can afford to use it. A kill criterion written by the people who want the product to exist, and reviewed by the people whose budget depends on it, will be reinterpreted rather than applied. So stage one names who holds each gate and what happens to them if they close it. If that person does not exist, the gates are decoration and we would rather say so at the start than discover it at stage three.

What you leave with

  • The hypothesis and its kill criterion — and the record of which way it went.
  • What users did with the prototype — observations, not a satisfaction score.
  • An MVP in front of real users — scoped to the question it was built to answer.
  • Decision records per boundary — the thing that makes the second release a change rather than a rewrite.

How you will know it worked

We have not published a method for product engineering, and we will not cite ourselves as though we had. What we do argue in public is how build quality should be measured, and it applies here directly: cost per accepted pull request rather than per generated line, counting reviewer minutes, rework, rollback rate and time to merge.

The discipline the first stage asks for is one we do argue in public, about a different kind of work. We say an agent system should start from a measurable outcome rather than from a model, written as a contract that names the acceptance test and the condition for stopping — because that is more durable than a prompt and easier to review with a business owner. A hypothesis with a kill criterion is the same document, for a product instead of an agent.

The honest test of stage four is slower and simpler: when the first real change arrives, is it a change or a rewrite? Nobody can tell you that at the start, which is why the decision records matter more than the assurances. What happens next is a different question with its own answers — Cloud Operations for the delivery path the product then needs, and GitOps Operations if you want it described in Git.

Tell us the one thing your product has to prove, and what result would make you stop. If the second half has no answer yet, stage one is the conversation.

Talk to us

Related services

Cloud-Native Engineering

Cloud Operations

Accelerate your product development and delivery with our expert DevOps services.

Tell me more
Cloud-Native Engineering

GitOps Operations

Streamline your application management with our GitOps services.

Tell me more
Cloud-Native Engineering

Migrate to Cloud

Seamlessly migrate to the cloud with our expert guidance and support.

Tell me more