There is a fog surrounding the minimum viable product (MVP) concept . Startups took MVPs mainstream. In the process, “best practices” evolved and the definition went from simple “first MVP is just a landing page” to wireframe prototypes or applications that are sometimes viewed even as feature complete.
“The minimum viable product is that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.”
Enterprise Minimum Viable Product
The enterprise world wants to adapt and adopt startup best practices and MVP is one of them.
Enterprises however are not yet comfortable with the fast development cycle that agile and MVP’s bring to the table. For a small company, it is almost natural today to start off with a new product release that is just a landing page, then move into an alpha version of the product that has only one feature and then a beta product that is slightly more advanced. That is because startups understand that making mistakes and learning as they go is cost effective and gives them a better understanding of the market, which they do not have yet.
Start small and validate as you grow
The challenge with enterprise minimum viable product is how to start, and how to define it. Releasing something that is feature incomplete, or a landing page can be seen as a product failure inside the company. For decades enterprises released highly complex products and features are seen as an indicator of quality. Successfully implementing MVP driven approaches in large organization, requires a mindset shift towards how to learn about required features in a structured way. The goal should change from releasing complete products, to learning about the product throughout the release cycle, and focus future investments towards functionalities that have the greatest ROI possible.
Define “small” to your context
Even though starting at a bare minimum, such as a landing page, can be a great approach, the concept of MVP’s is not rigid, and allows an organization to tailor it to their own situation. Eric Ries provides a more in depth overview of what he means by MVP, and as we see, the creator himself defines it broad, as a framework and not a predefined approach:
MVP, despite the name, is not about creating minimal products… In fact, MVP is quite annoying, because it imposes extra overhead. We have to manage to learn something from our first product iteration. In a lot of cases, this requires a lot of energy invested in talking to customers or metrics and analytics.
Second, the definition’s use of the words maximum and minimum means it is decidedly not formulaic. It requires judgment to figure out, for any given context, what MVP makes sense.
Using MVP in enterprise solutions
Using an agile approach and the MVP concept in enterprise projects is not conceptually different from a startup project. The main differentiation is the constraints that are imposed by the way of work of a large company. The second one is the perception that a public release should only be done with a perfect, feature – complete product.
A rampant inefficiency in traditional enterprise technology development is the attempt to build the perfect product before it’s released to customers. Brian Murray, Director of Enterprise Strategy @ Yammer (full article here)
Challenges in using enterprise minimum viable product approach
Enterprises work with fixed budgets, so the idea of expanding as you go through iterations, and creating an initial product that is not final is the first and main challenge. We learned this the hard way, and as time passed by we adapted our message to enterprise clients. Agile approach, and MVP’s are less controllable upfront from a budget perspective, or timeline perspective. There is no fixed release date at which the perfect final product goes live, nor a fixed budget to accomplish the perfect product.
But how does the perfect product look like anyway?
Instead of falling in the trap of committing to old outcomes using new approaches, we assure our clients that within a fixed budget, we can create the perfect product for that budget that is released on the date we say we do.
Traditionally, software companies did a full specification upfront, fixed the budget and the deadline and off the project goes. The highlights?
- Large IT projects run 45 percent over budget and 7 percent over time, while delivering 56 percent less value than predicted according to McKinsey.
- Both customers and providers play a never ending game about what is and what is not an RFC (Request for Change).
- RFC’s cost is not usually associated with the actual project cost, but they exist.
- Everyone is focused to deliver a product that is considered perfect by the implementation team not the end user.
- Once the product is released, additional development is needed to align with user feedback, and account for usability concerns.
In brief: the fixed budget is not a fixed budget after all. The fixed deadline is usually an agreement that “everyone tries to release on X date”. The perfect product from day one becomes obsolete. The feedback from the final user may add additional complexity to a system that is already built in a certain way.
Patience and trust are important in adopting MVPs in the corporate world
Sam Palani described the enterprise challenge from a different angle. In a blog about agile and minimum viable product, he underlines another aspect: patience and trust.
Yes we were bringing in tons of data and writing really complex ETLs (Extract, Transform, Load procedures) 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.
How MVPs support enterprise thinking product development
For larger projects, the customer is blindly trusting that within months from now, a piece of software will come up that matches his expectations. Our own experience is that expectations at the date of signing an agreement and starting a project are different than those over a 6 or 12 months period. This is to be expected, and is normal. The market, business, and perception over the project all evolve and change. Managing expectations then becomes a task in itself. With agile and MVP’s on the other hand, the expectations align with every release and every iteration.
Let’s dive into the same list from above but from an agile and MVP approach.
- The goal is to have a production ready product at the end of every iteration.
- There is no concept of request for change. Everything… and I do mean EVERYTHING is part of the scope of development. The focus is shifted from who is right or wrong in RFC’s, to what the client and user believe to be a priority for the MVP.
- The product is focused on being perfect for the users. After first MVP is launched, the development road map benefits from input of final users and usage analytics.
- Whenever a product is released, it is the best existing version of the product. There are no RFCs to align the product with the market. Everything left on the road map are just additional new features that can further increase ROI.
In brief: with a fixed budget you do get a perfect product. It may not be the final product, but it is the perfect one for that release. The release date is known and truly fixed. The feedback from the final user adds value to current system not additional unwanted complexity.
The result is that using an iterative enterprise minimum viable product approach will “create a product that slowly and continuously evolves into what it should be, not what people think it should be.” As Brian Murray, from Yammer bluntly says.
Changing corporate mindset is key
In the same blog from above, Sam Palani reinforces this point very clear and expresses the same ideas that we at Maxcode experience every day:
A minimum desirable product goes beyond viability to include more scope and features from the requirement or scope document. Ideally you should plan an agile release or sprints with a MVP progressively moving to the MDP (Minimum Desired/Delightful Product) state in the next iterations that would deliver maximum business benefit and customer delight.
The Minimum Viable Product can make a difference in enterprise software. It can help organizations adopt agile practices better, and it can shift innovation and product cycles from years to months or even weeks. There would be one thing left to tackle. The overfeature culture may be the last obstacle. Enterprises are still under the perception that more features equal more robust product. As Jesus Rodriguez states:
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 only thing we can do as software suppliers, is to showcase with every new client and product that “it works” and it delivers business value.
