Minimum Viable Progress?

*Image generated on craiyon.com with prompt "minimum viable ship"

MVP is open to interpretation and often is cited in the context of when long before it's understood 'what' to deliver. MVPs sounded great when I first heard about them on an extreme programming team. It was among the first terms of a new shared language between engineering and management. On that team, we benefitted from weekly customer feedback during functional demos. In that context, it's excellent; you will eventually iterate to a minimum acceptable feature set and get a shared success out into the wild. An MVP can serve as a motivating aspiration but also can be a dangerous commitment if it's just a Milestone on a roadmap with an arbitrary date. If you set it, you will hit a date on a timeline, what you ship will shrink to fit but it won't necessarily be valuable. MVPs should not hinder experimentation, but if they are committed to a drop-dead date, they often can stop any valid customer investigation. If a date needs to be hit at all costs, the team may be forced to push out an overly risky, untested backlog. 

Frank Robinson, who originally coined the phrase, emphasised the MVP only within the context of the journey of his packaged process (SyncDev); it was an outcome of the entire process, which engaged with customers and users from the beginning. His was a process of continually 'Test Selling Validation Prototypes' all the way to the outcome of his entire engagement.

Melissa Perri writes:

"Due to the misconception of this term, I have stopped using MVP altogether. Instead, I talk more about solution experimentation. These experiments are designed to help companies learn faster. Here we are experimenting to learn, not building to earn." - Escaping the Build Trap

Constant experimentation en route to the MVP will result in more useful software because shipping code will always incur a cost you are going to be lumbered paying for, it may as well be worth paying for, which you will not know unless you've been ideating and measuring all the way to the destination. I'm not advocating stopping using the term MVP as it's useful for cross-functionally sharing the agile mindset. In recent years I've preferred the term Minimum Viable Prototype, which I think I got from Accelerate. However, perhaps even then, it's still too milestone related and removed from a discovery process to be helpful. I think now, I will throw my hat into Minimum Viable Progress because it speaks more to a process than crowning achievement. In the context of progress, MVP becomes a suitable classifier for bounds-checking our next deliveries.

Join me to discuss the concept of MVP at the Product Junto on Thursday 16th March, 2023 at 6:30 PM It's a free event, we'll be meeting at the Barbican centre in London. I look forward to discussing.