Minimum Viable Product for Enterprises

In a software, there are always several solutions that can be offered to the users. It is common that the development team, the business analyst or the product owners, just assume which one is the best solution and which one the end users are most interested in. But, in fact, only the end users can somehow clarify to the development team what they want to use and how they want to use it. Only in a very close relationship with the end users the right features can be revealed.



MVP

In product development, the Minimum Viable Product or MVP is a strategy used for fast and quantitative market testing of a product or product feature, popularized by Eric Ries for web applications. (From Wikipedia)

"A version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort." ( Eric Ries )

"This has nothing to do with the size of the company." - VIDEO: Lean Startup on Enterprise by Eric Ries

In an enterprise software development, you can start defining MVPs as soon as you define the project vision. To identify an MVP it is necessary a lot of knowledge about the users of the application, otherwise the software will never be viable.

"It is necessary to deeply understand the essence of a product in order to strip away the non-essential parts." (Jonathan Ive, Apple's chief designer)

It is not easy to define a minimum project. The traditional Waterfall development culture of "it will not work unless all the pieces are together" needs to be abandoned. Even for very big and complex applications, it is when is more important to avoid waste. To define the MVPs, the first thing to be done is divide the big and complex application in a lot of small independent projects, which can be focused and managed in a more accurately and realistic way. After that, clearly define who the end users are and bring them as close as possible to the development team. When the software projects are simple and small, it's much easier for the users to absorb the business concepts, understand the technical needs and provide accurate feedback. As well as much faster and cheaper for the development team to produce the right results.

Almost every feature has external dependencies, mainly on enterprise software, it is difficult to isolate and develop them independently. But simulating incomplete components with mocks or stubs, allows the team to proceed with each MVP separately. The prospects become much clearer and new possibilities of implementation easily opens up. The advantages are enormous. In fact, as development proceeds, what usually happens is that several of these components and dependencies will not need to be implemented anymore, because the plan normally changes when you start to dialogue with the end users.

Each development team should focus on its own MVP and start working with the first key features. A Task Board can be used, Demo meetings, retrospectives, etc, but the most important thing is to deliver something as quickly as possible in the production environment, so the end users can personally manipulate the software and the Build-Measure-Learn loop can run the most efficient possible.

"Unlike a prototype or concept test, an MVP is designed not just to answer product design or technical questions. Its goal is to test fundamental business hypotheses." (The Lean Startup, Eric Ries)

User Delight Vs Number of Features

Catherine Courage - VP, Product Design – Citrix

Post: Lean Startups at Enterprises