Every venture capitalist, board member and startup advisor counsels the entrepreneur to focus on building their minimum viable product (MVP). Successful startups do a great job of executing on their MVP buildout. Once their MVP is established, adding prioritized functionality transforms the product from acceptable, to good, to great.
Everyone understands the concept behind MVP. But how exactly does a company build out its MVP? What does “viable” look like? Because every company has a different product, it’s impossible to provide specific advice for each situation. However, by drilling down to the next layer of detail, insights become more clear. When discussing MVP, I typically prefer to use the following five terms:
- Earliest showable product
- Earliest testable product
- Earliest usable product
- Earliest likable product
- Earliest lovable product
The diagram below shows the MVP progression from a user’s current state to an early lovable product.
An MVP Example
These abstract concepts frame up the process, but I find it helps to provide a specific example. In this case, let’s assume we’re trying to improve the infrastructure of a package delivery business. Today, the delivery couriers (generically, “users”) have very little infrastructure — packages are hand carried by the users to the destination. Building a delivery truck for the courier may look something like the process below.
Some may ask “what is the benefit of creating something that the user can see, but not use?” This is actually done all the time across many different industries. I’ve often been to trade shows where a vendor has a product in development that isn’t quite ready for anyone to use. In such cases, a very early prototype of the product might be in the vendor’s private “whisper suite” sitting under glass. A few invited visitors that have signed a non-disclosure agreement can look, but can’t touch. If the product is an application, maybe the visitor can watch a recorded demo video, but there’s no ability to deviate from the pre-recorded demo script. There are still many benefits to this as users will start to talk and ask questions. You learn from listening to the questions asked. You get a sense for what users consider important. Often, the user asks some questions that leads to a low-level requirement that wasn’t previously considered.
In this example, the delivery truck is nothing more than a barren truck frame with four wheels. Without an engine, someone has to push the truck frame like an overgrown hand cart. The user might ask how the cart is steered or whether it makes more sense to push or to pull the platform. Regardless of what the question is, you want the user to be engaged.
In the software world, the earliest showable product might be nothing more than a bunch of web pages stitched together to demonstrate the flow of a small application. Each web page has a few constructs on it (text, fields, photos, diagrams, buttons, etc.) but there’s no material code behind anything. Everything is hard-coded with static data. The only thing that works is the navigation between web pages and maybe one or two simple features. You just want to open the eyes of the users to what you have in mind.
For this evolution of the delivery truck, the earliest testable product adds a folding chair, a steering system and a braking system to the platform. You can invite a small number of users to test the product. Users can actually sit in the cockpit and manipulate some controls. The platform may still be missing some key features. In this example, because the truck lacks an engine, the only way for the user to test some package deliveries with the truck is if the platform is going downhill. Yes, that’s clearly very limiting, but you’ve properly set the users’ expectations by communicating in advance. The point is it’s possible for a few users to put their hands on the product and provide feedback. The initial feedback might be nothing more than: 1) it’s very difficult to turn the steering wheel (because it has a manual steering system) and 2) the folding chair lacks lumbar support and gets pretty uncomfortable when you sit in it all day. Users might not be thrilled, but they are seeing rapid progress and starting to ideate with you.
After receiving the initial user feedback, the engineering team adds a few quick enhancements to the product roadmap. The plan for the earliest usable product already included an engine and a fuel system, but the engineers also replace the folding chair with a traditional automotive bucket seat and install a power steering system. Since the truck platform now has a small engine, it can carry more packages and has a maximum speed of five miles per hour. A limited number of beta users can make deliveries with the truck. Since the platform doesn’t have a body or a roof, it can’t be used in inclement weather, but at least it’s no longer limited to downhill roads only. After using the truck, the users ask for: 1) higher speed (which was completely expected), 2) something to help them lift heavier packages from the ground to the cargo area, and 3) a way to organize the packages in the cargo area. None of the engineers previously realized how back-breaking it can be to lift packages all day. Nor did they understand how it slows down the courier if they have to move other packages out of the way in order to get access to a specific package in the middle of the truck. One user specifically requested the shelving system when they needed to deliver package #2, but had to move packages #1, #4, and #5 first. These last two feedback items would not have been uncovered if the product wasn’t actually being used.
At this point, the product is really starting to take shape. The engineers add a transmission and design a shelving system to organize the packages. The lift gate couldn’t be added yet because the weight that needed to be lifted required a larger battery system, so it’s been deferred to a later release. A larger pool of users signs up to use the product. Adding the transmission increases the truck’s maximum speed, but since the engine is still undersized, the truck tops out at 35 mph. The engineering team also builds a body around the driver cockpit and passenger area, but the packages in the cargo area are still exposed to the elements. With a larger pool of users, product suggestions start to really flow in. To deal with some of the user expectations, you begin sharing a high-level product roadmap.
Finally, the engineers build the body around the cargo area, resulting in a fully enclosed vehicle. Engineers have been busy, as they’ve also added the lift gate, upgraded the engine (so the vehicle’s max speed is now 65 mph), and added basic wireless / GPS / navigation capabilities. The marketing team begins to salivate as they envision advanced real-time tracking and telemetry, giving package recipients unparalleled ability to track their deliveries. As a bonus, the marketing team also hired a graphic artist to advertise the delivery company’s logo and services on the side of the van.
Typical Pathways to MVP
The table below helps illustrate how the product development evolves from showable, testable, usable, likable to lovable.
Each of the five key designated releases (showable, testable, usable, likable, lovable) have specific goals, benefits and limitations. Each release also grows from a very narrow, restricted user base to a very broad community. The table above includes an estimated ideal timeframe to help product teams determine the general rate of progress.
Avoid the temptation to rigidly analyze the specific wording of any given cell in the table above. It is more important to remember that this represents an approach to rapidly evolve the product. Also remember that the earliest usable product will not likely be the most usable product, the earliest likable product will not be the most likable product, etc. This approach emphasizes targeting the earliest release that fits the designated goal.
Where’s the MVP?
So, what exactly is the MVP? For a very, very simple solution, it might be the earliest showable product. For typical companies, it’s often the earliest testable product. However, for a very demanding solution involving public safety, human lives, large financial risk, sensitive data, or something similar, it can be the earliest usable product. In many cases, the product team may designate the MVP as one of the Agile sprints one or two releases before or after the earliest testable product. Every startup has to adjust their definition of MVP to align with the nature of their product.
Regardless, the point isn’t to get fixated on a specific definition of MVP, but to focus on the overall process to get to MVP and beyond. The key lessons here are: 1) to iterate quickly, 2) to be very disciplined not to overload features into each release, 3) to engage users on every release after the earliest showable product, and 4) to steadily gather feedback. Entrepreneurs who diligently follow this recipe usually make consistent, predictable progress with their product development, which often leads to great success.