Updated: Feb 16
The process to develop a product in a startup or any environment with high levels of uncertainty is very different from the traditionally used model. In a startup, the problem (what the customer needs) and the solution (what the product should do) are unknown. To know them requires a combination of an iterative process to understand the customer's problem through hypotheses and experiments, and at the same time, develop the solution through data and feedback. In practice, this process requires developing prototypes and multiple versions of the product to show it to customers and refine it based on their reactions.
This approach, which combines elements of Steve Blank's Customer Development Process and agile development methods, is a Lean Startup and the Minimum Viable Product (MVP) is a key strategy to help customers. Startups build their product while learning what the market needs by focusing on multiple product iterations to refine it based on customer feedback.
An MVP allows you to learn about customers.
A Minimum Viable Product is a product version that allows a team to gather as much validated learning from customers with the least possible effort. It is used to quickly, quantitatively, and qualitatively test the market response to a specific product or functionality. An MVP has only that functionality required to show the product to the customer. Its main objective is to avoid developing products that customers do not want and maximize customer information based on the cost and effort invested. Despite its name, MVP is not just about creating a product. It is a strategy and a process focused on developing and selling a product to a specific group of customers. It is an iterative idea generation, prototyping, presentation, data collection, analysis, and learning process. If the goal is to create something quick, an MVP might not be necessary. In most cases, an MVP requires additional efforts to talk to customers, define metrics, and analyze the results.
An MVP is focused on early adopters and visionary clients.
An MVP contains only the minimum functionality required to learn from "early evangelists" - visionary clients and early adopters. Typically, the product is focused on this type of customer, who in principle are more tolerant, are more willing to provide feedback, and have a greater capacity to understand the vision of the product with only a prototype or basic product information, in addition to helping to fill in the 'gaps' in desired functionality.
An MVP may be different depending on the product.
There is no exact formula to define an MVP as a certain level of judgment is required and depends on the context of the product. For example, the team at IMVU, a 3D Instant Messaging customer, took six months to create its original MVP, in contrast to other companies where the first version takes five years before launch. However, at other times it can take up to 2 weeks to develop certain functionality that, in the end, nobody wanted when a simple test through Google ads could have shown in a few days that nobody was interested.
An MVP allows you to learn and change directions if necessary.
The most significant waste in creating a product is building something that no one wants. An MVP seeks to verify that the product effectively solves a market need before investing too many resources in its development.
Usually, a prototype is built, and after showing it to some clients (even if no one wants it initially), through rapid iteration, it is possible to correct the course without having to invest extra effort, thanks to the frequent feedback that is had, compared with spending months locked in building the "perfect" product and then realizing that it was not what the market wanted. The critical thing to remember is that if the product solves a real need, an MVP allows you to achieve a big vision in small increments.
A metaphor that helps illustrate how the process works is the concept of the Observe / Guide / Decide / Act cycle concept that has its foundations in military theory. According to John Boyd, the creator of the model, "the key to victory is being able to make the appropriate decisions faster than the enemy."
The same principle applies to startups, which usually face the problem of maneuvering in the field with confusing or unknown conditions, so they must have the ability to generate hypotheses, learn quickly and react to unknown conditions. An MVP is one of the critical tools that allows this learning to be achieved, since it allows multiple iterations to be carried out, which facilitate learning and flexibility.
How to build an MVP
The main objective in a startup's development process is to minimize the decision cycle, which consists of Build - Measure - Learn through ideas, code, and data, seeking to reduce the total time in each iteration. The process is repeated until the product that effectively meets the market need is obtained or when it is determined that the product is not viable.
Examples and techniques
Here are some techniques and practical examples of MVPs in action:
Only a landing page. This approach is what we could call "sell before building" and starts with only a landing page (landing page) describing the product to be developed with a link to request more information. Advertising on Google or other means generates traffic to this page and offers the product. In this simple experiment, it is possible to check how much interest there is in the product - for example, if 0% of the visitors click on the purchase offer, there is no reason to develop the product. We already know that there is no interest in it. It's best to use those resources to redefine the product and find what features the market wants.
Test specific functionality. Insert a link to new functionality in a web application, which directs to a section with more information or requests the user to register their interest. Links are logged and serve as a measure of how necessary that functionality is. For example, Fliggo (a video sharing service) started offering a paid version in addition to its basic version by asking its customers if they wanted to be notified when the new product was ready. By doing this, they were able to measure user interest - if too few signed up, they knew that this was not what customers wanted without having to build the entire product.
Eliminate functionality, focus on one thing. The original idea for Grooveshark (online music service) was to combine elements from Limewire, eBay, Wikipedia, Facebook, LastFM, and iTunes. After realizing that the product was going to be incredibly complex (a Frankenstein monster, according to one of the founders), the company focused on offering a straightforward function: find a song and play it. After testing various hypotheses, they began to add additional functions.
Create a simple product. The first Twitter prototype was created in two weeks, enough for several users to test it. If two weeks seems too long, consider that Cloudomatic's MVP, a service for promoting online applications, was built in one weekend. Hence the phrase: "there is a 2-week version of whatever."
Manualization (flintstoning). To check whether or not a client requires certain functionality but without carrying out a complete development, the "flintstoning" strategy can be used, which consists of giving the appearance that something is done automated, although actually behind the scenes, it is done manually. The term comes from The Flintstones, who moved their cars with their feet. There is a story of a person who wanted to sell cars online, but this required writing a rather complicated product, and he did not know if it would work or not. So he created a website with forms, but all the information processing was manual - what happened behind the scenes was done by hand - and this was enough to confirm that the business could work.
Release 1.0 and iterate quickly. The most important recommendation is to release the first version of the product and iterate based on customer feedback. For example, PayPal started as a money transfer service between PDAs, and soon after, they realized that there was not much demand for this product. However, they also noticed that the email money transfer functionality (a feature they hadn't even paid much attention to) was attracting multiple users, and the rest is history. Other examples include the first version of Facebook, Windows, and even the iPod 1.0 (pictures of all these first versions can be found on Wikipedia). The golden rule of thumb for when to launch comes from Reid Hoffman, founder of LinkedIn: "If you're not embarrassed about the first version of your product, you waited too long to launch."
In conclusion, validating ideas before investing is always welcome in any environment. The client is the one who will always have the last word so that our products are successful, and your feedback is of the utmost importance. At Alset, we have a process for validating ideas and projects based on the Sprint Design created by Google.