The notion that a Minimum Viable Product (MVP) is reserved exclusively for startups is a common industry misconception. In reality, businesses with established products can use MVP too, though the application is a slightly different.
MVP: startups vs. mature products
MVP emphasizes simple feature lists, building products in iterative cycles, and communicating with customers early in product development. Indeed, it is possible for even established businesses to use MVP. At a startup, like Dropbox in its early days, MVP was the company’s entire product. When Dropbox launched, it didn’t have many of the capabilities that it has today.
However, at a company with a mature product, while you probably won’t do everything in the spirit of MVP, you could use MVP’s features as your product’s solution. In other words, when the product launches, you’d have certain features with links to alerts that they are not yet available. Tracking how many people click the feature, gives you an indication of whether it’s a valuable feature to pursue later.
MVP as a user story
MVP, in its simplest form, is essentially a user story. The acronym “INVEST,” originally developed by Bill Wake, applies to Agile methodologies. Because Agile and MVP are a de facto combination, this can help you identify good user stories — or good applications of MVP. This drives home the concept of MVP, which you are implementing using the Scrum mythology with Sprint. User stories must be:
I – Independent: If there’s a dependency between the stories, you need to implement the predecessor before you implement the dependent.
N – Negotiable: The story is not an explicit contract for features; it’s negotiable between the product owner and the Scrum developer.
V – Valuable: To deliver it as a minimum viable product, it needs to be valuable to the business.
E – Estimable: Will this take 20 hours or 20 days? This is just an estimate.
S – Small: If you have a large story that cannot be implemented in a single print, you need to break it down into a smaller story.
T – Testable: Independently, the story needs to be tested to determine whether or not it was successful.
Communication is key
In any process or methodology, people are the most challenging component, especially when change is involved. People are creatures of habit. The purpose of MVP is to determine whether a product is the right product without investing too much time and effort. That’s where communication among developers, product owner, and early-stage customers is important.
You don’t want developers, for example, to over-engineer and add more features than are necessary for MVP. With MVP, less is more. That’s where a good feedback loop between the developers and the product owner is essential: There needs to be a methodology in place to validate what developers should be doing, so they’re not chasing unnecessary features. While product owners can influence these decisions, they are not the ones coding.
Over-engineering is common especially in an engineer or developer-centric culture. Many years ago, a Google developer added code in Gmail that pulled in advertisements based on email contents. While this particular example ended up as a welcome addition on Gmail, it represented an engineer working beyond the scope of the product. However, this new feature caused so many perceived privacy issues for Google that it withdrew the feature a few years ago.
For every good example, there are dozens of examples of over-engineered obscure features or multiple workflows that may accomplish the same task but do not add value to the product or increases user adoption. Again, sometimes less is more!
In MVP, the key word is “minimum,” meaning you need to feel comfortable and secure in saying no when people insist that a feature is necessary. It might be an important feature, but it’s important to clarify that it’s not necessarily important for an MVP. When considering the user, it’s better to get ten things in reasonably good shape than a hundred things that are half-baked. “Not-to-do” lists are sometimes just as valuable as your traditional to-do lists.
Know when to say no
MVP is not for every customer; you need customers to be early adopters with the ability to envision what the finished product will look like even when it’s only 20 percent done. From a business standpoint, your customer needs to have enough pain points addressed, so they are willing to go along for the ride while MVP provides solutions to them.
An MVP is not a new concept, it’s a widely known concept across many industries. You may know it as concept, alpha, beta, technical review, pre-release, etc. Whether you’re doing it at a startup or trying it with a mature product, it’s a concept that you need to keep small, simple, and laser-focused.
Where to start
Start with a simple website, send out newsletters to a small percentage of your customers, the die-hard ones that love everything you do. If you don’t feel comfortable adding it to your main portfolio, create a product website, giving it the validation by your main product “Product X by … (your company)”. We can help you get started with this in a very short time, for a fraction of a conventional full-site development investment. Contact us today.
