Minimum Viable Product in the AI Era: The AAC Technique Moved

A minimum viable product (MVP) is the smallest thing you can put in front of real customers to test a hypothesis. The Agile Extension to the BABOK Guide describes it as technique 7.6, and the AAC exam still tests it.

Did the technique stop working? I think no. What changed is the price. Building now costs far less. So the hard part moved from engineering to selling, marketing and judgement.

Last verified: October 2026.

I have been on three MVPs: certificate.tips (this site), an applicant tracking system (ATS), and a social network for Australian universities. Each time in a different role. Below is what the standard says, what I saw in practice, and where the two no longer match.

What the Agile Extension says about MVP

The Agile Extension treats MVP as a way to avoid building the wrong product: you test a hypothesis with real customers first [1]. The guide says "Minimal Viable Product". Most of the industry says "Minimum". Same technique.

In my words, the guide gives the technique a purpose, three steps and four elements:

What do I take from this section? Not the strengths. The limitations. There is no formula for the right feature set. For a simple, clear solution the MVP may be the whole product. And the line I like most: MVP is not about creating a product, it is about testing a hypothesis.

More on experiment design: MVP and experiment design.

Why MVP matters for the AAC exam

The AAC exam is built on the Agile Extension, and MVP is one of its techniques. The exam has 85 scenario-based questions in two hours, and roughly 30 of them are about techniques [2]. The full breakdown is in our AAC exam guide.

Questions on MVP usually check three things:

1. An MVP tests a hypothesis. It is not "version 1.0 with fewer features".
2. Success criteria are set before the MVP is released.
3. The next step depends on validated learning, and stopping is one of the options.

MVP lives mostly at the Initiative horizon: it helps you decide whether an initiative should go on at all. If the horizons are new to you, read Agile Extension horizons: strategy vs delivery.

The technique did not change. The price did.

The steps in the guide are still right. What changed is which resource is scarce.

When the classic MVP books were written, the scarce resource was engineering. Developers were expensive and slow to hire. Every feature cost weeks. So the craft of MVP was to fake as much as possible: a button that does nothing, a landing page with no product behind it, a person pretending to be an algorithm.

Even in 2013 two authors wrote that it is "vanishingly cheap to create the first version of something" [4]. AI coding assistants cut the cost by another order of magnitude. A person with an idea and no engineering background can now build a working product alone. One practitioner built a SaaS in Replit without writing code and says a similar project now takes days rather than months [13].

What is scarce then? Not hands that write code. Heads: knowing what to build, for whom, how to sell it and how to get it in front of people.

Which minimum viable product types lost their point

Some MVP types existed only because building was expensive. When building is cheap, a fake costs almost as much as the real thing. And it also costs you trust.

The last row is the one I believe in most. The Lean Startup tells the story of a company that served its first customer with no software at all, then a second, then a third, learning each week [3]. Today you do not need to stay manual for long. Find one person with a real problem. Solve it. See that they pay. Use what you learned as the base of the product. Software catches up in days, not quarters.

My three MVPs

Three MVPs, three roles. Each one taught me something the standard does not say directly.

certificate.tips: the MVP I thought nobody needed to market

certificate.tips started as an experiment of two people. The only money spent was the domain, about 10 dollars a year. Hosting and the rest of the stack ran on free tiers. Our own AI subscriptions I do not count: you pay once and build ten products with them.

What was our hypothesis? Honestly, I cannot write it down. It was more a belief, and I still hold it: companies that sell exam question banks charge a lot for what they give. Is that true? Here is what I found when I checked prices this month:

The picture is mixed, and I want to be fair. Scrum.org practice banks can be cheap. For IIBA exams, a month of access costs from about 25 to 99 dollars. And price is not my only problem. When the bank is small, at some point you start remembering the answers. Then the practice stops measuring anything. certificate.tips is our product, and right now all its simulators are free.

From idea to the first version with questions took months, not weeks. We were inexperienced vibe coders, used weak models for design and code, and had no process for producing questions. Today I think the same could take days.

