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 thoughts about the famous and notorious Minimum Viable Product.
As a PO I want to strive for 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's 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? Almost fail!
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 that's good, because humans tend to continue useless activities just because of the resources they already spent.
And here is the recipefor 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 simplest 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 that's 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 don't forget to include your stakeholders into your decisions. You may have to argue..
…but that is way better then having discussion like that afterwards. To prevent this from happening, you also need some prerequisites from the environment – 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 so much.
Continues delivery. That's 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 fixed. The scope must be variable.
Ever heard about all this M*? Minimum Marketable Product? Minimum Viable Features?
Be careful! Maybe it helps. But all these 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.
