There is hardly a term where when I ask different people what it means I get as many different answers as with the MVP. For some, an MVP is already a fully developed piece of software with more functionality; others actually see it as the minimum expansion stage of a product. For some, an MVP can contain a multitude of bugs, for others it must be fully productive.
There is hardly a term where when I ask different people what it means I get as many different answers as with the MVP. For some, an MVP is already a fully developed piece of software with more functionality; others actually see it as the minimum expansion stage of a product. For some, an MVP can contain a multitude of bugs, for others it must be fully productive.
The fact is: An MVP - a minimum viable product - should be used to deliver functioning software to the customer at an early stage and thus to collect feedback as early as possible in the life cycle of the product being created.
The big misunderstanding about agile product development
I found the best explanation for an MVP in a blog post by the Swedish agile coach Henrik Kniberg. By means of a very nice graphic, he does away with a great misconception about iterative and incremental (aka agile) product development. The top row shows simply how not to do it. The example shows that the customer has ordered a car. Incremental development now provides a result with every sprint. Of course, the customer will say we're crazy if we just provide them with a tire in the first step. Even in the next steps with the provision of the chassis and the body, we will not make the customer happy. Because ultimately none of the sprint results can be used in any way.
Learn about the customer through early feedback
And that's exactly what agile product development is all about: At the end of every sprint there is a usable result, which can be used by the customer to gain feedback for the next iteration. In doing so, we always question the customer's intention, the why for the desired product. This is now visualized by the bottom row.
Even if the skateboard delivered in the first step will certainly not cause the customer to jump for joy, it is a fully usable product that already addresses the customer's underlying problem: moving from A to B.
In order to eliminate handling problems with the first throw, a handlebar is donated and the skateboard mutates into a scooter in the next iteration. With a bicycle in the next iteration, we are tackling the problem that longer distances can be covered if necessary. And then we learn more things about our customers during development: Maybe they love the wind on their faces and moving around in the open air? Maybe he's already completely satisfied with the bike. Maybe two wheels are enough for him in principle and to get even faster and further he would like a motorcycle. Or in the end it will be the car.
All of this is decided in the course of using the product based on the feedback received. Feedback that - if we had developed the product as shown above without fully functional increments - we would only have received at the very end. By providing a minimally viable (or, as Henrik Kniberg puts it, minimally lovable or minimally testable) product early on, we receive valuable feedback, can perfectly adapt and control further development and also save costs for things that the customer does not want or want needed.
From real life: An MVP at atrify in the GS1 Data Quality Excellence Service
At atrify, we created an MVP together with GS1 Germany and SmartDataOne last year. With the GS1 DQX Service , products exchanged via the GDSN are to be compared with product images, for example, through an assessment process, to determine whether the product data supplied matches them, in order to sustainably increase the data quality for retailers.
The GS1 DQX Service came with an almost hundred-page technical concept, in which all requirements for the assessment process and the required system were described, were therefore quite “waterfall”. We got the customer on board right from the start in order to convince them of the agile implementation of the service in the long term.
Initially, we have the rough concept
To the original article
