During my workshops on agile development of physical or hardware products, I often meet people who have already heard of Agile or come from paths on agility applied to software.
Inevitably these people ask me to give an example of an MVP (Minimum Viable Product), or Minimum Usable Product in both software and hardware.
To explain what an MVP (Minimum Viable Product) is I employ the metaphor, used in the Agile world, of a person looking for a means of getting around, evaluating two possible alternative proposals. The person would like a car.
- The first proposal is to receive a car at increasing levels of completeness, but still not usable by the customer. Customers cannot accept intermediate solutions because they do not provide an answer to their mobility demand, so they must wait for the product to be completed.
- The second proposal is to receive a product that starts as a skateboard, to evolve into a scooter, then a bicycle, then a scooter to finally become a car. In this way the customer can solve his or her need for mobility in an increasingly satisfactory way. The solution acceptable to the customer constitutes the MVP.
This means that if you purchase a product with software that is still under development, it will receive several software updates that, release after release, will increase the functionality of the product without charge to the customer.
This is something we all check with our apps and software, which receive constant updates included in the contract of stipulated with the provider of the same.
The first time I tried to make an example of MVP of a hardware product, I confess that I went into crisis.
The examples I have given are of a product that is upgradeable by the customer himself by purchasing easily installed add-on modules, leading to an evolution of the product (upgrade).
These upgrades evolve the product, but in quantities limited by the condition that it is sustainable for the user to make the upgrade.
Indeed, no one would think of taking a product, several times to a service center of the company that developed it, to get an update.
Even for a fee, this operation would not be cost-effective because, in a great many cases, products are manufactured within highly efficient equipped assembly lines.
Even for a fee, the costs can far exceed the increase in value to the customer that the upgrade would bring.
I remember in this regard upgrading my MAC from mechanical Hard Disk to solid state Hard Disk. However, the labor and time required were significant, and the cost of the replacement component was only part of the total cost.
These re-entry campaigns are very expensive and are done only in the case of upgrades needed for security reasons.
In contrast, this is possible in B2B in the case of customers belonging to the group of pioneers and early adopters, who are true “sparring partners” in the development of new products.
In this case, product updates can be brought in perhaps in conjunction with scheduled maintenance activities.
Apart from these two cases, in the development of a hardware product the Pretotypes that validate development ideas and solutions are for me the example of MVP.
With pretotypes, TDD (Test Driven Development) logic, used in software to develop product elements, is also made possible.
In fact, on several occasions we have validated subsystems of the products under development, at customers available to try them on the machines they own, suitably adapted to receive them.
The pretotype is indicative of a mindset, and in fact my teams have internalized that when designing a physical subsystem, you also need to think about how to validate it as soon as possible. This is done whenever possible with digital twins.
When this is not possible, a Pretotype, representative of the product, must be designed, the validation test with the relevant laboratory equipment or at “sparring partner” customers.
I think pretotypes are MVP forms of the hardware product world.
Pretotypes make the test-driven development (TTD) approach possible in the world of physical products.
