The notion of building a MVP or minimum viable product often pops up when planning software implementation or development projects. Although it not an inherent part of agile approaches to software development, it is often cited as a means to come to a quick delivery.
In my opinion the idea is rarely fully embraced or followed, maybe related to connotations related to the word ‘minimal’ and it’s echo of insufficient, crappy or a poor excuse for not wanting to invest sufficient time and means to come to a full featured product. Majority of project owners rather want to consider it as a first release of the product they had originally in mind, being fairly full featured and complete.
Is it possible to apply a MVP approach in all circumstances or should we reconsider the positioning of a MVP as part of a project approach?
A MVP can be produced for any type of product, being it a physical product or a service provided to a customer base. The MVP is that version of the product that enables a full turn of the Build-Measure-Learn loop with a minimum amount of effort and the least amount of development time. The minimum viable product lacks many features that may prove essential later on. (Eric Ries in the Lean Startup p. 77) Thus it serves the needs of the users/customers and is the first step in a journey of learning and fine tuning the product. In this way it certainly fits the design thinking approach where it can prove to be of better service than the prototype as the MVP is put to the test in a real productive environment interacting with the intended user/customer.
Based on this description of the MVP it is ideally fit to be applied in a green-field, developing a new product or service. Based on a conceptual understanding of the needs of the intended customer a first basic version of the product can be put to the test, seeking feedback, while already earning some income through the new service or product that is ready for a ramp up based on the feedback provided by user interaction and interaction measurement. The learning based on the first use of the product can and should then be transformed into new product feature, for which the demand is clearly demonstrated, new product ‘behaviour’ or configuration conforming the wishes and needs that have be tracked based on use. Therefor producing MVPs require the courage to put one’s assumptions to the test.
The MVP is often positioned in larger organisations. However, it does not succeed in delivery on expectations. Are there obvious reasons why the MVP approach is not taken up or even met with resistance by project or product owners in organisations?
A MVP is often seen as a phase of the product development and release life cycle, when developing new solutions or replacing existing solutions. The expectation level in this situations and certainly in the latter case is not the same, maybe even not similar to those of a green-field development. In the context of the succesion of an existing product or process, one is often confronted with an extensive set of requirements, and a high level of detail in the requests detailing the needs for the product to be developed. Unless the product to be developed holds a complete change of concept, the set of requirements is often that large and detailed that the initial release can, in my opinion, hardly be considered a MVP.
The cited MVP is not really an MVP in a large number of enterprise projects. In the context of the succession planning of an existing application, the product to be delivered, even though the technology or system basis changes is a new release, not a new product. Current users expect the new product to perform better than the product they are currently using. It should contain all current features, be modern and have increased performance and improved usability compared to the current product. The product to be delivered is not subject of discovery and learning it is expected to be an improvement for features well known and – when lucky – well documented.
It is to be discussed whether providing automated support to a running process can result in the release of an MVP. Although the (software) product may be new and its usage and usability is subject to testing and feedback, process and information support requirements are sufficiently known to be explicitly discussed and documented. It might be that the processes to be supported are fraught with bureaucratic controls and needs to be cut down, the concept as such is not to be tested.
Even when we are talking about a real MVP, there are potential reasons for reluctancy to adopt a MVP as step in the way to the implementation of a solution of product are to be found in relationships, the disruptive nature of the approach where majority of interactions are contractually defined.
Relationship with the IT solution supplier – an external contractor is expected to work for a limited time and should deliver the product as defined initially, when granting the project. Even when working with the internal company or organisation’s own IT department, relations are often not as smooth as they could be. In some cases the department is seen as an enemy, it transpires to know better the needs of the business than business departments do and behave in a similar contractual relationship as the external supplier. Challenged by lack of resources, they tend to block of extra requests or changes in scope or requirements, increasing resentment while taking a reactive stance rather than pro-actively participating in the definition of the product along and together with the business department that is product owner.
We want everything to go to plan attitude is part of the overall culture we live in. This need-to-be-in-control, and to act in a predictable way, leads to a lack of open communication, where mistakes, misunderstandings and planning deviation are tucked away by not communicating or vaguely communicating about progress, results and problems while preceding in the development of the product. An efficiency culture that starts with the premise that all is to be done based on past experience, known facts and on precedents or similar activities executed in the past increases expectations and decreases the perceived need to be explicit and clear when expressing requirements and desires. It has been done before, relax, is the standard (requested) attitude… Focus is not on a discovery of the real need and the real added value as design thinking promotes.
In order to profit fully from agile and lean innovation concepts including the use of MVPs, a cultural turn around is needed for departments and enterprises that will thrive on innovation and adaptability. They should go from a command and control view on things, where the few plan and think out products and the majority execute without question what they are ordered to do, to a learning and improvement attitude where everything is in flux, knowledge is gained and all participants in the organisation participate in creating it and its products. All concerned have to work with the same overall purpose in mind, bringing down the walls between departments and teams introduced with an eye on efficiency and task specialisation.