MVP or not?! – A misunderstood pic goes viral

This morning a pic showed up in my timeline that I had hoped not to see again. But it seems the pic has gone viral and is used out of context numerous times. It was a picture from the Agile Testing Days Scandinavia keynote “Why we do not need testers on the team” by Bent Myllerup to demonstrate the concept of an agile approach to software development, delivering value more often and developing software iterative and incremental.

Media preview

Let me describe what I see in this picture, and why I think it’s the wrong picture to describe the concept of MVP (the minimum valuable product). My problem is with the right part of the slide.

This picture is made by Henrik Kniberg and described in this blog. Henrik is also stating that his picture is used often, and not always in the right context. So why do I think that this picture is not showing what it should?

The upper part: For me it looks like that the customer wants a car. Somehow he gets multiple deliveries, while the product is built. I’m not sure, why would you deliver a partial product that’s unusable. But this picture should show the advantage of Agile, so I accept it as a stupid exaggeration for the sake of context.

The lower part: This picture should describe the principle of iterative and incremental development with multiple deliveries bringing (some) value to the client early to gather feedback and deliver the right product in the end. But now comes the problem of using manufacturing comparisons for software development; they usually don’t work. When software is built incrementally, you don’t need to start over after a delivery, and the part that was delivered must not be completely redesigned. In this example the customer gets 5 different products. But the second is not based on the first, the third not on the second and so on. This is an example of poor understanding of the needs of the client. This could either be that the client doesn’t know what he wants, and we slowly find out together what he wants, with an enormous effort to generate five different products. Or we were not able to ask the right questions and get additional information only by delivering something wrong to get more clues on what the client wants.
In the first case at least the client has to pay 5 different products, I suppose. In the second I presume we deliver five products for the price of the last one, which would not bring us enough money for all the effort we had.
I can imagine one scenario where this is absolutely valid. When you are a salesman of a company offering those five products and a customer comes in and doesn’t know what he wants, he can present him five different solutions, until the customer found what he wanted. But this is not Agile! And it does not apply to software development either, at least not if you want to stay in competition tomorrow.


So let’s look at different situations what a “minimum valuable product” is, and how you come from there to offer the client what he really wants. The scenarios I want to look at are:

  • one customer
  • few customers
  • many customers

MVP for one customer

A customer comes to us with a problem (or multiple) to solve. Asking the right questions we could find out what the customer most obviously wants to have. We find out what the most basic thing might be to solve a part of the problem. Then start off in that direction and showing him our first throw. The customer then can tell us, if that goes in the right direction or if we need a course change. We adjust and add value to the product as we go on, until the customer really gets what he want.

I like Cassandra Leung’s approach for that to find a real live example:

Media preview

MVP for a couple of customers

Let’s assume we have a couple of customers who share a similar problem. Our task would be to ask enough questions to all of them to find out about what parts of the problem they have in common, what parts are shared by some of them, and which parts are unique to some customers.

Our MVP in this case would start with providing some basic value of the common part, so that all customers could benefit from it. Getting feedback we sharpen the understanding for the problems of our customers and how to solve parts of the problems in a common way and where we need to start focusing on solving problems differently for some of them. Developing features now after customer directions might also influence some of the customers, showing them different approaches how to solve their problem. This might bring value quicker to them and also influence the desire for the final solution.

An example would be special business software, focusing e.g. on one branch of the industry, where multiple market participants share a common problem to be solved.

MVP for many customers

This is more like looking for a new product that many customers would want to use. So you need to find a common problem for them to be solved. Since there are too many market participants to ask, you better get a product owner who knows his business and has a good understanding and overview of the problem at hand. Now we start much like solving a problem for only one customer. When we bring the MVP to the mass market we start getting feedback from “many”, if our solution is serving the many or not. Based on a vision or on feedback from the customers you now start adding features, continuously collecting feedback from the users. When the product grows you might start developing features that add value to only parts of your clients.

You should not shy away to remove features, if they are not used enough. Features cost money to maintain, and if they bring no or not enough value to your customers, get rid of it again. You might also learn that your MVP is solving problems you hadn’t had in mind, when you were starting to develop it. Then it’s good to have early feedback to change your course and address a different group of customers.

A real live example would be e.g. a text messenger for smartphones. SMS were expensive, but internet data connections were cheap compared to that. So text messengers using the internet were coming up. Then adding feature by feature, like sending pictures, voice bits, videos, etc. Some features are not used by all, some more often, some less, some are removed again, when they flop.

My tip, when explaining the concept of MVP to someone, describe the context. Makes it easier to understand.
If you think I did misunderstand the concept of MVP, please let me know so in the comments.


One example to show how MVP development works in non-software industries, car manufacturers. It all started with Ford’s model T. There was one kind in the beginning, then slowly starting to evolve for different problems to be solved. One company that accompanied me all my life is Audi. When I was young there were about three different models. A small medium (80), a big medium (100), and a big model (200 / V8), which then became A4, A6, and A8. Something to find for most people. Then people were looking for smaller cars and Audi wanted to have those customers as well, the A3 came. Then they invented something even smaller with the A2 and something sporty with the TT. Then the palette increased on the small end with the A1, and sporty versions in the medium to large segment with the A5 and A7. Not speaking about adding cabriolets and station wagons in most segments. 2- and 4-door versions. In the meantime SUVs came up, starting with the Q7, later came the Q3 and Q5 to present small and medium-sized SUVs. It took a couple of decades, but now most customers find something to solve their problems (taking into account the size of your purse of course). And it all started with a single model. But Agile is not a solution here, because you don’t want to have half a car.


