You had a great idea for a software product or service and can’t wait for the world to start using it. Now you have to face a difficult but crucial question. Do you invest a lot of money and build as much functionality as possible upfront, or do you wait months for the product to be completed, potentially allowing others to beat you to go-to-market?
Most people in the industry would agree that building a minimum viable product (MVP) is the sensible route to take. Regardless of how mature a company is, be it an early stage startup or an established business, the MVP is the proof in the pudding that shows the effort you’ve spent so far on your great idea hasn’t gone to waste.
Due to its importance, it’s no surprise that engineering managers, product managers and startup founders are so obsessed with getting the MVP right. That process might involve squeezing every ounce of productivity out of the engineering and design teams to get it done as quickly as possible or holding up the release for months on end until the leadership feels that the MVP is sufficiently fleshed out. Either way, the run-up to the MVP is an exciting, frenetic time for a business.
It’s easy to see the flipside of this obsession: the release of an MVP is often plagued by the fear of getting it wrong. Releasing too early gives you the advantage of being able to change direction more quickly, but that comes with the risk of affecting your reputation as a brand if the product is buggy or incomplete. Doing it too late, on the other hand, might mean you threw away a lot of money chasing the wrong rabbit while the market and the competition have been moving forward and moving on.
All this brings us to one question: When should you release your MVP? The answer to that question depends on what you’re trying to get out of it.
The Real Purpose Behind An MVP
Earlier, I mentioned that you can use the MVP to verify your product’s direction, but what does that mean in practice? Ask your various stakeholders, and you might be surprised by the different takes you’ll get. Here are some common ones.
In technical startups, the MVP is often built as a showcase for some bleeding-edge technology. In these cases, the technology is so new that the team must make up problems that it can solve. The issue with this approach is that often these problems are artificial, and they aren’t dictated by a real market need. Looking at the gadget market, we can see an example of this in the Samsung Galaxy Fold from 2019. This phone was built around the technology of foldable OLED displays, with an extremely high price tag and no real advantage over a standard slate phone. It created some buzz, but disappointed in terms of sales performance.
In the past, I’ve worked on a couple of projects where the MVP was built with this intention, and neither was successful. In both cases, we had to go back to the drawing board and get potential users (i.e., our prospective target customers) onboard to find a valid application for our idea before building the next iteration. That’s extremely expensive, as you might have to throw out all the work you’ve done so far. In fact, one of the projects didn’t even manage to create another MVP before the startup ran out of money.
Another reason why companies build MVPs is to test the market. Let’s imagine that a more mature company than the previous example, less dependent on showcasing their tech, has determined that the idea satisfies the needs of a few users and wants to ensure that the market is receptive before investing further. This is a valid use case for an MVP, but you could also consider cheaper alternatives. On the more conventional side of the spectrum, you could use surveys to gather intelligence on the market before you go ahead and build the MVP itself. On the opposite end, you could engage with crowdfunding (if applicable) or customer registrations (a la “Keep me informed”/“Register now to find out more”) and pre-orders before beginning production.
A third possibility is that you’re building an MVP just to test your idea. This scenario is similar to the previous one, except here you don’t even have an initial group of potential users. In this case, a full MVP is likely overkill. A better approach is to use prototypes and proofs-of-concept to test your idea before pouring more effort into producing a full MVP. You can use these prototypes to engage with an audience and find your initial following. Then, with concrete data from the marketplace, you can flesh out the MVP based on their feedback.
What Is an MVP, Actually?
“Wait a minute,” you might well say, “how’s a prototype or a proof-of-concept different from an MVP? Aren’t they the same thing?” Well, not quite. Let’s look at how they differ by taking a hypothetical email app as an example.
A prototype is make-believe. It’s an implement that shows the user experience (UX) for your would-be product, but it lacks functionality behind its facade. In the case of an email app, a prototype would show the inbox, the compose screen, the single email screen, and all the interactions that would allow the user to compose, read and reply to emails, and perhaps even how moving emails to different folders and deleting messages works. The prototype would just offer sample data, however. It wouldn’t actually send or receive real emails nor make modifications to a user’s inbox.
A proof-of-concept is basically the opposite of a prototype. It verifies the technology you intend to put behind your product without much care for real user interaction. Looking again at our email app, a proof-of-concept would need to connect to a real email server and download email from it, but it wouldn’t present the messages nicely to the user. Perhaps it would also show a simple list of all the subjects for all unread messages without much care for formatting or pretty typography.
An MVP, on the other hand, is fully functional. It combines the UX with the functionality that makes it work. The MVP is the most basic iteration of your idea that could be considered a real product. The difference between an MVP and a fully fledged product, then, is in the number of features implemented, with the MVP offering the bare minimum to make the product usable. An MVP for our email app would allow us to see a list of unread messages, read email and compose and send new messages. It might lack more refined features such as saving drafts, folders support, and perhaps even reply-all and CC, though. The MVP does a subset of the full feature list, but it does that subset as well as the full app will.
Having said that, these three implements aren’t mutually exclusive. On past teams, I’ve seen functionality start out as prototypes and proofs-of-concept before turning into actual features after proper revision and re-implementation. This activity is often referred to as productization. The lessons learned from the prototype and the proof-of-concept are incorporated into the design of the feature to produce a highly polished final product.
In fact, prototypes and proofs-of-concept are often merged together into a hybrid that offers both some of the eventual UX with functionality behind it. In these cases, productization consists of improving the quality and stability of both the user interaction and the code behind it so that they’re fit for real-world use. Sadly, as productization work happens mostly behind the scenes, justifying it to other stakeholders can be difficult. They might feel that the prototype and/or proof-of-concept is already good enough and should itself be released as the MVP. The issue is that, when producing prototypes and proofs-of-concept, the team is more focused on getting something out of the door fast, with less concern over edge cases or performance under heavy loads. Highlight these shortcomings to resistant stakeholders, as releasing an unstable MVP could cause the image of your company and brand to be tarnished by the poor performance and subpar quality of such a release. Speed to market is important, but even more important is making a quality product.
So, How Long Should It Take?
Now that we’re clear on the purpose of an MVP and its difference from similar pre-production implements, we can perhaps have another go at answering the opening question for this article: How long does it take to build an MVP?
First of all, building an MVP should take long enough that its intended functionality is fully implemented. You should treat the MVP as a full release. It should be stable, performant and, if applicable, scalable. Keep in mind that an MVP is allowed to have a restricted feature set, though. It’s OK to have “coming soon” areas in your MVP.
It’s also OK to ask for user feedback within the MVP itself. In fact, as long as it doesn’t break the overall user experience, soliciting feedback can vastly raise the MVP’s usefulness. After all, its purpose is to verify that you’re heading in the right direction with your product, and there’s no better indication of that than the feedback of your users, along with the uptake of the MVP itself. Remember to take any feedback with both a grain of salt and an open mind, however. The early adopters are only a subset of your potential user base, and as such they might present a skewed view of what your full product ought to be. On the other hand, they still represent the market. Ignoring their feedback completely if it goes against your team’s ideas is a very risky endeavor that might result in the production of a good or service that nobody needs.
In closing, the MVP is an excellent tool to prove that you’re implementing the right functionality. In the end, though, it’s worth remembering that the MVP is just a tool. It’s not your full product. There’s still time to course-correct after launching an MVP to address product-to-market fit. As such, you shouldn’t be afraid of releasing it. As long as it’s fully functional within its limited feature set, and quality-wise it portrays what your product is going to be, you’re good to go.
