ZIRP, Broken V1s, and the End of the MVP Era

On July 1, 2024, a Twitter user noticed that Figma’s newly released generative AI feature seemed to be reproducing designs from existing apps. By July 2, 2024, Figma co-founder Dylan Field tweeted that the error was “My fault for not insisting on a better QA process for this work and pushing our team hard to hit a deadline for Config.” 

Figma is not alone. 

Soon after release, the Humane Ai Pin and the Rabbit r1 received harsh criticism, as did Microsoft’s Windows Recall feature. There appears to be an increasing impatience with half-baked v1 products that extends from brand-new startups to scaleups to enterprises. 

AI (and the pressure to release AI products quickly) has revealed a problem, but the technology in question is incidental. A formerly positive feedback loop – releasing, iterating, re-rereleasing – has become a negative one as users get a first impression and reject it instead of waiting for the follow-up. 

What changed?

Minimum viable product (MVP) was always a contentious term, and many people disagreed about what it meant and how to apply it. To this day, even the original formulator of the term can’t get people to agree. 

Eric Ries built the original MVP concept, and his career informs why he formulated the idea and why it took off. 

Ries moved to Silicon Valley in 2001 and launched numerous companies before eventually joining venture capital firm Kleiner Perkins as an adviser. There, he combined ideas he had picked up from Steve Blank, another founder-turned-adviser, and the concept of lean software development (inspired by Toyota’s lean engineering methodology).

The core MVP idea took off when Ries published blog posts about the “lean startup" in 2008 and spread even further when he published the book The Lean Startup in 2011.

The concept, at its most simple, is that startups waste money trying to build the perfect product before releasing it. Instead, startups should build products that are “minimally viable”—meaning, they are just good enough to generate useful feedback from potential customers—and release them as soon as possible. 

This was especially useful at the time because, as Enzo Avigo, co-founder of June, explains, “The idea of the Lean Startup was conceived on top of the rubble of the 2000 Dot-Com crash. [...] With risk capital at a premium and the public markets closed, startups and their investors now needed a game to save cash and survive long enough to start making real revenue. And to do that they needed a different method than just ‘build it and they will come.’”

The idea soon became canonical among startup thought leaders and accelerators, but popularization quickly overtook its initial intentions. As Lassi A. Liikkanen, Director of Product Design and Insight at Qvik, points out, “An MVP, as defined in the Lean startup framework by Eric Ries, is a tool to explore and develop in unknown markets to discover product market fit and to develop a startup through the product.” 

Back in 2001 and even in 2011, unknown markets not yet penetrated by software were plentiful and ripe for disruption. Remember, too, that in 2011, Marc Andreessen proclaimed that “Software is eating the world.” In 2024, many fewer markets are unknown, and few, if any, haven’t at least been nibbled by software.

Due to its canonical status, criticisms of the MVP concept over the years have focused less on the changing context around it and more on the acronym itself. Many, many modified terms emerged over time, such as Minimum Loveable Product, Minimum Testable Product, and Minimum Viable Representative Product – all of which suggested marginal improvements that people also disagreed with. 

Visualizations emerged and varied, such as the pyramid below, which criticizes one way of thinking about MVPs in favor of another.

Others tried to add nuance but ended up adding complexity, such as the one below, which includes MMR, MRF, and MBI.

