Is the Minimum-Viable-Product Still Relevant Today?

Is The MVP Still Relevant?

The Minimum Viable Product (MVP) is right up there with Microservices as one of the most misunderstood concepts in software development. While its principles remain sound, the term has become so diluted and misapplied that it is high time we re-examine how we think about initial product releases.

The Original Promise

When Frank Robinson coined the term MVP in 2001, his focus was purely commercial. The core idea was simple: development costs are high thus adding features is expensive. Every line of code added to implement a feature is ultimately a liability. The more code you have the more bugs you are likely to have and that code needs maintenance, and maintenance is expensive thus more code == more expense. This wasn't about quickly building unfinished products and unleashing them on customers as quickly as possible, it was about refinement, getting to the essence of a feature and trying to find the optimal balance between understanding what customers want and then building it, extracting the maximum value for your efforts. Put plainly, the MVP is all about ROI.

The Art of Pathfinding

At its core, successful product development is about pathfinding - discovering the optimal route through uncertainty to reach your business objectives. Like an experienced navigator, you need to plot a path that balances speed, safety, and the likelihood of reaching your destination.

Doing this sounds straight forward enough, but in today's landscape, users have countless options and limited time to engage, the modern world is relentlessly trying to grab their attention. The bar for what constitutes "viable" has risen significantly. Release something too rough around the edges, and you might never get a second chance. And let us not forget that the 'M' in MVP stands for minimum not minimalism; what is minimally viable is extremely dependent on context.

Reid Hoffman's now famous quote "If you are not embarrassed by the first version of your product, you've launched too late" made perfect sense in 2011 when he said it, and it still holds true for truly novel products today, but users are not easily impressed so we need to be honest with ourselves about what we are building. Consider Anthropic's Claude versus ChatGPT. When OpenAI released ChatGPT, its basic and somewhat clunky interface didn't matter - the underlying technology was so revolutionary that users would forgive almost any UX shortcomings to ‘talk’ to an ‘AI’. This exemplified Hoffman's philosophy perfectly.

However, when Claude launched into an already established and increasingly congested market, it required a more polished experience from day one. The context had changed - users now had expectations shaped by existing products, and being "embarrassingly early" would have risked immediate dismissal by an audience increasingly spoilt for choice. Despite offering fundamentally similar products, each company had to find a different path to market, based on their unique circumstances and timing.

The Validation Trap

A common pitfall in product development is a phenomenon called the "IKEA Effect" where humans place disproportionate value on things we've built or assembled ourselves. This cognitive bias can be particularly dangerous when building digital products.

Consider a scenario:

A team builds what they believe is an MVP for a consumer service. They get positive feedback from friends and early users. The product works as intended, and the initial response seems encouraging. However, they've fallen into a classic trap - confusing technical validation with business validation. Does the product work? Yes. Will it sustain a business? Who Knows!

Effective pathfinding requires us to validate not just individual features or technical capabilities, but the entire journey from problem to solution to sustainable business. Like a mountaineer planning a route to the summit, you must identify hazards, set (validation) milestones, and be ready to backtrack when facing unexpected challenges.

Making Smart Bets

Instead of thinking in terms of MVPs, we should think in terms of smart bets and careful pathfinding. Every feature, every release is essentially a bet, and like any professional poker player will tell you, success isn't about always winning – it's about managing risk and knowing which bets are more likely to win, it’s about making informed, educated guesses. When making any kind of bet the first question shouldn't be "what should we bet on?" but "how much are we prepared to risk?" Before you think about what to build think about the stakes. This isn't just about financial investment. When we commit to building a feature or product, we're betting with multiple forms of capital: direct development costs, of course, but also opportunity costs, market reputation, team morale, technical debt and heck, in some cases peoples ability to pay their rent. A startup might bet the company on a single core feature, while an established business might spread their risk across multiple smaller initiatives. The key is knowing your risk appetite and sizing your bets accordingly. This is vital and cannot be understated.

If you were to bet on a horse to win a race, success is very easy to define, if your horse crosses the line first, you win. With digital products, successes are less clear cut, so the second critical consideration is understanding what it is we need to learn in order to gauge success - we want to make smart, educated bets so it is vital to define meaningful and measurable outcomes that we can learn from. Vague success criteria like "users will love it" or "it will drive engagement" won't cut it.

Success criteria serve multiple purposes: they force us to articulate our assumptions clearly, they provide clear decision-making frameworks, and they help us design focused experiments that have empirical evidence that can actually prove or disprove our hypotheses. Without this clarity, we risk building solutions in search of problems, rather than solving real, valuable challenges.

Remember, when it comes to measuring success we need hypotheses and data not hopes and dreams.

Breaking Down the Journey

Smart pathfinding typically unfolds in stages. Think of it like exploring new territory. First, we send out scouts – this is our technical proof of concept, verifying that our planned route is even possible. Next come the reconnaissance missions – targeted experiments that test our key assumptions about user behaviour, pricing models, distribution channels and the like.

Only when these early missions succeed do we commit to establishing our first base camp – a focused initial build that delivers immediate value to users while creating a foundation for future expansion. Each stage provides specific learning outcomes that inform the next steps, allowing us to quickly realise when we have taken a wrong turn and back track or when we're heading in the right direction and to double down.

This staged approach might seem overly cautious, but it's the difference between taking regular compass readings versus walking for days in the wrong direction. By reducing uncertainty before making larger investments, we reduce our risk exposure and dramatically improve our odds of success.

Remember, the goal isn't to avoid all risks – it's to take well informed risks with clear potential returns. That can easily be the difference between building something people might use and building something they'll actually pay for.

The UX Factor

Here's a crucial point that often gets overlooked: good user experience isn't a luxury feature, it is not a nice to have – it's a critical part of your path to success. If we've identified truly valuable features, then not investing in making them delightful to use increases our risk of failure. Users don’t have the time or patience to work through clunky interfaces, if something is difficult or counter intuitive you will most likely lose them. Research from Forrester (2017, paid report) shows that, on average, investing in UX has an ROI of 9,900%. As the old adage goes, you never get a second chance to make a first impression, don’t squander that.

The Path Ahead

So, is it time to retire the MVP? Not exactly, but it is time to be more considerate about what an MVP is and should be. What really matters here is finding the right path through uncertainty with clear hypotheses, smart, calculated bets and great delivery. Whether you call it a Minimum Viable Product, Minimum Loveable Product, Minimum Marketable Product, or simply Version 1.0, the principles remain the same:

• Map out your potential paths before committing

• Validate your riskiest assumptions first

• Build enough to get meaningful feedback

• Invest in good design for features you're confident about

• Be nimble enough to change course when needed

Shipping first is no longer enough – Success will come to those who can find and navigate the smartest path. Like any journey into uncertain territory, the key is not in having a perfect plan, but in having the right approach to discovering the best route forward.