What would I do differently? Three things.

1. I cut too much. I followed the classic rule: cut every corner so users see something sooner. Is this rule still right for a small team with AI? I think not. A product thought through to the details is cheap to build. So cutting corners saves little and costs first impressions. A corporation is different: most of the work there is process, not code, and the old rule still holds.
2. I did not learn the tool first. AI sped up code and content a lot. But I am not an experienced developer, and once I opened a pull request of about 6,000 lines. That is not a review, that is a punishment for my partner. A study of a Cisco team found that defect detection drops beyond 400 lines of code per review [11]. So AI did not remove the bottleneck. It moved it to review. Today I discuss design with the model and with people, and I use skills instead of trusting the first output.
3. I believed the product would be interesting by itself. The classic founder mistake. Product people I learned from repeat it constantly: nobody wants to come to your product, they want their problem solved. I knew the principle and still fell for it. Knowing about a bias does not protect you from it.

What do I measure now? Registrations, as the main success signal. And retention: did a registered user start an exam and come back? Most users who came spent more than one day in the product, and many stayed for 5 to 10 days. A good sign. The problem is that there are few of them. Which is exactly why this article exists.

An ATS: an MVP for one customer that was sold before it was finished

The second MVP was an ATS for blue-collar workers. My role was a mix of product manager and product operations manager. I helped the founders turn their vision into concrete features and helped the team understand those features. The tools were ordinary business analysis techniques.

The team was five people: a CEO with the vision and the search for investors, a CTO with the technical veto, two developers, a salesperson who also did marketing, and me.

We built the MVP and sold it at the same time:

1. The salesperson found a warm lead.
2. We sold the lead a paid pilot of the ATS itself.
3. We connected their accounts, and the pilot customer felt the value from day one.

The ATS is an AI product. So the price had to cover the cost of the model that talks to candidates. The classic MVP books never had this constraint: your MVP has a variable cost per conversation.

Many parts were left out of the code on purpose. For example, there was no AI setup of the customer profile. Instead, the salesperson and the CEO onboarded each customer by hand and wrote custom prompts for them. In the language of the guide, this is a concierge MVP for one customer, with the understanding that many customers will follow.

The niche was narrow on purpose: logistics companies in a specific region of Eastern Europe. The ATS got paying customers, and one of them signed an annual contract.

What did the ATS change for me? My definition of MVP. An MVP is not about producing software faster. It is about checking whether the sale will happen.

A social network for Australian universities: what an MVP should not be

Formally I was the business analyst. In practice I was closer to a product manager who helped the founder put his thoughts in order. With elicitation techniques I separated what he really wanted from what he said. We even moved the strategy from B2C to B2B.

The MVP here was a real, fully built product. It was made before AI coding existed, when building was expensive. The founder fell in love with his idea and came to an outsourcing company with money ready to spend. The classic mistake from every startup book. And not only a founder's mistake: product managers do the same with their own features and then refuse to believe the features failed.

One more lesson. If you have money and want an MVP, is an outsourcing company the right place? I think no. Outsourcing exists to sell as many hours as possible, not to produce software fast. Nobody did anything wrong there. The business model simply points the other way.

What worked: we understood the users, found people who could champion the product, and the founder knew his domain very deeply.

Where the bottleneck moved

When building becomes cheap, the bottleneck moves to marketing and distribution. I see it on certificate.tips, and other builders say the same:

• A small business owner who built his SaaS with AI writes that getting users is ten times harder than building the product [13].
• A security engineer argues that when building is cheap, distribution "becomes destiny" [14].
• An indie builder for local businesses puts it shorter: coding was never the real bottleneck [15].
• A vibe coder on a maker forum describes the trap: building feels so rewarding that you keep polishing and postpone marketing [16].

Let's look at it through a different lens: a large company. At my current job, QA was always slower than development. AI sped development up again, and the gap grew, even though QA also got faster. So in a big company AI does not remove bottlenecks. It reveals new ones or makes the old ones stronger.

