These are slides from the Agile Product Ownership Meetup, where we discussed the Discovery Phase of a product.
A question came up this week following a discussion on story writing that I think bears further discussion.
What really is the Minimum Viable Product?
To explain my thoughts I will use the building of a Skyscraper as an analogy.
The project vision is to build the UK’s tallest building. To achieve that it must be over 1000ft tall and 88 floors.
What is the MVP? There are many possible answers to this, but the first two responses that spring to mind are:
1 My MVP is over 1000ft tall and 88 floors, without that it simply fails to meet my vision.
But let’s say I underestimated the costs and after 65 floors I run out of money, I have been agile and each of the floors was a complete deliverable, the building is perfectly functional at 65 floors, in fact it was probably functional at 1 floor. So surely at any point it was an MVP?
2 My absolute worst case scenario MVP a single floor
This is where things get confusing. No serious customer would consider a 1 floor building with massive land costs and hugely expensive foundations ‘Viable’ the project would never be signed off. As such this is not viable. However, I’d still suggest aiming for the ability to deliver in phases, e.g. a delivery after each floor.
In this situation I’d say an MVP is the minimum that a customer would accept. And that is a conversation, would he agree to a MVP of 88 floors but a first phase goal of 20 floors, with the ability to expand later? As you can imagine the MVP is likely to change according to the circumstances. Our goal is to delight the customer but our plan is to build the product in such a way that if at any point he is satisfied or better yet delighted, we can ‘deliver’ immediately.
My point – hopefully not lost in the mix is that an MVP is about thinking about the minimum that a customer would find useful – usually this is closely related to the original vision. In the case of this building – what if the last 10 floors were empty unfinished shells? or similarly we leave the project in a state where it is valuable as is and the Vision can be achieved in a future project – The building still will meet the vision and those floors could be finished later?
Having an MVP in mind is useful, it may help with some decisions, but every project is different and MVP will likely evolve with the project. A good Product Owner or BA will be able to work out what is the true MVP and why. The PO can focus on the customers evolving needs so that the customer gets the best ROI at each stage, but most of all they will be aware of what would be the solution that would delight the customer.
An MVP is a tool like any other, in most cases it is a fall back position, not the goal.