Rethinking MVPs in the Age of AI
There’s a version of MVP (Minimum Viable Product) development that hasn’t changed much in a decade: find a real customer problem, confirm there’s willingness to pay, and build the smallest solution that addresses it. Then, get it into customers’ hands quickly and see whether it delivers.
Now, with AI compressing development timelines, teams can build more with fewer resources. But that has introduced a new temptation: if we can add another feature to an MVP, why wouldn’t we?
We sat down with Ajay Singh Thakur, Group Leader at Constellation Dealer Group, to discuss what belongs in an MVP in the era of AI, how teams can validate ideas before investing heavily, and why AI should be used to get to customers faster, not to make the first version bigger.
Start With a Problem Your Customers Will Pay to Solve
Before a product is built, Ajay believes teams need evidence that the problem is commercially meaningful. Traditionally, that process starts with an initiative manager exploring a defined area of the business, speaking with customers, and identifying problems worth solving.
Rather than beginning with a fully formed idea, the goal is to identify customer problems that meet three key criteria: they are urgent, pervasive across the customer base or total addressable market, and customers are willing to pay to solve them. From there, teams can progressively narrow the field. “We would go and interview 30-plus customers and build a list of ideas,” Ajay explained. “Then narrow it down to one or two.”
From there, the question is whether customers would actually be willing to pay for the solution. Within Constellation Dealer Group, Ajay says teams model potential adoption across their existing customer base to understand the commercial viability.
Ideally, Ajay suggests identifying a group of early adopters willing to help fund development. This way, the MVP isn’t built around what the team thinks the market needs. It’s built around a problem customers have already indicated is valuable enough to pay to solve.
AI Is Collapsing the Distance Between Discovery and Development
Historically, customer discovery and product development were largely sequential. Teams would identify a problem, validate it with customers, and then work with R&D to begin building.
AI is changing that process by allowing discovery and development to happen much closer together. Teams can prototype, test and iterate faster, creating more opportunities to develop alongside customers and bring them into working sessions where they can see the product take shape and provide feedback in real time.
“You could be sitting right next to the customer and working on the solution,” Ajay explained.
The opportunity with AI is to compress the path from customer insight to a high-quality product, allowing teams to validate what the market wants and deliver a reliable solution faster than before.
The Risk of Building Too Much
There is an obvious side effect to making software easier and faster to build: teams can build more.
“There’s absolutely this drive to add more stuff because we can,” Ajay said. “I strongly discourage that.”
The purpose of AI in the MVP process shouldn’t be to squeeze twice as many features into the same development window. It should be to shorten the time it takes to put something useful in front of a customer.
Historically, resource and data constraints often pushed MVPs toward the “minimum” end of the spectrum. The first version might solve the core problem, but not always efficiently, intuitively or with the level of quality expected from a mature product. AI gives teams more room to improve that core experience before moving on to the next major feature or adjacent problem. For AI-powered features, refinement extends beyond user experience to accuracy, privacy, security.
If AI allows a team to build an MVP in three months instead of six, the opportunity is not necessarily to spend the additional three months expanding the scope. Teams can use that capacity to refine the solution, improve usability and iterate based on real customer feedback.
“If the first version doesn’t hit the mark, we can quickly iterate through that and get to the mark,” Ajay explained.
The balance is avoiding both extremes. An MVP does not need to be crude to remain focused, but improving quality also does not require gold-plating or over-architecting. AI gives teams the opportunity to put greater emphasis on the “viable” part of MVP, increasing the number of learning cycles they can complete while delivering a stronger solution to the original customer problem.
In Conclusion: The Definition of “Minimum” Hasn’t Changed
Faster development shouldn’t change the discipline behind an MVP. If anything, it makes that discipline more important. The goal is to shorten the distance between an idea and evidence that it solves a real customer problem.
AI’s greatest contribution to MVP development is not that it lets teams build a larger first release. It is that it lets them build, test, and iterate faster. But faster development doesn’t necessarily mean faster adoption. The products we build still rely on customers to incorporate them into their workflows, use them consistently, and provide meaningful feedback.
This makes getting the MVP into customers’ hands as early as possible even more important. As Ajay puts it, “Perfection is the enemy of progress.” The teams that benefit most from AI will be the ones that use it to create more opportunities for customer learning, not to expand MVP scope.
Back to Insights