MVP, or Minimum Viable Product is a term that gets thrown around business like crazy. It’s especially ubiquitous in agile contexts. MVP is something that we constantly ask ourselves. What is the MVP? What can we put off until Day Two? What are the need-to-haves and what are the nice-to-haves? These are all great discussions to have. This is because these conversations allow us to get something in front of the customer. It lets us get their reactions and informs us whether or not we’re on the right track. If we are on the right track, it brings us a return on our investment faster. These are all great things.

However, sometimes, these conversations change. It’s usually when we’re well into software development. The features have been defined, designed, and mostly built. We discover a problem and start talking about whether or not to release anyway. Someone invariably asks whether or not fixing it is MVP. Or, at least, that’s how they phrase it. What they’re really asking is whether or not it’s an acceptable degree of shi… shoddiness.

At this point, the conversation has shifted from what features should be released to what level of quality is expected. The implication is that MVP goes beyond which features should be released and encompasses how well those features should work. By this definition of MVP, a component of MVP is the minimum level of quality that we will accept. The concept of a minimum level of quality implies that there is also a Maximum Acceptable Shoddiness, MAS, if you like.

If we follow this version of MVP to its logical conclusion, we’ll discover that all products should be released with Maximum Acceptable Shoddiness. We should cut all the corners that we think we can get away with for the sake of getting the product out the door. Not only should we let problems slip through the cracks, but we should be actively looking for ways to cut corners. After all, this lets us get our product out the door faster. We can test our assumptions and start getting that ROI even faster.

The problem with masking this discussion as an MVP discussion is that we’ve changed the nature of the conversation. MVP decisions are often hard to make and equally hard discussions to have. But they’re always the right conversations to have. You should always feel comfortable having those conversations. Conversations about sacrificing quality, on the other hand, should always feel uncomfortable. Sacrificing quality is, by definition, a problem. It might be a solution to a bigger problem, but it’s still a problem in itself. By disguising these discussions as MVP discussions, we’ve removed, or at least lessened, the discomfort of the discussion. That’s a bad thing.

Sometimes we feel pressure to get something out. We’ve been struggling to meet our velocity, we’re up against a deadline, the higher-ups are getting restless, whatever. We’re looking to get something in front of customers and sacrificing quality feels like the right thing to do. Maybe sacrificing quality really is the right thing to do. Maybe this really is a discussion that needs to be had.

When we need to have discussions about sacrificing quality, let’s have them. But let’s not disguise them as a good thing. Let’s address them as they are: a discussion about making the best of the bad situation. This brings the underlying failures front and center, so that we will, hopefully, address them and do better next time. After all, that’s part of what agility is all about.