^{MVPs and mbis. Disciplined Agile. (n.d.). https://www.pmi.org/disciplined-agile/process/product-management/mvps-and-mbis}

At a certain point, you start to lose sight of the original concept's simplicity and clarity and miss bigger, more substantive criticisms. 

Ries struck at an assumption many people took for granted: You shouldn’t wait until the product is perfect before releasing it. But the opposite case remains true, too: There is such a thing as too early. Where, then, do you draw the line?

Remember, even in Ries’s original formulation, founders aren’t supposed to release MVPs and hope they succeed despite their v1 nature. MVPs test the market so that founders can get a sense of market demand and potential product/market fit before investing a lot of time and energy. 

The question, then, is how effective a test an MVP can be. Here, it’s useful to turn to another startup leader, Paypal Mafia member Peter Thiel. In an interview with Tim Ferries, he argues that “failure is massively overrated.”

“Most businesses fail for more than one reason,” he explains. “And so when a business fails, you often don’t learn anything at all because the failure was over-determined. You will think it failed for Reason 1, but it failed for Reasons 1 through 5. And so the next business you start will fail for Reason 2, and then for 3, and so on.”

You could, for example, build a spreadsheet product that would appeal strongly to lawyers but fail because the MVP version was too slow or because you targeted accountants or because your marketing was bad. What’s your takeaway for the next attempt? Hard to say.

That’s why, when people disagree about what “minimum” and “viable” mean, the disagreement isn’t just semantics. As Jason Cohen, founder of WP Engine and Smartbear, writes, “​​MVPs are too M and rarely V. Customers see that, and hate it. It might be great for the product team, but it’s bad for customers. And ultimately, what’s bad for customers is bad for the company.”

If the MVP isn’t good enough, you might not merely disappoint users and just fail – you could learn the wrong lesson entirely and fail again with the next attempt.

The real pressure test that the MVP concept is suffering from now comes from a much larger macroeconomic perspective. The end of ZIRP (Zero Interest Rate Period) has caused a sea of change in the tech industry, leading to layoffs, acquisitions, and drastic shifts in business models. The MVP model might be another victim. 

ZIRP refers to a “zero-interest-rate period” (some also refer to a Zero-Interest-Rate Policy or Phenomenon, but we’re all referring to the same thing). 

In simple terms, a ZIRP is when the central bank of a given country lends money at a rate low enough to be a rounding error away from 0%. The modern tech industry has been operating within a ZIRP since around 2000.

^{Orosz, Gergely. “The End of 0% Interest Rates: What It Means for Tech Startups and the Industry.”, 2024}

For context, such a sustained period of low rates has been unheard of for nearly the last century.

Before you skip ahead of the macroeconomics jargon, consider everything that’s happened since 2000. Gergely Orosz, author of The Pragmatic Engineer, points out two of the biggest changes: The launch of the iPhone and Android and the rise of cloud computing.

These products were categories as well as platforms. People have made millions and billions of dollars building products that could only exist thanks to mobile devices and cloud computing. 

This is the era when Eric Ries built the MVP concept, and venture capitalists focused (and were able to focus, thanks to ZIRP) on funding growth at all costs. 

Now, everything has changed. As Orosz writes, “For people and institutions with money to invest, ‘risk-free’ returns on investments have increased by almost 10x.”

We’ve already seen some of the effects: Existing companies are under pressure to make a profit instead of prioritizing sheer growth, and new startups are struggling to get funding because borrowing is more expensive. 

The tech industry isn’t over by any means, but it’s time to revisit concepts borne from ZIRP and evaluate how well they’ll work in a post-ZIRP environment. 

The core startup model, the pipeline that sent founders stage-to-stage from MVP to product/market fit to funding to rocketship growth, depended much more on ZIRP than anyone realized. 

As Matt Levine, columnist for Bloomberg News, writes, “Startups are a low-interest-rate phenomenon.” When interest rates are low, he explains, a dollar today is as good as a dollar tomorrow, so it makes sense for investors to delay profits for the sake of growth. Now that interest rates are higher, startups will have to demonstrate potential profitability much sooner. 

Again, this doesn’t mean the end of startups, but it does mean the end of a certain kind of startup—the kind typified, I would argue, by a focus on building and launching MVPs. 

Remember, the MVP's original intention was to test yet-unknown markets, but in 2024, many fewer markets remain unknown. Liikkanen breaks out four situations where the MVP model might (now) fail you.

People are familiar with software now, so a strong customer base with clear expectations and plentiful competing options might reject your MVP outright in a way they wouldn’t have back in 2011. 

Jiaona Zhang, product leader at Dropbox, Airbnb, and WeWork, argues, “The minimum viable product was appealing because it was cheap, and you could get it to market faster. But we’ve advanced past a world where products are ‘the first of X.’ Stiffer competition means that MVPs aren’t going to cut it anymore.”

The “minimum” has risen over time, and it’s becoming increasingly difficult to release something that’s truly “viable.” The MVP concept (and its permutations) might have only worked as well as it appeared to when startups had lots of cash and more runway. 

Post-ZIRP, capital is low, the software market is saturated, and switching costs are lower than they’ve ever been. There are plenty of dependable incumbents that an MVP will struggle to compete with, even in narrow use cases. 

Quality, which people historically deprioritized for early-stage companies, is now a way to stand out. Founders have to redefine quality, a term even vaguer than MVP, for the post-ZIRP era.

Earlier, we cited Thiel, who argued that failure is overdetermined. In a similar sense, low-quality software, too, is overdetermined. An MVP is intentionally imperfect, but it’s not always easy to see where brokenness, deficiency, and incompleteness make a big difference.  

Quality, ultimately, is not a linear spectrum between bad and good, and startups have to think more complexly than picking a good enough spot on that spectrum. Every quality decision is a tradeoff, and the examples below are only a few of many.

Internal quality and tech debt: As Martin Fowler writes, external quality is visible to customers, and internal quality is only visible to company developers. But, when internal quality issues make it hard to iterate, they can cause external quality issues—especially when competitors can iterate faster. 

^{Fowler, Martin. “Is High Quality Software Worth the Cost?” Martinfowler.com, 2019}

Often, companies absorb this low quality and define it as tech debt. However, as Tim Cochran and Carl Nygard, advisers at Thoughtworks, write, “Startups regularly state that tech debt is their main impediment to growth.” Taking on some amount of tech debt is a good way to start, but taking on too much can impede growth – allowing competitors to swoop in or initially positive customer sentiment to sour.

Integrations: As technology writer and business analyst Byrne Hobart writes, “The biggest product typically has the most integrations, and as the cost of launching a new SaaS product declines, the investment required to have the right integrations for 99% of customer use cases actually increases.” Hobart points out that this is a big reason why Docusign, which offers a seemingly simple tool, needs to employ nearly 8,000 people to support it.

^{"12 Docusign Integrations for Smarter Business Practices.”, 2024}

The saturation of the software market means a parallel rise in the number of software integrations new products need in order for users to consider them viable. “It's easier than ever to build version 0.1,” Hobart explains, “and takes more time to connect with everything that's going to get it to 1.0 status.”

Security and compliance: In theory, a product that has a few security or compliance issues but is otherwise perfect could still fail for those relatively small reasons. Aptible, for example, a PaaS provider, wanted to target the healthcare industry and needed to build even early versions of the product with compliance in mind. However, HIPAA has extensive, complex regulations for logs, which are a core part of any PaaS product. 

“Typically, companies bolt compliance features on after the fact,” writes Ann Guilinger, engineer at Aptible. “But we knew that this after-the-fact approach wouldn’t work for logging because the separation and isolation our initial customers sought needed to be built in from the beginning as an architectural requirement and first principle.” 

Aptible could have been perfect in any other regard but would have failed – at least for healthcare customers – without this compliance. 

Startups are not static entities, and neither is startup success. If a startup methodology encourages startups to focus on early-stage growth that leads to mid or late-stage failure, then the methodology needs to be questioned.

Low-quality software is a tradeoff, but the costs are often hidden—both because of the overdetermination outlined in the previous section and because small costs can be visible early on but compound in surprising ways over time. 

If we return to tech debt and Fowler’s distinction between internal and external quality, we can see how low-quality compounds. If there’s too much tech debt, developers will have a hard time modifying and iterating. If your MVP proves your ideal user needs a new feature or that an unanticipated market needs different integrations, tech debt can make it difficult to act on the data your MVP provided. 

An MVP could create a bad first impression with early users, too, and a bad first impression could carry enough weight to damage your initial marketing efforts. In our research, for example, we found that most people consider churning after three to four bad experiences with a website or app.

^{Sauce Labs Every Experience Counts Report 2024}

Low quality – particularly in terms of completeness with integrations, security, and compliance – can also ruin your market data. An incomplete product can attract the “wrong” early customers, making a fintech company, for example, assume higher-value customers wouldn’t be interested in the value of their product when, in reality, they don’t appear to be interested only because your MVP doesn’t integrate with their stack.

Note, too, that complete doesn’t necessarily mean complex. As Cohen explains, “It is not contradictory for products to be simple as well as complete. Examples include the first versions of WhatsApp, Snapchat, Stripe, Twilio, Twitter, and Slack. Some of those later expanded to add complexity (Snapchat, Stripe, Slack), whereas some kept it simple as a permanent value (Twitter, WhatsApp).”

These three costs are only a few among many, but they each compound:

Embracing low-quality is a good idea, in theory, when your startup is young, but you need to know which costs you’re taking on and which benefits you’re trading off. 

In the ZIRP and MVP eras, speed and growth were priorities because the macroeconomics allowed them to be. On the one hand, you could grow because money was cheap, and on the other hand, you had to grow because money was cheap, and competitors would grow past you if you didn’t. 

Now that the economic context has changed, a high-quality product can create compounding positive effects that are often worthwhile, even for new startups and new products. 

Customer delight, for example, can translate into customer advocacy, which fuels marketing efforts and lowers customer acquisition costs. Our research shows, for example, that 60% of people feel delightful experiences impact their buying decisions.

This has always been true, but this strategy has become more impactful as markets have become saturated with software options and users have developed opinions about what they want out of software.

Figma, for example, did not take the MVP route but instead took nearly four years to build and launch its first product. Compared to incumbents like Adobe XD and Sketch, Figma started in a strong position when it launched and, as a result, captured the UI design market in only a couple of years.

^{“What’s Changed in 50 Years of Computing: Part 3.” Pragmaticengineer.com, The Pragmatic Engineer, 18 June 2024}

Quality (sometimes called “craft”) can also be a moat, especially for knowledgeable B2B buyers in an established market. Developers are the prime example because they intimately understand what software should be able to do, but other professionals have a good sense, too, considering the average department in 2023 uses 87 SaaS tools. It’s harder than ever to be fresh and new but easier to be comparatively excellent. 

With the end of ZIRP, the MVP model is now in an awkward middle ground, and founders need to drastically lower quality on one end or drastically raise quality on the other. 

Early on, founders can go even more lightweight than MVPs by using tests. 

Gagan Biyani, co-founder and CEO at Maven, for example, writes that a good test “does not attempt to look like the eventual product. It’s rather a specific test of an assumption that must be true for the business to succeed.” 

Peter Reinhardt, previously CEO at Segment, echoes this point with an example, writing, “The first ‘test’ for Segment.io wasn’t a product at all. It was a souped-up for loop with a nice API called analytics.js. [...] The interest on HN and Github clearly showed there was a market, which only then resulted in the team developing a real product – minimally viable or otherwise.”

Later on, founders can take more time to build products that are good enough to stand out and really test their ideas. 

As Karthik Hariharan, Head of Engineering at Goodwater Capital, writes, “Your competition is no longer non-software solutions. It's probably existing, but sub-optimal software. Which means if you're going to compete with it, your software needs to be significantly better.”

Echoing this point, Tuomas Artman, co-founder at Linear, writes, “Since many of us are building in a crowded market, the bar for a competitive, public-ready MVP is much higher than the MVP for a novel idea, since users have options. To get to this high bar, we have to spend more time refining the initial version [...] To truly test the viability of any new idea you need to build something that is substantially better.”

Either way, quality can no longer be a stray concern only to be addressed later. Tradeoffs abound, and with the end of ZIRP, there’s little cushion for throwing good money after bad.