I want to thank the following people for making up my thoughts today, triggering the problem, challenging my statements, agreeing and disagreeing with me. I hope I didn’t forget someone.
Dan Ashby, Jose Diaz, Bent Myllerup, Thomas Ponnet, Aleksis Tulonen, Robert Meaney, Hannes Lindblom, Jokin Aspiazu, Michele Cross, Cassandra Leung, Tim Ottinger


9 thoughts on “MVP or not?! – A misunderstood pic goes viral”

  1. Really interesting post. When I saw your tweet earlier in the day I thought would a house be a better example of MVP? Good to see that someone has used it as an example already.

  2. This is a really great blog that clearly explains MVP with examples from every day life – great job! I really like how you gave three different contexts as well to show how it might differ in each case. Thanks for sharing! And including my pic =]

  3. A sorry tale about MVPs – I recall working at one client who was pretending to be agile. They wanted a web application to sell financial products. I tried to persuade the PM (they didn’t have product owners) that they could get value early by delivering the advertising and financial illustration (quote) part and a basic form to capture contact details for those who were interested. This would require lots of manual fulfillment work, but would be followed by further releases to start processing the data, and ultimately completing the application and making the sale. I never used the term MVP or anything like it – I just tried to explain that this way they’d start to get value in a few weeks, not several months.
    The PM explained that if they did this then a time would come when the Business would decide they didn’t want to spend any more money as they had what they needed. I said “exactly!”, hoping that he understood. But he continued… “And so we’d never get the project properly finished”.
    All he understood was he had a scope to deliver, and never mind whether it was the right thing.
    In the end it took two years.

  4. Hi Patrick,

    The core purpose of an MVP is to explore hypothesis formed by the business and has nothing to do with the technical implementation of the product itself.

    So let’s take the original example, let’s say you and I wish to start a new business providing a way for people to get from a to b. This assumes that there are no existing transport media other than walking.

    The business hypothesis is that people will be willing to spend enough money on our product that we can make a profit.

    The first step in the process is to clearly articulate the problem which would involve talking to potential customers. Their biggest problems may be 1. Walking is slow 2.walking is tiring.

    With that information in hand we try to create a ‘product’ as quickly and cheaply as possible to solve their problems. So we draw a small board with wheels attached and show it to our customers, they look at it and think yes that may allow me to move more quickly and more efficiently so we move to the next stage and build the skateboard and present it to our customers. Our customers immediately begin using the skateboard but find its very difficult to steer(we did not anticipate this issue) so we quickly attach a steering mechanism. The feedback is very positive, as the customers can move pretty quickly but it’s still tiring to use the skateboard.

    The product continues to evolve based on the feedback of our target customers (customer segment), their evolving understanding of their needs in terms of benefit, our understanding of our solution in terms of cost\profit until we hit a sweet spot where the product achieves product/market fit.

    The interesting question from a testing perspective is whether it’s our job to ensure we are building the right product and if we are building the product right.

    MVP aims to ensure we build the right product(business decision based on many facts not just technical), from a test perspective we typically try to ensure we build the product right.

    As a tester I often struggle with the question above as ultimately I want the product to deliver value to people that matter but in some circumstances we are solving the wrong problem.

    I’d appreciate people’s opinion on the above.

    Regarding MVP I suggest reading ‘lean startup’ by Eric ries, ‘running lean’ by ash maura. They are both excellent reads.


    1. Hi Rob,

      thanks for your addition to the discussion.
      I agree with you that the purpose of the MVP is to gather feedback early and provide a solution stepwise to keep waste of engineering wrong things or things wrong to a minimum.
      I like you approach to keep with the first products, because in that frame it makes sense, because the products are similar. In my opinion the “real live”, well non-software, example fails is when imaging that one company / product team needs to evolve from skateboard/scooter building to manufacturing cars.
      A better example might be lying in picture 3. A customer comes to a custom-bike manufacturer and says he wants a bike, but not sure what he needs in particular. So let’s show him a drawing of the simplest form of bike; one with a frame, two standard wheels, a saddle, a handlebar, single-gear. Then we gather feedback what he likes, what he doesn’t like, what needs to be improved. We come up with a first model to build, then exchanging the handlebar, adding multi-gear, splash guards, a carrier, exchanging wheels for thinner ones, etc. And after a few feedback loops we come up with a personalized form of a Randonneur, and the customer is happy. We didn’t need to build a city bike, a mountain bike, a race bike, a bike rickshaw, and what not. In this example we don’t have to leave the domain of building bikes.
      In software development the domain is not so restricted, because a company can evolve more naturally from a single app business to an enterprise supplier, when they sense the chance for it. In the general case it’s also “only” the person or group of people who deal with domain knowledge who need to evolve the most.
      In an agile context we are back to the approaches I described above. What kind of problem do we need to solve. Single customer, a few customers with similar problem, or many customers.

      I haven’t yet even looked at the testing aspect in an MVP approach. Thanks for bringing the discussion in that direction. I have to give that context another sit & think.

  5. Thanks for this insightful post on MVP. Also simple but very important tip – when explaining the concept of MVP, describe the context!

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: