Beyond MVP: Why Minimum Viable Quality (MVQ) Is Needed in the Age of AI

I’m always hesitant to propose a new framework. Product management and consulting are already drowning in them. Every week there’s a new canvas, a new acronym, a new two-by-two matrix promising to unlock growth. I’m not naive enough to think I’ve discovered “the answer”.

But here’s the thing: building AI products has consistently left me scrambling for something. A lens, a model, a shared vocabulary to help align product, business, and technology teams on decisions that traditional frameworks don’t quite address. After running workshops with dozens of teams and shipping AI features across industries, I think there’s a gap worth filling. Not because I want to add to the noise, but because I keep watching teams struggle with the same unanswered questions: how do we know if this AI product is good enough to ship? How do we evaluate quality, cost, feasibility, ethics, and user value?

This article introduces a framework I call Minimum Viable Quality (MVQ). It’s a practical approach to finally bridge the language of responsible AI with commercial outcomes, and to help product teams make better decisions about what to build, when to ship, and how to optimise.

If you’ve built products before, you know the MVP (Minimum Viable Product) playbook by heart. Ship fast, test assumptions, iterate based on feedback.

MVP is both a framework and a mindset. You’ve probably heard non-product people say “let’s just do an MVP”, usually meaning “let’s cut corners and ship something half-baked.” But true MVP thinking is rigorous. It forces you to answer hard questions:

• Is it desirable? Will users want this?

• Is it feasible? Can we build it?

• Is it viable? Does it make business sense?

These questions, championed by pioneers like Marty Cagan and the Lean Startup movement, have worked brilliantly for decades. You test desirability with prototypes, validate feasibility with technical spikes, and model viability with unit economics.

But here’s where traditional MVP thinking starts to break down. AI products are probabilistic, not deterministic.

Let me show you what I mean.

If you design a support ticket form, you can map out the entire user journey. User fills form, clicks “Submit”, ticket is created, routed to agent, resolved. The behavior is predictable. Every time someone clicks “Submit,” the same thing happens.

Now insert a GenAI chatbot into that flow.

You can steer it with prompts. You can add guardrails. You can fine-tune it on your data. But you will never know with 100% certainty whether it will hallucinate a policy, give incorrect advice, or, in rare but real cases, say something that violates laws and regulations.

The risks are higher, and the probability space is unlimited.

Think about this example:

Engineer: “We can ship next week with a chatbot achieving 75% accuracy.”
Legal: “What does 75% mean for liability?”
Support: “75%? So we’re going to be wrong 25% of the time?”
Finance: “What will it cost us to be wrong?”
Exec: “What will it gain us to be right”
Everyone: stares at each other

The problem wasn’t that the product was undesirable or infeasible. The problem was that we hadn’t agreed what “good enough” meant for a probabilistic system. That gap, between ‘we can build this’ and ‘we should ship this’, is what Minimum Viable Quality addresses. It’s not about replacing MVP thinking. It’s about adding a lens that helps you answer questions MVP wasn’t designed to solve.

Let me be clear upfront: MVQ doesn’t replace MVP thinking. It enhances it.

MVP asks: “What’s the smallest thing we can build to test our hypothesis?”

MVQ asks: “What quality threshold must we hit before this creates value instead of harm?”

Think of it this way. MVP is about scope and learning velocity. MVQ is about quality gates and acceptable risk. For deterministic products, MVP was often sufficient because quality was binary. The button works or it doesn’t. For probabilistic products, where the same input can produce different outputs, you need both lenses.

Desirability + MVQ = “Will users want this at this quality level?”

Feasibility + MVQ = “Can we build it to the quality threshold needed?”

Viability + MVQ = “Are the economics sustainable at this quality?”

MVQ isn’t a new framework. It’s a lens that helps you make better decisions within the frameworks you already use.

Here’s the thesis. AI products require a way to assess quality that bridges technical capabilities and business requirements.

In traditional software, this bridge existed naturally. Engineering says “it works” and everyone understands what that means. Design says “users like it” and we have usability metrics. Business says “it’s profitable” and we have unit economics.

But when you’re building with LLMs, this bridge collapses.

Engineering says: “The model achieves 80% accuracy on our test set.”
Everyone else hears: “I have no idea if 80% is good, bad, or catastrophic.”

Business says: “We need to reduce support costs by 30%.”
Engineering hears: “I don’t know what quality level achieves that.”

Legal says: “We need to be GDPR compliant.”
Engineering hears: “What does that mean for model explainability?”

MVQ creates a shared language. It forces the question: what quality is acceptable, why, and how will we measure it?

Once you answer that, everything downstream becomes clearer. Model choice? Do we need reasoning capabilities (expensive, high quality) or fast inference (cheap, medium quality)? Technical architecture? Do we need RAG for citations, or is prompting sufficient? UX design? How do we handle confidence thresholds? When do we escalate to humans? Go/no-go decisions? Are we ready to ship, or do we need more optimisation?

The real power of MVQ isn’t the metric. It’s the conversation it forces.

Let me show you what I mean with a real example from my consulting work (details anonymised).

The initial pitch was simple. “We want an AI chatbot to handle Tier 1 support queries. We have an OKR from the board to save 40% on support costs this year.”

I ran a 90-minute workshop with product, engineering, support ops, legal, and the CFO. Here’s what emerged.

Me: “What does ‘handle’ mean? What’s acceptable quality?”

Support Ops: “Our human agents resolve 80% of Tier 1 queries on first contact. If AI can match that, I’m happy.”

Legal: “We can’t have it inventing policies. If it hallucinates even some of the time, we have regulatory risk and we won’t sign off on this.”

Me: “It will be impossible to remove hallucinations, but what we really want to understand is quality. Surely humans get it wrong right now? Would we be happy if it met or exceeded the same 80% resolution rate as your human agents?”

Engineering: “We think the base model in our MVP has 65% accuracy. We can probably hit 75% if we add RAG. 80% would require fine-tuning and another three months.”

CFO: “What’s the cost difference between 75% and 80%?”

Engineering: “75% costs £0.15 per query with RAG. 80% costs £45K upfront for fine-tuning, but drops to £0.08 per query.”

Me: “So the question is: Is 75% first-contact resolution at £0.15/query acceptable, or do we need 80% and can we justify the upfront investment?”

Thirty minutes of productive debate followed.

The final MVQ decision:

• Primary Metric: First Contact Resolution ≥ 75% (acceptable given escalation path exists)

• Secondary Metric: Hallucination rate < 1% (legal requirement)

• Tertiary Metrics: Escalation time < 30s, user satisfaction > 4/5

• Go/No-Go: Ship when we hit 75% FCR + <1% hallucination for 2 consecutive weeks on 100-user pilot

• Optimisation Plan: Launch at 75%, monitor closely, invest in fine-tuning to reach 80% if ROI justifies it

See what happened? MVQ didn’t give us the answer. It gave us a framework to have the right conversation. One that connected technical capabilities, business economics, legal requirements, and user expectations.

Crucially, MVQ helped us overcome the legal hurdle of “we won’t sign off on this”. By establishing what the Minimum Viable Quality is, you can work backwards and have a productive debate on feasibility, viability, and desirability.

Right, let’s make this practical. Here’s the process I use.

MVQ isn’t a solo decision. You need:

• Product (you): understand user needs and business goals

• Engineering: understand technical feasibility and cost

• Domain experts (support ops, clinicians, lawyers, etc.): understand acceptable quality in context

• Legal/Risk: understand regulatory and liability requirements

• Finance: understand economic constraints

Before you set MVQ, understand what “good” looks like today.

Questions to ask:

• What’s the current human performance? (e.g., “Support agents resolve 80% first-contact”)

• What’s the current cost? (e.g., “£5 per support ticket”)

• What are the current failure modes? (e.g., “Long wait times, inconsistent answers”)

• What do users expect? (e.g., “Instant response, 24/7 availability”)

Document this. You’ll reference it constantly.

Not all “quality” is the same. For AI products, I typically track:

1. Task Performance – Does it complete the core job? (e.g., FCR %, accuracy, value)

2. Faithfulness – Does it invent facts or hallucinate?

3. Relevance – Does it answer the question asked, or go off-topic?

4. Safety – Can it produce harmful, biased, or inappropriate outputs?

5. Latency – Is it fast enough for the use case?

