We're big fans of Lean Software Development movement here at Rocket because it contains many useful principles we appreciate like "Amplify learning", "Deliver as fast as possible", and "Build quality in". One of the more contentious elements of Lean, however, is the MVP, or Minimum Viable Product.

The MVP is a popular topic in software these days but there is no real consensus on exactly what it is. Even Eric Ries, a foremost thinker on Lean, admits the MVP can be confusing, stating:

"(the MVP's) power is matched only by the amount of confusion that it causes, because it's actually quite hard to do. It certainly took me many years to make sense of it.".

Which definition of MVP is the right one?

Indeed, even the Wikipedia article on MVP seems to contain several different definitions of the term:

• "An MVP is the product with the highest return on investment versus risk"
• "An MVP has just those core features that allow the product to be deployed, and no more"
• "An MVP is that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort"

All of these ideas are valuable but can become confusing when trying figure out what to build. That is, after all, the practical application we are looking for. And since everybody is somewhere different on the spectrum of "tiny startup <> huge established business" it is also difficult to know if the notion of MVP even applies to a particular situation. For better or worse MVP is now part of conversations in any new product environment, not just startups.

Another difficulty with the term kept bothering us: MVP definitions don't include a notion of user success. Another reason we find it sometimes difficult to talk about MVPs.

Why we use "Simple Working Systems" instead

To this end, we've stopped putting products in terms of MVPs here and have started to talk more about Simple Working Systems (SWS) instead (read The Next Feature Fallacy). We've found this a much easier starting point when talking to people who have amazing product ideas but aren't sure how to get them built. (or how much of them to build) Not everyone spends their time soaking in software methodologies. ;)

It's a lot easier to agree on what a simple, working system is. First, it's Simple, meaning that it doesn't take a lot of time or energy to understand and use. Second, it's a System, so it includes several parts that rely on each other. We use the example of a mobile app that includes an email component for sign up and notifications as a small system (most people have used software products with these components). Finally, the contentious word: it has to Work. We find in practice that people have a pretty good sense of what products work and don't work. In general, products that work allow people to get work done, achieve their goals, and use easily with others. In the simplest of terms a working product is one that people are using.

Here's the crux...when you start thinking about building simple, working systems you become even more focused on getting people to use the product. In 98% of cases this is exactly where product teams should be focusing. Nothing else matters...without people using your product you're not going to be successful. That seems to us a pretty straight-forward way to explain where we focus when designing and building products and we've generally found it easier to talk about than an MVP.

Your mileage may vary, of course, and your audience will too. But we've found that even people who use and like the term MVP tend to also like the idea of simple, working systems because the examples are obvious: Instagram, Twitter, Slack, Pocket, etc. These huge companies were built on the back of very simple systems that worked from the beginning.