The purpose of a minimum viable product (MVP), as defined by Eric Ries in lean startup, is to learn about customers with limited effort and money. In the blog post the problem with a lean startup: the minimum viable product, online marketer Paul Kortman shares his experiences developing a minimum viable product. He starts by shortly explaining what lean startup is:
The basics of the lean startup philosophy are to get user feedback, do user testing, and discover if people are willing to use (and pay for) the product you are creating both before and throughout the creation process.
Lean startup has the intention of making organization more efficient, by finding out quickly if there is a need for a product that they wants to develop. But organizations sometimes find it difficult to define a minimum viable product:
We all understand what Product means, and Minimum makes sense: what is the bare essentials that you can get away with?
Paul describes the questions they had while trying to develop a minimum viable product:
At what point does our product become viable?
- When we reach critical mass?
- When we have no other features to build? (ha that’ll never happen, I’m a visionary don’t you know)
- When we bring in revenue?
- When we make profit?
In the Forbes article the times are changin': the evolution of enterprise software, the director of enterprise strategy at Yammer, Brian Murray, describes what is changing in the development of enterprise software with lean startup, and why these changes are necessary:
A rampant inefficiency in traditional enterprise technology development is the attempt to build the perfect product before it’s released to customers. (…) Development teams are now focusing on building MVPs whenever possible. (…) allows service providers to efficiently test their hypotheses and ultimately create a product that slowly and continuously evolves into what it should be, not what people think it should be.
In the blog post minimum viable product vs minimum delightful product, Adam Berrey gives his view on how a enterprise minimum viable product looks:
(…) an enterprise business system will usually win on underlying technological innovation, features, and sales/marketing. If you can get just enough features to start selling, then you have something viable. You’re off and running.
Jesus Rodriguez explains in his blog post the enterprise minimum viable product: focus on viable Instead of minimum how enterprise software development is different from from consumer product development when it comes to minimum viable products. For the consumer market the user of the software is also the buyer. This is rarely the case in the enterprise world, which challenges getting product feedback:
(…) the people trying the MVP are rarely the ones making the ultimate purchase decision. (…) enterprise software startups need to be able to carefully evaluate the feedback received from an MVP, filtering the noise from the features that will make the product more relevant to potential customers
Another challenge for the concept of minimum viable products for enterprise software is how organizations base buying decisions on functionality. Jesus Rodriguez describes this as an “overfeature culture”:
For decades, enterprise software has evolved in the middle of a culture that value the number of features over the simplicity and usefulness of a product. By presenting an MVP version of your product to enterprises, you might run onto a wall of prejudices that tend to associate the number of features in a product with its robustness and enterprise readiness.
The blog post lessons from agile – the minimum viable product by Sam Palani describes why they used the minimum viable product for a complex enterprise initiative:
Yes we were bringing in tons of data and writing really complex ETLs and interfaces to extract and manipulate the data, but the actual business functionality was getting released in future releases and further planned out sprints.In an ideal world we still would have been able to succeed with our current planned approach, however in the real world we could sense the risk of our stakeholder’s patience running out.
He explains how he sees a minimum viable product, and how you can use that to develop and deliver a minimum desirable product:
A minimum desirable product goes beyond viability to include more scope and features from the requirement or scope document. Ideally you should plan a agile release or sprints with a MVP progressively moving to the MDP state in the next iterations that would deliver maximum business benefit and customer delight.
Sam describes a 5 step process to identify and define an enterprise minimum viable product. The steps are identifying stakeholders, scoping, dependency between features, prototyping, and aligning the minimum viable product with the business needs. Step 3 is about the product features:
Limit the number of interdependent features that you include in your MVP. Focus on the viable, but keep the minimum in mind. Having too many interdependent feature will limit your ability to do so.
