In the world of tech and product, there’s a term bandied about called minimum viable product, and often shortened to MVP. On a recent internal programme, one of our product directors gave a presentation on what MVP means.
I think the above image captures it really well about what MVP actually means, and why it gets confused with other development methods.
An MVP is not a fully a realised product that you can present to your client / customers. That’s a Fully Realised Product (capitals my own – not an actual name).
The concept of MVP means you provide iterations of a product, and each iteration is usable. That means the first version is about the bare bones of the usable product i.e. the skateboard above. It’s not about the foundations i.e. the wheel base.
It’s a different way of working, and often MVP is developed in line with an agile approach to project management / product development. Working according to agile principles means development of a quick usable product – which may be flawed in many ways, but allows the user to do something. The difference with traditional development practice is that you don’t tend to have an iterative product, you tend to have a final product which undergoes review.
Working in a MVP way means fundamentally starting from a different place than traditional approaches. An off the shelf product isn’t a MVP – it’s a Readily Made Product (capitals my own – not an actual name) which is customisable. That’s not the same thing. MVP means clearly understanding user / customer / client needs, and within a short space of time providing a prototype or first iteration of a usable product – that usable product is likely not to be something already available. If it was already available, you wouldn’t need to go down the MVP approach. On user feedback, you seek to build and do more for the next iteration – with the next iteration looking and feeling fundamentally different to the previous version e.g. from a skateboard to a bicycle.
Showing your work along the way, working out loud, explaining your design processes, are not MVP – they are Work In Progress (capitals my own – not an actual name). They are good and open practices, and should be clearly understood as separate practices to MVP and agile development.
What the MVP approach allows for is for the client/customer/user to also let you know if you need to do any more or if you’ve done enough for their need. E.g. the bicycle is not only adequate, it exceeds the need and is scalable to all their staff. You can end ‘product development’ at that point and focus on making the product available to all staff and making it a quality product.
Evaluation, is built into the process of MVP because every iteration means you either progress with development, or you halt as necessary because your evaluation from feedback informs you that you’ve done enough.
Here’s a scenario of MVP development in L&D.
You have a brief to develop coaching skills for a management population. The normal approach would be something like:
Identify skills gap > identify business needs > develop workshop > review workshop plan with client > deliver workshop > evaluation > end.
That’s fine, and I’m not suggesting in any way this isn’t useful and/or the right way to do things. It’s clearly not, though, an MVP approach, nor working using agile development.
An MVP approach for this might look like:
Identify skills gap > identify business needs > develop first product e.g. one page explainer about coaching as a management tool > gain feedback > second product e.g. video demonstrating coaching in practice > gain feedback > third product e.g. action learning set > gain feedback > fourth product e.g. 2 day workshop > gain feedback > end.
I’m not advocating L&D adopt MVP or agile methodology, I think it’s important to have clarity on what the range of terminologies out there mean. It’s then up to us as practitioners to figure out which approach we want to adopt and for what purpose.