MVP, or Minimum Viable Product. For the longest time, I thought this was one of the few things the folks in tech could agree on. However, like everything else, there are various interpretations.

Shared Interpretation

I believe we can all agree on this part

MVP is a piece of software delivered to the user in a non-finished state as quickly as possible. A lot of the time, it's built based on assumptions about what the user wants and/or needs. Given the label MVP, it's almost guaranteed that all stakeholders are aligned that the software will have future iterations.

Where's the mixup then?

The two interpretations that I've stumbled across both build on the shared interpretation above - the key is in what future iterations and non-finished state mean in the two interpretations.

Modular MVP

non-finished state means that we are delivering the smallest possible value to the user. What we deliver isn't what we originally wanted to deliver, but it is what we've agreed provides the highest value vs every other tradeoff.
future iterations means building up to what we originally wanted to deliver in small iterations, each iteration provides some value to the user, and user feedback can be incorporated into each iteration.

Monolith MVP (a bulk slice of the feature end to end—not "monolith" as in system architecture)

non-finished state means we are delivering a bulk of the feature as quickly as possible. Some parts are missing, some parts are not scalable, some parts are buggy. It may take a bit longer, but at least the user can see what we mean.
future iterations means implementing the parts that we skipped, making it scalable, and making it more robust.

An Example

Let's make a comparison to building a garage. Each step is a point where user feedback can be incorporated.

Modular MVP

lay the floor
build the walls
build the roof

Monolith MVP

lay some of the floor, add two walls, add part of the roof
finish the floor, add a third wall, add more of the roof
add the fourth and final wall, finish the roof

Both approaches have pros and cons here.

Feedback	Modular MVP	Monolith MVP
want the garage to be bigger	this can be realized immediately since we've laid the floor. It can be easily modified since there is not anything on the floor yet.	This may not be realized until one of the structures are finished (walls, roof, floor). This doesn't occur until much later in the process, and once it does, everything will need to be redone to incorporate the feedback.
want a metal roof rather than traditional roof	If feedback arrives after the roof is built, we've already finished it - redoing it costs time and money.	If feedback arrives while the partial roof from step one is still in progress, we learn before committing fully—less sunk cost than finishing the wrong roof in the modular path.

What method do I prefer?

I prefer the Modular MVP. Before knowing about the two interpretations, I thought this is what we all meant when we said MVP.

Why do I prefer Modular MVP?

Maybe it's just my Software Engineer brain, but I like to try to think of things in small modules. The deeper you can dive into one well defined thing leads to better decisions and better quality. You can also get feedback faster, which means you can make sure you're building the right thing or kill it quicker.

I've also found some shortcomings with the Monolith MVP approach. All of those things we skimped on to make it an MVP don't get the dedicated time or attention to resolve them until they become a problem. Usually you end up with future iterations meaning about the same thing as the Modular MVP, however you have a less stable foundation to work from, so you're constantly switching context between old bugs and new features. Plus, nobody wants to build unreliable stuff.

Something to consider...