The Minimum Viable Product (MVP)
Software engineers come up with the wildest ideas. From internet-connected toilets to dating apps for cats, we can truly dream up anything. Motivation can compel us to build anything we want, however, it can also get in the way of shipping.
A good plan violently executed now is better than a perfect plan executed next week.
How exactly does a quote from an army general related to software engineering? Well, when it comes to shipping products, sometimes perfect plans are executed next week and other times they're executed at all. The problem with perfect plans is that they don't exist. The process of shipping is not one and done, it's a cycle of learning and refinement.A product is never done until it's released and then deleted to the ether.
But we have to start somewhere. When we write our first line of code, we're starting essentially with a minimum viable product.
A Minimum Viable Product (MVP) is a version of a product with enough features to attract an audience and validate a hypothesis.
Let's use a search engine as an example. If our goal is to create something like Google - starting with the entire web may be too ambitious. As engineers, our time and resources are finite, and we have to start somewhere.
For a starting point, we could crawl a single site or a single page. Or instead of searching for images and videos, we could start with text only. In doing so, we reduce the scope to something more manageable, with enough features to go to market. Here's why that's important.
Why invest so much time and energy into a product that nobody wants? If we can gather a signal with an MVP, then we can potentially save time on things that don't work. That signal can also point us in new directions to what potential customers are actually looking for.
A good signal means more time and investment. On the other hand, a bad signal can mean a dead end.
Big features often come with risks and rewards. If we look at self-driving cars, for example, the automation is both a risk and a reward. Starting out the gate with a self-driving car is a huge risk. So companies like Tesla started with a car that has the capable hardware, with the automation disabled. That is their MVP.
When you're planning an MVP, you're betting on that first release. You may want to prioritize the biggest bets or risks, depending on how much runway there is and what facets need proving. In the Tesla example above, we see how the company hedged its bets with its cars with the promise that self-driving functionality will be unlocked down the line. On the other hand, carving out any new market is a risk.
Software engineers often confuse an MVP with the first step of a process to build the final product. If our product is a gourmet sandwich, an MVP is not just one slice of bread. In this case, the MVP could be two slices of bread and deli meat. It is a version of the final product that is the minimum amount of features to deliver to the market.
So now that we know what a minimum viable product is, the question is, how do we do it? How do we take a product and turn it into the minimum we can build and ship?
The easiest way to create an MVP is to focus on a specific feature. Rather than ship the entire product, we can experiment with a particular feature. If our idea is a pie, then the reduced scope is just a single slice. Now how you pick that slice is up to you, and what risks and rewards come with that slice.
When the scope cannot be reduced, another option is to minimize the market. This is essentially re-framing the idea for a more specific audience. This might feel similar to Reduce Scope, but it's less like taking a slice of the pie and more like making a quiche instead.
If we can't reduce the scope or minimize the market, then we could create a version of the product without all the bells and whistles we would normally include. We could hack something together with static HTML, or even lean on a third-party integration. Doing so would allow us to get a signal, and then add the bells and whistles later.
Minimum viable products help save time and effort in the product development process. Reducing scope, minimizing the market, and faking it until you make it - are all great ways to get a signal before committing to the full product. Remember that an MVP is not the first step to get to the final product, but rather the first step in the learning process.
I hope this helps clarify how a minimum viable product can make you an MVP at product development. If you have other questions, feel free to reach out to me on Twitter.