Does it make sense to develop an MVP iteratively?

Are the concepts of the MVP (Minimal Viable Product) and iterative development related? Do they try to solve the same problem in a different way or are they complementary and can be used together?

The MVP in a nutshell

An MVP is a concept popularized by the Lean Startup movement. The idea behind it is to validate as quickly and as cheaply as possible the market potential of a product vision, by releasing the simplest possible version of the product to real customers.

This idea is based around three observations:

  • No amount of theoretizing or market research can validate a product vision. Only the real customers’ willingness to pay for it can.
  • We don’t want to pay the price of a complete, full featured and fully polished product to validate its vision. We want to validate it through a cheap, Minimal proof of concept.
  • Customers won’t pay for a crippled, unusable or poor quality product, no matter if its vision is compelling or not. Therefore, the initial proof of concept, while minimal, must be also Viable.

Iterative development in a nutshell

Iterative development is a concept most Agile methods are organized around. The idea is to build the product in a series of short, timeboxed, constant length “sprints”, in such a way that at the end of each sprint we get a small increment of a final product. We may release it immediately or wait untill enough of such tiny increments accumulate.

To make this approach work, a couple of conditions must be met:

  • The product must be built as a series of “vertical slices”. Increments may be very small, but each increment must be a fully functional feature, usable for an end user.
  • Each increment must be potentially shippable. We don’t have to release it immediately, but it must have enough quality and technical polish to be immediately releasable if we decide to do so.
  • Each increment must add value for a customer. Work should be organized in such a way, that the increments adding the most most value are built first.

Do the concepts of the MVP and iterative development clash?

It may seem that the concepts of the MVP and iterative development overlap. An MVP is a small, fully functional slice of a product, valuable for a customer – just like the increment at the end of a sprint. There is only one fundamental difference:

  • An MVP is not timeboxed like sprints. It is considered done when it’s viable, not when a predefined time span ends, and there’s no reason to postpone its release when it’s done.
  • An increment built during a sprint must be potentially shippable, but it may not yet be viable like an MVP. We may have to wait until increments from a couple of subsequent sprints accumulate until we feel comfortable to release the product to customers.

Is there any point in doing iterative development, then? An MVP is already the smallest possible increment of a product that is viable to end users. Is there any value in dividing this increment into even smaller, non viable increments?

Yes, there is.

Iterative development helps us ensure that the MVP is viable

It’s much easier to guess what feature set is required so the minimal product is viable, than to guess how to build the final product so it’s a market success, but nonetheless it’s a guess. We can envision what would be viable, but we can’t evaluate it until we have the working product in our hands.

The same is true for quality and usability aspects. Not only the lack of features can make the product non viable, but a poor usability can discourage customers as well. And again, theoretizing about usability will never give us as good answers as running usability tests on a working product.

Building the product in tiny but working increments and constantly evaluating these increments allows us to make better decisions about what’s needed to make the product viable and to achieve this viability cheaper, by straying less on the way.

Iterative development helps us ensure that the MVP is really minimal

Because we don’t know precisely what feature set will make the product viable, we can’t also build the truly minimal product. We’re walking a thin line between the minimal and unusable product, so when relying only on our guesses, we tend to err on the side of “padding” the product with additional features to feel secure.

On the other hand, with an iterative approach, paired with building the most valuable features first, we start with an increment of the product that is definitely smaller than an MVP. We then gradually grow it bigger, extensively testing and evaluating the product each sprint. This allows us to see ourselves, on a working product, if it has already became viable, so we don’t have to guess and we don’t need any padding to feel safe. In effect, we can release a truly minimal product, immediately after it has reached viability.

Iterative development helps us stay flexible when building an MVP

All the customer feedback and all the opportunities to pivot happen, of course, after an MVP is released. However, the process of turning our idea into a tangible product, already provides many opportunities for learning and small course corrections, even if it all happens only internally.

Iteratively building potentially shippable product increments enables us to stay open for such opportunities. The flexibility it provides is unlikely to result in a big pivot in the middle of the MVP development, but it is quite likely to result in a lot of small tweaks that will make the MVP better and our initial product vision more refined.

Summarizing: treat potentially shippable increment at the end of each sprint as an internal MVP

We have asked in this post if it makes any sense to split an MVP into several smaller iterations if the MVP is already minimal. My take on it is that an MVP is a minimal product that can give us customer feedback. However, we can split it into even smaller parts to get lower-level feedback during development. Think of it as an internal MVP, a minimal product that can give us feedback from stakeholders or from usability tests. Of course, such an internal MVP won’t allow us to validate a product vision, like a “real” MVP does, but it still provides a lot of benefits, so we shouldn’t neglect such an opportunity in our process.

What’s your experience? Do you use iterative development when building an MVP? What benefits or drawbacks of such an approach have you noticed? Please share below in the comments!


What do you think?

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

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

Google photo

You are commenting using your Google 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