Toward A Minimum Sustainable Product

Development Strategy

The concept of a Minimum Viable Product (MVP) is hardly new, and an excellent way to prioritize the truly essential features of your applications. The concept of the Minimum Lovable Product (MLP) has also emerged more recently, which is the minimal product that effects the greatest end user affinity. However, beyond these two goal posts, it can be difficult to maintain the sense of rigor that ensures each iteration of the product addresses a key necessity.

This is where I would like to introduce the concept of a Minimum Sustainable Product (MSP), which represents a further step beyond the MVP and MPL that satisfies the condition of being capable of sustaining the business purpose of the application at scale.

Minimum Viable Product (MVP)

First, let’s briefly touch on the nature of the MVP: to define a product that satisfies the basic features of your business case, but is never intended to be the final state. The benefits of this approach are to ensure that you can get your application in front of your consumers in the least time possible while still gaining an initial return on investment (ROI), meeting regulatory deadlines, and so on. Out of the available features for functions that may be included in your application, the MVP represents the smallest subset that derives meaningful features to the end users.

Minimum Lovable Product (MLP)

Arguing that what came out of MVP implementations was insufficient with respect to the user experience, the concept of the MLP was born: the minimum product that would broker the greatest amount of end-user (early adopter) affinity. This is a different approach to feature selection than MVP, rather than an extension to it, though some degree of overlap would be expected since users would still want the functionality of the MVP! I would assert that MLP must include most or all of the MVP in order to satisfy the end users, since a proper MVP would have the minimum viable set of functionality do deliver value to that same user. I readily admit that is an over-simplification, but it’s not too far off.

Neither MVP nor MLP present themselves as the finished product, so how do you maintain the sense of rigor that kept your initial release(s) focused?

Minimum Sellable/Scalable Product (MSP)

Your MVP/MLP is now out in the world, and your customers are loving it, right?

Actually, they’re probably not. In fact, they might even hate it, but they are using it because it is providing value under the promise that future functionality and usability updates will alleviate their initial concerns. Some of these concerns are additional features that will derive benefit to them, and ultimately to your business.

What got you to the point of an MVP/MLP release was maintaining a hard line on those things that you did not need on day one versus those you did. Now that it is day one, how do you keep that rigor and not just chase your customers’ immediate wants, or worse yet what your business users think your customers’ immediate wants are?

While the impetus of the MVP/MLP was to get the bare minimum of functionality out into the world, the question that should be asked of an MSP is, “If we were to be told at some point that there would be no further development, what would have to be in place in order to cover the scope of functionality at scale?” This simple question has two parts, and each must be satisfied: covering the scope of functionality, some which may have been left out of the MVP, and functioning at scale, which is handling the anticipated user base without significant internal or external bottlenecks.

For example, an MVP may be acceptable with a number of manual steps that provide for the feature, but an MSP would require some or all of those steps to be eliminated as they would become prohibitively expensive at scale. This is again a question of ROI, as it should be, but the end result is an application that not only supports scale (as an extension of MVP) but promotes scale (as an extension of MLP). Amusingly, technologists will argue in favor of the MVP aspects while business users will skew more toward advancing the MLP agenda! A sound balance should be struck between incenting adoption and supporting it.

Each stage builds on the prior in product development

Each stage builds on the prior in product development

Beyond the MSP

The MSP concept is still just a stage in the development of your product, but it is an important one: it is the one that ensures that your application remains viable in the long term even if no further development occurs. It also provides a benchmark against which user stories and requirements can be judged for inclusion beyond the more restrictive constraints of the MVP/MLP. After MSP is complete, you are truly at a point where you add the true
bells and whistles” that create affinity above and beyond.

Colin Campbell is CEO and Principal Consultant at Stratosphere Technical Consulting, which specializes on the program-level evolution of best practices on the Pega platform.

To find out how Stratosphere can help your organization with the design, development, and evolution of your Pega practice, contact us via the form below and we will get back to you in one day or less