← Writing
xp009The Product DiscoveryMaturity ModelDiscovery isn't one step — it's four stages of escalatingproof. A maturity model that refines…6 min readexperiencefirst.design
096 min read

The Product Discovery Maturity Model

Discovery isn't one step — it's four stages of escalating proof. A maturity model that refines experience-first discovery and zooms into the Discovery phase of the Application Maturity Model.

Most teams treat discovery as a single box on a timeline. Something happens in it — research, sketches, a prototype — and then "real work" begins.

That framing is the problem. Discovery isn't a box. It's a sequence of escalating proof, where each stage answers a harder question than the one before it, and where the cost of being wrong climbs with every step you take.

This is a maturity model for discovery: four stages, four questions, one validated handoff. It builds on the experience-first approach to discovery, and it was written as a companion to a model I owe to a colleague — Vincent van Gameren's Application Maturity Model. More on how the two fit together at the end.


Discovery is a ladder, not a room

Every stage of discovery exists to retire a specific kind of risk. You don't move forward because time passed; you move forward because you answered the question that stage was built to answer.

Skip a rung and the risk doesn't disappear — it just surfaces later, when it's more expensive to fix. A beautiful prototype of the wrong idea is more dangerous than no prototype at all, because it manufactures confidence without earning it.

So the model treats discovery as four stages, each with a single exit question. You don't graduate a stage until you can answer its question honestly.


Stage 1 — Viability

The question: Is it worth doing?

The goal here is strategic alignment and conceptual clarity. Before anyone prototypes anything, you have to know you're solving the right problem.

  • Ideation. Start with a living markdown document that frames the problem, defines the audience, and states the initial hypotheses. AI is a thinking partner here — useful for expanding and reframing ideas, never for deciding which one is right.
  • Stress-testing. Deliberately try to break the idea with a cross-functional group — product, engineering, architecture, sales. The point isn't consensus; it's to find the risks and the market-fit gaps while they're still cheap.
  • Convergence. Force clarity by drafting a PR+FAQ — a press release and FAQ written as if the product already shipped. If the FAQ can't be answered cleanly, the concept isn't ready to advance.

Viability is the rung most teams skip, and it's the one that quietly determines whether everything downstream is wasted. A clean PR+FAQ is the artifact that says: yes, this is worth doing.


Stage 2 — Feasibility

The question: What is the shape of the solution, and where are its boundaries?

Once the idea is worth doing, the goal shifts to defining its shape — without prematurely finalizing the design.

  • Prompt-driven prototyping. Translate the validated PR+FAQ into a structured set of instructions that captures the user flows, the edge cases, and the design constraints. The prompt itself becomes a discovery artifact.
  • Product-owned prototype. Use AI to generate a rough first-pass prototype. This isn't the product — it's a tool to sanity-check the mental model, align stakeholders on what's in and out of scope, and explore options for incremental delivery.

Feasibility is owned by product, not design. The output is rough on purpose: its job is to make scope arguments concrete, not to look finished.


Stage 3 — Usability

The question: Is the experience right, and does it earn user trust?

This is where experience-first stops being a slogan and becomes the work. The goal is to prove the product is desirable, accessible, and coherent end to end.

  • UX-owned prototype. Hand the validated intent and context to the UX team, who build a high-fidelity prototype focused entirely on design-system alignment, consistency, and the full journey — not just the happy-path screen.

The ownership shift matters. Product proved the shape; UX proves the experience. Trying to collapse these two stages into one is how you end up with prototypes that demo well and frustrate in practice.


Stage 4 — Technical Validation

The question: Can we actually build this, and what's the technical scope?

The final stage shifts from conceptual alignment to evidence. Everything before this was about whether the idea is right; now it's about whether it's buildable.

  • Proof of Concept. Engineers use AI-assisted tools to build exploratory code aimed squarely at the riskiest assumptions. A PoC produces "works on my machine" evidence, defines the API contracts, and exposes the limits.

What comes out of this stage is the most important artifact in the whole model: a validated seam — a piece of proven technical reality that the next phase of engineering can build on with confidence.


Where this hands off

This model deliberately stops at the edge of delivery. The validated seam from Stage 4 doesn't go straight into production — and that gap is exactly the point Vincent makes.

In The Missing Phase Between PoC and Production, he describes an Application Maturity Model with three phases:

  • DiscoveryPrototype ("should we build this?") and PoC ("can we build this?"). The purpose is learning.
  • FoundationStructure, Extensibility, Operability. The phase he sees skipped most often: turning everything a PoC taught you into intentional architecture that can evolve without a redesign every few months.
  • ProductionHardening, Scale, Operations. Answering "how do we operate this successfully?"

His sharpest point is that systems rot not because teams start with bad engineers, but because a successful PoC gets mistaken for a production architecture. Foundation is the missing step between the two.

The Product Discovery Maturity Model is a zoom-in on the first of his three phases. Where his Discovery is two moves, this one is four — because experience-first discovery insists that desirability and trust earn their own stage rather than hiding inside "prototype." Everything in this model produces the validated seam that his Discovery phase hands to Foundation.

The validated seam is the join. This model proves what's worth building and what's buildable; Foundation turns that into a sustainable architecture; Production runs it at scale.


Why four stages instead of one box

Because each stage retires a different risk, owned by a different discipline, answered by a different question:

  • Viability retires strategic risk — product and leadership.
  • Feasibility retires scope risk — product.
  • Usability retires experience risk — UX.
  • Technical Validation retires technical risk — engineering.

Collapse them and you blur accountability. You get prototypes that look done before anyone proved the idea was worth doing, or PoCs that prove the tech while nobody checked whether users would trust the result.

There's a deeper reason the model can afford four stages now. For decades, discovery was kept short because building was expensive — every hour spent exploring was an hour not spent writing costly code. Agentic AI inverts that. When implementation gets cheap, the expensive work becomes understanding the problem, proving the experience, and making good decisions — which is exactly what these four stages are for. The same economics that justify Vincent's Foundation phase justify taking discovery seriously.

Discovery done well isn't slow. It's a ladder you climb quickly — but in order, and without skipping rungs. The reward for climbing it properly is a handoff to Foundation that's built on evidence instead of optimism.


Read next: From Discovery to Delivery — where the validated seam meets the systems-first thinking that holds the experience up.