6. Cost – Is it economically sustainable?

Pick 1-2 primary dimensions (what you optimise for) and 2-3 secondary dimensions (what you monitor as guardrails).

This is where the magic happens. Bring your stakeholders together and ask: “Given our baseline and our constraints, what’s acceptable?”

Example conversation starters:

• “Our human team achieves 80% FCR. If AI does 60% but costs half as much, is that acceptable? If it isn’t acceptable, what if the cost were reduced 80%? 90%? 99%? Is there ever a time this quality from an AI system would be acceptable?”

• “If we want to match human performance at 80%, it’ll cost £100K and take four months. Is that viable?”

• “Legal needs <1% hallucination rate. Engineering says we can hit 0.5% with RAG. Is that sufficient?”

Don’t pull numbers from thin air. Ground them in human baseline performance, user expectations (sometimes higher than human!), regulatory requirements, and economic constraints.

This is the artefact that makes MVQ real. It’s a one-page document that captures your agreements.

Here is a sample (courtesy of Claude), but in reality you can use any system you already use (Miro, PowerPoint, Slides, Confluence, etc.) as long as you articulate on a single page:

• What your feature/product is

• What are your quality dimensions and thresholds

• How you will measure quality

• What good looks like

• How you will escalate/check/review

• And get signoff from multiple stakeholders

Note: I am going to work on compiling a series of templates/artefacts for this as part of a future article. Watch this space!

Here’s what I hope becomes standard for every AI PM.

Before you write a single line of code, before you pick a model, before you design a UI, sit down with your stakeholders and fill out an MVQ Card.

It will force you to answer:

• What does “good enough” mean for this use case?

• How will we measure it?

• What’s our go/no-go criteria?

• What’s our optimisation strategy?

These aren’t “nice to have” questions. They’re existential.

I’ve reviewed dozens of AI product launches. The ones that succeed have MVQ clarity from day one. The ones that fail, the Chevy chatbots, the Air Canada debacles, skipped this step.

“This sounds like a lot of upfront work. Won’t it slow us down?”

Yes, it’s upfront work. No, it won’t slow you down. It’ll speed you up.

Here’s what happens without MVQ:

1. Build for 6 weeks

2. Launch

3. Realise quality is too low

4. Scramble to fix

5. Rebuild for 4 weeks

6. Re-launch

7. Total: 10 weeks

Here’s what happens with MVQ:

1. Define MVQ (1 day workshop)

2. Build to MVQ (6 weeks, but you know when you’re done)

3. Launch confidently

4. Total: 6 weeks, 1 day

“What if we don’t know what quality we need?”

Then do research. Talk to users. Benchmark competitors. Run a small pilot.

But don’t ship without answering this question. The market will answer it for you. Loudly, publicly, and expensively.

“Can’t we just set quality to 100% and be safe?”

No. For two reasons.

First, economics. Higher quality costs more (better models, more data, more compute). Sometimes 80% at £0.10/query is smarter than 95% at £2/query.

Second, time-to-market. Perfection is slow. If 75% quality unlocks value and has safe fallbacks, ship at 75% and optimize from there.

MVQ isn’t “make it perfect.” It’s “make it good enough to be safe and valuable.”. Remember, MVQ is to be used WITH MVP. Ultimately, we still need to fail fast, validate, and ensure we are iterating quickly.

MVQ doesn’t replace the foundational PM frameworks we know and love, nor should it feel like a burden. In many ways, Product Managers should already be used to the core concept of MVQ, even if they haven’t deliberately practised it.

It’s a lens that helps you bridge technical conversations (accuracy, latency, cost) with business conversations (ROI, risk, user satisfaction).

Most importantly, it creates a shared language for your cross-functional team to align on what “good enough” means before you build, and how to optimise systematically after you ship.

My challenge to you: next time you’re scoping an AI feature, don’t ask “what features should we build?” first.

Ask “what quality must we hit, why, and how will we measure it?”

Fill out an MVQ Card. Run a workshop. Get alignment.

I think you’ll find that the hard conversations you have upfront will save you from painful ones later.

And honestly? I hope that in five years, we (as a product community) can have some really robust conversations about what quality means in the age of AI (especially considering AI slop) and I hope MVQ can be a core part of that conversation.