The following Ignite-Talk* was held by Benjamin Wyss at the DevOps Days 2022 in Zurich.
*Speakers are given 5 minutes and 20 slides that auto-advance every 15 seconds, making for a fast and fun presentation.
Video
Talk
Hi Folks.
I am Benjamin from Infometis and today I would like to meme you my thougts about the famous and notorious Minimum Viable Product.
As a PO I want to strive to as simply products as possible.
Because every feature
- is a potential source of whatever kind of error
- needs to be maintained
- or can make a product more complicated
That is where the MVP comes in. But let’s have a look back first.
In 2001, a guy called Frank Robinson tried to solve the problem, that the number of features is more important than the value they actually bring.
He got this Outcome vs. Output Stuff very early.
Frank said, we can find the MVP, where the Return on Investment is high and the effort is low.
Some of us would call it the Pareto-Principle, or just 80/20.
In 2011, the MVP gained popularity with the Lean Startup methodology. Why? Fail fast!
Big Enterprises can wait, but if you have venture capitalists, they want to see progress.
And we know…
…Working Software is the Primary Measure of Progress! The other stuff are just side dishes for your delicious main course. The tasty product.
But what is „a tasty product“?
We make assumptions about that. And with the MVP, we want to test them early.
And thats good, because humans tend to continue useless activities just because of the ressources they already spent.
And here is the recipe for something viable
- The unspoken basic needs
- Sufficient performance needs your stakeholders will ask for
- and some cool stuff your users will love
And for every need you want to fulfill…
…try to find the simpliest solution possible – Or as the Manifesto says:
„Simplicity – the art of maximizing the amount of work not done – is essential.»
GitLab writes in their values: «We always go for the Boring Solutions».
And I think thats great. Invest time into thinking about simplicity at the beginning, makes you faster on the long run.
With that in mind, we can go and find the most boring solution for as few needs as necessary.
But do not forget to include your stakeholders into your decisions. You may have to argue…
…but that is way better then having discussion like that aftwards. To prevent this from happening, you also need some prerequisites from the environement – or at least the will to create them.
For example:
An MVP is NOT the end. It tests your assumption. Therefore, you must be willing to build, measure, learn and adapt.
Somone in the internet once said, that Leonardo da Vinci said:
«Art is never finished, only abandoned».
And in the great book «The Professional Product Owner» it is written as:
«Because no product is ever „done“, you create a series of MVP’s, one after the other» .
Unfortunately in the project world, where the primary measure of progress is the project plan and the count of «features», either – the first and last thing customers see is the MVP – or…
…you really need to be patient to include the learnings into the next release. This is why I love DevOps that much.
Continues Delivery. Thats technically implemented Agility.
But there are also some traps. MVP does NOT mean get the shit done with compromises in quality or by getting into technical dept. Because this will catch up with you.
You may win the sprint.
But collapse during the marathon. And you end up doing more stabilization then feature releases.
Remember: Quality, Cost and Schedule can be fix. The Scope must be variable.
Ever heard about all this M*? Minimum Marketable Product? Minimum Viable Feature?
Be careful! Maybe it helps. But all this terms have a huge potential to confuse your stakeholders.
If there is one thing I want you to remember, it’s this:
Use the MVP as a thinking process to get the most simple and boring solution possible for your challenges.