From minimum viable to minimum lovable product

A minimum lovable product (MLP) is a first version that early users love, not just tolerate. The term was popularised in 2013 by a product software founder. He argued that "barely enough" produces products that work but do not delight [5].

My own definition of MVP was always closer to this. What does "viable" mean? Not a product that merely survives. A product that has found its niche and already took something inside it. The ATS niche was logistics companies in one region. Small, and that is the point.

Why does MLP fit better today? If a polished version costs the same few days as a rough one, the rough one saves nothing and gives a worse first impression. The risk is on the other side: "lovable" can turn into months of polishing with no contact with customers. So the test is simple: are real people using or paying for it this month?

Related ideas worth knowing:

• Riskiest assumption test (RAT): test only the one assumption that would kill the product. See riskiest assumption testing.
• Minimum marketable product (MMP): the smallest product you can actually sell to a market, not just test.
• Minimum marketable feature (MMF): the same idea applied to one feature.

New forms of a product

A solo builder is no longer limited to a web app or a Telegram mini app. There are at least three new product forms:

What does this mean for MVP? Good news: an MVP can be a skill or an MCP server that solves one narrow job inside a tool people already use. The constraints are new too:

• You depend on someone else's platform, its rules and its ranking.
• Discovery inside AI stores is still young.
• Monetization models are only forming: OpenAI said it would share monetization details later [18].

Money as a metric: for the business, not for the product

Money is now a realistic success measure for an MVP. With the right approach and the right marketing, a small product can pay for itself quickly.

But I split two things. Money is a good metric for the business hypothesis: will someone pay? It is a poor metric for the product. A product should be measured by what it gives users: time saved, a problem solved, a reason to come back. That is why on certificate.tips I look at retention first.

The guide agrees. Its "mechanism to measure learning" element asks you to choose objective measures in advance, not to pick money by default [1].

The hidden costs of an AI-built MVP

AI cuts the cost of building. And it adds costs that are harder to see:

• Security. A 2025 study of more than 100 models on 80 coding tasks found security flaws in 45% of cases [12].
• Review load. Large AI-generated changes are hard to review, and defect detection falls with size [11].
• Reputation. If you charge for code that does not work, you pay with trust, not only with refunds.
• Legal and data risks. Personal data in prompts, unclear licences of generated code, and terms of AI platforms all need someone's attention.
• Vendor dependency. Your product's unit cost depends on someone else's model prices, as we saw with the ATS.

AI is a powerful tool, a buddy even. But it does not replace people and their heads. It is a beast you need to learn to ride.

Experts disagree on whether MVP still matters

Practitioners agree that building got cheaper. They do not agree on what follows from it.

1. MVP is outdated, build a lovable product. The MLP camp says "barely enough" no longer wins attention in crowded markets [5].

2. MVP is fine, distribution is the real problem. Builders and investors argue the technique works, but the scarce skill is now reaching customers [13, 14, 15].

3. Cheap building is a trap. Some warn that easy building pushes people to skip validation and polish products nobody asked for [16].

4. MVP was always about learning. The original Lean Startup view: an MVP gets maximum validated learning with least effort, whatever the cost of building [3].

Where am I? Between 2 and 4. The technique is the same. The minimum just moved up, because a working product is now cheaper than a convincing fake.

Limits: you still cannot sell air

Is MVP possible in any industry, medical equipment included? I think yes, because MVP is about checking demand and selling. You can sell a product before it is finished. But you must have good reason to believe you can build it.

The extreme counterexample is Theranos. Its founder claimed a small machine could run many tests from a few drops of blood. In 2022 a jury convicted her of fraud, and she was sentenced to more than 11 years in prison [20]. Selling ahead of the product is fine. Selling a product you know does not exist is not an MVP.

The opposite failure is common now too. When building is nearly free, people build products in search of a problem. The endless jokes about yet another B2B SaaS are a symptom. A joke this popular usually points at something real.

Common misconceptions

