In the beginning, there was an idea. Much has happened since then - talks with partners have stretched long into the night - but finally, design of the platform has commenced. That's when a question arises whose answer has big implications, and whose impact is very hard to determine: should we start with an MVP or an MLP?
First of all, what do these two acronyms stand for?
MVP stands for Minimum Viable Product - the earliest stage in the product's development at which it is able to survive on the market. The MVP counts on the pure 'disruptiveness' of the product to win a following, with the emphasis more on the idea itself than the quality of the implementation.
Starting with an MVP is often considered ideal for startups, the approach compromising between budget and speed of deployment: but it is currently being challenged by a new way of thinking which, inspired by the needs of the sharing economy, says that we should instead aim for a Minimum Loveable Product.
As we've already noted elsewhere, the priority for service marketplaces is to create a community. The idea of an MLP is that for users to be loyal, they must not just use a product, but also love it - and that a product shouldn't be put out there until it's good enough to be loved.
From Apple to Harley-Davidson, the concept has been around for a while - but with new giants like Tesla and Uber now rapidly ascending, it's picking up steam more than ever. But all managers face the challenge of juggling the equation of price, quality, and speed.
Your priorities here, and the room you have of maneuver in each category,could help determine whether you should look at MVP or MLP :
- Compromise on price: if you want to create your product for a lower price, you'll need great negotiation skills.
- Compromise on quality: choose MVP. In sharing economy projects, whether B2B, B2C or even C2C, compromising quality should be avoided, even for a proof of concept. In fact, the proof of concept is far riskier than it appears, for a start because the MVP product must compete with MLP rivals - this could leave your project lagging behind the competition in a way it can never recover from - even if your timing is excellent, customers could easily be distracted by a slicker rival. If the implementation is not robust, is unstable, or doesn't possess a user-friendly interface, users will be put off. It's necessary to understand that the message sent when managing this kind of platform is that we pretend to be able to conduct a transaction between two people who do not know each other, and who each have no confidence that quality service will be given. Bankers wear ties to show the clients they can be trusted - by not compromising on quality, you 'put a tie' on your product.
- Compromise on timing: choose MLP. As with any endeavor, time cannot be compressed. The first thing to make sure is that your time limit makes sense:
- An unbelievably short timeframe suggests a lack of experience or a deliberate lie told to win a tender. If a timeframe seems too short, run! You will lose much more time than you ever had the chance to gain. Trust is the cement of all relationships.
- A too-long timeframe (more than six months for a web project equally signifies a lack of experience. Momentum must be kept up and is too difficult to compensate for once lost.
Since your competitors will also have to make an investment of time if they want to enter the market with an MLP, we suggest that this is the area in which you accept compromise.
The ideal starting point to penetrate a market is to bring an MLP to a community already demarcated by one or more MVPs: the proof of concept is already done, the community formed.
