At Ebix we strive for agility, flexibility, and rapid iteration. Focusing on speed to market first, we then collect feedback, and make needed adjustments to our products and services. These agile methods and DevOps are central to delivering a minimum viable product (MVP). Ebix’s use of this contextual concept is surprising to some. They do not realize that we operate with a startup mentality despite having been in the insurance software industry for decades.
The notion that 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. MVP, along with Agile and DevOps, may seem like unrelated concepts, but they’re not. For example, for DevOps you need to have Scrum, a framework for Agile, and with Scrum you might be doing MVP.
Indeed, it is possible for even established businesses to use MVP. At a startup, like Dropbox, MVP is 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 with your product’s mobile solution. When the product launches, you’d have instances in which links alert you that certain features are not yet available. Tracking how many people click the link gives you an indication of whether it’s a valuable feature to pursue later.
Or you might consider MVP if you’re integrating something with your mature product, such as payment gateways or eSignature providers. There are many ways to integrate the concept of MVP, even if you’re not a startup.
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 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 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 so they are willing to go along for the ride while MVP provides solutions.
At the end of the day, MVP is not a new concept. It’s been called alphas, betas, technical reviews, prereleases. 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.
