Working Software is Not MVP

Two potential partners pitch you the first phase of your upgraded enterprise software platform, both with the same scope and requirements, but one quote is 25% more cost. Which partner do you choose? Same features, but one company can do it cheaper – the answer seems obvious, no?

Even if price is your primary deciding factor, I’ve still not given you enough information to decide. That’s because the cost of a Minimum Viable Product (MVP) has two parts – the visible costs that you pay in the initial engagement, and the invisible costs that you pay over the life of owning, extending and maintaining the platform. The visible costs you pay once; the invisible costs are a tax you pay forever.

MVP is about proving the approach, not the solution. Enterprise applications continue to be expanded upon for years after the initial project. Worthy goals of an enterprise MVP are:

• Consistent and repeatable patterns and practices
• Accessibility to new personnel, both business and technical
• Flexibility to modify the solution as needs change
• Extensibility to new sites, business units and use cases

The level to which these goals are accomplished (or failed to be) is what determines the invisible costs you pay for your MVP in the months and years to follow. What’s not on the list of MVP goals is “working solution” – that should be a given, the most basic requirement of any piece of software.

To understand how this concept impacts you, let’s look at two MVP software solutions represented by children’s building blocks. The project scope for this MVP was a built wall with a given number of blocks representing features.  Here are the two solutions:

Both software solutions accomplish the project scope and can be considered a “working solution.” And if our end goal was to have a block wall of exactly this size with exactly these blocks, then really both solutions are effectively equal. But if these solutions represent different versions of an enterprise MVP, measured against the goals above, the total cost of ownership (TCO) and resulting return on investment (ROI) of these solutions are worlds apart.

Solution A clearly follows planned, consistent patterns and practices, while Solution B pieces features together with no overarching rhyme or reason. This has a direct impact on team members’ productivity now and will impact accessibility to new personnel using and developing this solution in the future. When needs change, Solution A accommodates by straight-forward replacement of one set of features with another:

And when business units need the solution to accommodate additional use cases, Solution A incorporates those features into the overall solution with minimal rework:

What does it look like for solution B to accommodate changing needs and new use cases? It’s hard to say given this starting point, but what I can tell you is it’s going to be painful, costly and require a lot more work than it should. This is because step one looks like this:

If you ever find yourself asking, “Why does it take so long for our development team to add new features?” or “Why does every change to the system seem to break something else?”, you’re probably experiencing the tax of a solution that looks a lot like Solution B.

Choose your MVP partner wisely.