• "MVP means fewer features." No. It means the fewest features needed to test a hypothesis.
• "With AI, we do not need MVPs anymore." You still need to test demand. You just test it with a real product instead of a fake.
• "A successful MVP proves the business." One paying customer proves one customer. The guide asks you to analyse learning and decide the next step, and it may be a different approach.
• "AI replaced the team." In my experience it replaced no role fully. It changed what each role spends time on.

Practice Questions

These are original practice questions in the style of the AAC exam.

Question 1

A team wants to test whether small logistics companies will pay for automated candidate screening. Building the full product will take three months. What should the business analyst suggest first?

A. Build the full product to avoid a poor first impression B. Define the hypothesis, the success measure and the minimum features needed to test it with a few real customers C. Run a market survey and build if more than half of respondents say yes D. Release a shadow button on the company website

Answer: B. The Agile Extension's MVP technique starts with the problem and hypothesis, then the minimum set of features, with an objective measure of learning defined in advance. A survey (C) is what MVP is meant to replace with real behaviour.

Question 2

An MVP brought the first paying customer, and the customer is happy. What is the best next step?

A. Scale marketing immediately B. Analyse what was learned and decide whether the growth model holds or another approach is needed C. Stop collecting feedback, since the hypothesis is confirmed D. Add all features from the original backlog

Answer: B. Step 3 of the technique is to analyse validated learning and decide the next step. Even a profitable MVP may show that a different approach is needed.

Question 3

Which is a limitation of MVP according to the Agile Extension?

A. It is always more expensive than a full product B. There is no formula to define the right feature set C. It cannot be used for services D. It replaces the need to understand early adopters

Answer: B. The guide lists the lack of a formula for the feature set as a limitation. It also notes that MVP applies to services, often to test willingness to pay.

Conclusion: the gap between the Agile Extension and real MVPs

The technique in the guide still describes good practice. What drifted is the context around it.

So the minimum viable product is not dead. It is no longer limited by engineering. It is limited by your judgement about what to build and your ability to sell it.

Related topics

• Impact mapping
• Lean and waste
• Practise IIBA questions in the CBAP exam simulator

FAQ

Is MVP still relevant with AI?

Yes. The goal of an MVP, testing a hypothesis with real customers before investing more, does not depend on how code is written. What changed is that a working product is often cheaper than a fake one, so the minimum moved up.

What is the difference between MVP and MLP?

A minimum viable product is the smallest thing that tests a hypothesis. A minimum lovable product is the smallest version that early users love rather than tolerate. With cheap building, the gap between the two became smaller for small teams.

Is MVP on the AAC exam?

Yes. Minimal Viable Product is a technique in the Agile Extension to the BABOK Guide, which the AAC exam is based on. Expect scenario questions about hypotheses, success measures and what to do after the MVP.

What is an MVP for one customer?

It is an MVP where you serve a single real customer, often partly by hand, to learn what they value and whether they pay. Then you add customers one by one. It is close to the concierge MVP.

Which MVP types are outdated?

Fake doors, shadow buttons and landing pages with a sign-up form lost most of their point. They were cheap alternatives to building, and building is now cheap too. They also cost user trust.

Sources

1. Agile Extension to the BABOK Guide v2
2. IIBA AAC exam pattern
3. The Lean Startup
4. Lean Analytics
5. The Minimum Lovable Product
6. PSM I practice tests and PSPO I practice tests
7. CBAP exam simulator
8. AAC exam simulator
9. CBAP question bank
10. CBAP online study exam
11. Best practices for peer code review
12. AI-generated code poses major security risks in nearly half of all development tasks
13. I vibe coded an entire SaaS in a few months with Replit
14. When building gets cheap, distribution becomes destiny
15. The biggest bottleneck isn't coding anymore
16. The dopamine trap of vibe coding
17. Introducing the Model Context Protocol
18. Introducing apps in ChatGPT
19. Skills
20. Elizabeth Holmes sentenced to more than 11 years in prison