Probably 1 of the most difficult juggling acts in software development is scoping a minimum viable product. I’m pretty sure a lot of that comes from the juggling act and judgement calls that constitute defining said minimum viable product. It’s not easy to do, mostly because defining a minimum viable product involves balancing 2 mutually exclusive terms. That said, I think you can find the best set of tradeoffs en route to the minimum viable product by examining the principles behind each part and then combining them back together once we understand what we’re looking for to satisfy each keyword.
“Minimum”
First up is the “minimum” aspect, this means including whatever your differentiating factor is, along with just the features required to be considered a complete product, and nothing else. As a simple case study, if you were going to write your own blogging engine, you’d want whatever it is that makes your blogging platform worth trying, the ability to save drafts, publish posts, edit them later, and comments (yes Ghost, comments are required if you want your blogging platform to be considered “feature complete”). That’s it. Scheduled publishing of a post can come a few weeks later in a another push. The same with tagging (do people really do anything with blog tags anyways?). If you can solve your application’s problem without it, then it’s not part of your minimum viable product.
Keep in mind the primary purpose of your minimum viable product is to get it out the door so you can A) start selling it and B) start getting feedback from your users about your product. Doing anything else before shipping is a waste of time, and wasting time on unnecessary features is nothing more than an excuse to avoid having to actually ship. Seeing as how shipping is what actually makes you money and gets your product adopted, finding excuses to not ship is counter-productive to pretty much any goal you may have for your software.
The other thing to remember, while you’re looking to compete with any other products out there, to start with you’re competing with the low-end of the market. I’m sure whatever you’re building is going to be great, but you need to ship quick, and everyone else in your industry has the advantage of having been in the market longer. That’s time spent adding features, experimenting, and gaining lock-in with their existing customers. To grow your customer base, you need to either snag people just entering the market (which means they’re likely just starting out and very sensitive to price), or pick off easy wins from existing competitors, which you’re likely not going to get from organizations offering the “premium” products. You can always move up market as you add features and grow your operation – it’s a lot easier to break into the higher levels of your market from below than trying to break in from the outside. Figure out the bare minimum you need to be a low-cost player, and ship as soon as you’ve built that.
“Viable”
Next up is “viable” – however minimal your product is to start, it still needs to be a complete product. Either there are already products out there you’re going to have to compete with, or there will be soon. That means you can’t be missing essential features. You need to know what it takes to make your product solve it’s target problem in its most basic form – even if the solution isn’t as polished, or has as many bells and whistles, or is as customizable as you’d ultimately like – and make sure those things are present when you launch.
The hard thing to come to terms with is that the later you are entering a market, the longer the list of essential features is. Remember, you need to be able to compete with the low-end of any given industry you’re entering, and the longer your competitors have been around, the longer the list of features has grown across the board. What you need to focus on is not the specific things competing products or services offer, but rather the problems or issues those features are intended to solve. You may be able to reduce the number of features you need to tick off by coming up with better ways to solve those problems, or by correctly targeting a segment of the market that doesn’t have some of those same requirements.
Luckily for you the reverse is also true, the earlier you can get shipped, the smaller the feature set you need to be considered “viable,” especially if you’re 1 of the first to market for something. Similarly to how you need to have a more full-fledged product the longer your competitors have been around, the newer your particular segment of the market is, the less settled and smaller your competitors feature sets will be, and the less you need to implement to get in there and compete – that’s the advantage of shipping fast and soon.
No matter what existing features you need in order to be considered an option in the marketplace, the most important thing to make sure you have implemented the first day you go live is whatever it is that makes you stand out from all the other companies you’re going to compete against. Without a differentiating factor, there’s no reason whatsoever for anyone to give your product a chance as opposed to literally anyone else who has a competing offer to make – and the more people who were already doing business in your industry before you released, the worse that situation’s going to be for you. Having something that’s both different and compelling to offer gives you an immediate competitive edge – without 1 of those no product is “viable,” no matter how large their feature list may be.
Bringing it all back together
So after looking at the competing terms individually, you can probably define a “minimum viable product” as “a product that offers just enough to compete at the low end of the market, complete with whatever makes your product unique, but nothing else.” Remember, the emphasis on building a minimum viable product is shipping. The more minimal your product, the faster you can get out onto the market, the sooner you learn just how valuable your product really is to people, the faster you can get your backlog into a real priority order based on your user’s needs, and the faster your application or service starts paying for itself (and for you to work on it).