MVP was built for deterministic software. AI products broke that assumption

Minimum Viable Product answers a scope question: what is the smallest set of features that lets you test a hypothesis with real users. It's a scoping tool, and it works because traditional software is deterministic - the same input reliably produces the same output, so once a feature works in testing, it keeps working in production. Cut scope aggressively, ship fast, learn, iterate.

Generative AI features don't behave that way. The same prompt against the same model can produce a correct answer, a subtly wrong one, or a confidently wrong one, on different runs. That means an AI feature doesn't just have a scope question ("what does it do") - it has a quality-floor question that traditional MVP scoping never had to answer: how often is this allowed to be wrong, and what happens when it is. Minimum Viable Quality (MVQ) is the name for that second gate.

MVP and MVQ are not competing frameworks - they answer different questions and a real AI product needs both. MVP decides what's in scope. MVQ decides the quality bar that scope has to clear before shipping it does more good than harm. Skipping MVQ doesn't make an AI feature ship faster; it makes the failure mode happen in production instead of in testing.

Defining your MVQ bar: four questions before you write a line of code

What does "wrong" look like here?

A wrong summary is annoying. A wrong dosage suggestion, a wrong invoice total, or a wrong legal citation is a different category of wrong. Classify your feature's failure modes before you pick a quality threshold - the threshold should scale with the cost of being wrong.

How will you measure it, not just eyeball it?

"It felt pretty good in testing" is not a quality bar. Build a small labeled eval set (50-200 real or realistic inputs) and score outputs against it on a metric that maps to your actual failure mode - accuracy, hallucination rate, refusal rate, or a task-specific rubric.

What's the fallback when the model is wrong?

MVQ isn't only about raising the model's hit rate - it's often cheaper and more reliable to lower the blast radius of a miss: human-in-the-loop review for high-stakes outputs, confidence thresholds that trigger a fallback, or explicit "I'm not sure" states instead of a confident guess.

How will the bar move after launch?

MVQ is a floor at launch, not a permanent ceiling. Decide up front how production outputs get sampled and reviewed post-launch, so the eval set - and the bar - improves with real usage instead of staying frozen at your pre-launch guess.

A worked example: an AI support-ticket triage feature

Say you're building a feature that reads an incoming support ticket and suggests a priority level and routing team. Here's how MVP scoping and MVQ gating work together on the same feature, rather than as separate projects:

  • MVP scope: handle English-language tickets only, suggest one priority level and one routing team, no auto-routing yet - a human confirms before it moves.
  • MVQ bar: on a labeled set of 150 real historical tickets, the suggested priority must match a human triager's actual decision at least 85% of the time, and it must never suggest "low priority" for a ticket a human labeled "urgent" (a false-negative-on-urgency rate of zero, since that's the failure mode that actually causes harm - a slow response to a critical issue).
  • Fallback: below a confidence threshold, the feature shows "needs manual triage" instead of a low-confidence guess - it degrades to today's baseline instead of guessing badly.
  • Post-launch loop: every week, sample 20 production suggestions a human overrode, add the disagreements to the eval set, and re-run the bar.

Notice that the MVP column ships something narrow and useful in days. The MVQ column is what keeps that narrow feature from becoming the reason a genuinely urgent ticket sits unrouted for six hours - and it took one afternoon of defining a threshold and building a small eval set, not a research project.

MVQ is not the same as "add more guardrails"

A common mistake is treating MVQ as an excuse to bolt on generic safety filters and call it done. Real MVQ work is specific to your feature's actual failure mode, not a one-size-fits-all checklist:

A content-generation feature's MVQ bar is mostly about tone, factual grounding, and brand-safety language. A financial-calculation feature's MVQ bar is mostly about numerical correctness and units. A routing/classification feature's MVQ bar is mostly about the cost-asymmetry of different wrong answers (as in the triage example above). Applying the wrong bar to the wrong feature wastes eval effort on risks that don't actually apply and misses the ones that do.

How this connects to defensibility

MVQ isn't only a shipping-safety practice - it compounds into the moats that actually hold up for AI products (see our companion piece on AI moat and defensibility). A disciplined eval-and-fallback loop is exactly the mechanism that turns raw usage into a real data flywheel: every override, correction, and "needs manual review" case is labeled data that makes the next version's MVQ bar higher, cheaper to hit, and harder for a competitor without that same feedback loop to match.

Key takeaways

  • MVP defines scope. MVQ defines the quality bar that scope has to clear before it's safe to ship - AI products need both, not one or the other.
  • Classify your feature's failure modes and let the cost of being wrong set the bar, rather than picking one generic accuracy number for every feature.
  • Build a small labeled eval set before launch - 50 to 200 real or realistic inputs is enough to start measuring instead of eyeballing.
  • Design an explicit fallback for low-confidence outputs; lowering the blast radius of a miss is often more effective than chasing a marginally higher hit rate.
  • Treat the eval set and the bar as living artifacts that improve from production disagreements, not a one-time pre-launch checklist.
Shipping an AI feature and not sure where to set the quality bar? That's a focused, one-conversation problem to solve before launch - not a multi-month research project.