The difference between and idea and a product is execution. As a Product Owner, your chances of being successful are very low if you don’t have a clear definition of your MVP (Minimum Viable Product). Without the MVP being defined, you will most likely take too long and spend too much money trying to deliver your product. Why is it so vital? Simply because Product Realization means execution, and execution is the proper management of trade-offs, time, and budget. The MVP defines what features and functions are critical for the product to be launched to market. Having a clearly defined MVP crystalizes scope and focuses your team to deliver only prioritized essentials.
At LLAMAX, we have worked with several startups. All startup Product Owners have a great idea and typically understand their users and market really well. They are innovators and understand the application of their innovations very well. They are also very clear on what they can do on their own and where they need help with. Some have prototypes, some kind of working models or even beta units. However, we have found that most do not have a clear definition of the minimum set of product features that early adopters need and therefore will want to buy and get lost in a never ending quest to get everything right.
The term MVP is typically used in the software or web development context, however, it is just as critical in hardware or services. Techopedia defines it as “the most pared down version of a product that can still be released”. We believe this definition is incomplete since each of the 3 words of the moniker has a specific meaning. “Most pared down” makes sense, since it is the definition of Minimum, but it needs to provide some value at least to a subset of target users. For a startup or new entrant in a category the value needs to be unique or differentiated. Otherwise, users will stick to what’s already in the market. Notice the use of the word value. Value implies that the functionality is appreciated by the target users and at a cost they are willing to pay. That’s what makes it Viable.
A product “that can be released” as Techopedia’s definition says is not enough. In order to make it Viable it has to perform flawlessly on all of those pared down features. Quality is never a tradeoff. A marketing cliché says that good marketing of a bad product will put you out of business faster. The credibility of your brand and product relies on quality and quality needs good engineering following good processes. If your differentiated functionality resonates well with users, it has to work well. Skimping on engineering is a mistake. However, with limited resources – another commonality of startups – it is not possible to deliver all your features with quality on your first release. So a clearly defined MVP is also a resource optimization strategy.
The word Product needs clarification as well. Product Owners commonly believe that the definition of their Product – the thing, software, or service they are trying to sell – is enough. Of course it is vital and that is the “P” in MVP, but if you want to be successful, you will need your entire marketing mix – or 4 P’s – defined before you launch. But that is a topic for another post.
So we will take the liberty to redefine MVP as: The most pared down version of a product that still provides value and can be delivered with quality.
The obviously critical part of defining the MVP is what not to do. A common error is to focus on the complexity of the feature, rather than its value. It is tempting to leave behind a complicated performance attribute, but if it provides value and you can deliver it with quality and at the right cost, it is a unique competitive advantage.
As a Product Owner, you may want to hang on to your favorite feature, the one that gave birth to the idea, but if it is not what your target market considers of most value, you will be wasting valuable resources bringing it to market on the first release. Leave it in the backlog for a future version. Take a close look at all your features, performance attributes, and functions, even your packaging, manuals, and accessories if applicable. A simple table like this one may help:
|Feature||Value||Complexity||Competitive Advantage (Value * Complexity)|
|Feature A||0 – 5||0 – 5||0 – 25|
These are of course subjective numbers. We recommend having many people fill out the table on their own. Then have an open discussion until you reach consensus on the numbers for value and complexity. Then decide, as a team, what Competitive Advantage number is the minimum in order to make it to the MVP. Anything below that number goes to the backlog. Then, check the budget and estimated delivery time. If you can afford it, go for it. If not, raise that Competitive Advantage number until you can. If you are below budget, keep it there, do not be tempted to add the next feature on the list. Stick to the minimum.
Taking time defining your MVP will always pay off in the long run. Talk to your advisers, consultants, investors, target users, developers, etc. Be critical, be candid, and be realistic. Once you define it, write it down and post it somewhere in sight. Make sure all members of the team understand it clearly before starting development. It will save you time, money, and a lot of headaches. Be minimalistic. Focus on value and quality and do not give either one of them up.