Minimum Viable Products Don't Replace Product Requirements – They Help Identify Them

“Minimum viable product” (MVP) is the term du jour among entrepreneurs and increasingly among product managers. In our product management advisory service at SiriusDecisions, we hear the term used frequently by b-to-b product managers to refer to products that have the absolute minimum feature set required to launch – products that are devoid of unnecessary and non-value-adding features.

Unfortunately, those aren’t really “minimum viable products.” Those are just products.

Let’s start with defining MVP. There are many different definitions out there, but generally it refers to any offering or capability that requires the least effort to build while giving the organization the greatest ability to learn about customers. “Least effort to build” and “most ability to learn” are the key phrases in this definition that are often misunderstood or ignored.

As an example, imagine you are the product manager for a software application that collects data on customer activity and produced different types of reports. You’ve heard anecdotally that some of your clients want to export these reports into various formats, but you’re trying to evaluate whether it’s worth the considerable development effort required to create exports in many different formats for many different reports. A true MVP approach might be to show different exporting options in the interface for various reports, but instead of actually building the automated reporting, you have someone manually create the reports when they are requested and send them to clients. Development only needs to add buttons in an interface, and not a full backend, so it’s “least effort to build.” Then, based on how often certain types of reports are created, you determine whether or not to build that automated functionality into the product directly.

Often when product managers discuss MVPs, they are not referring to a scenario like the above, where hypothesis testing – and the potential outcome is to not actually add anything or to remove a feature – is involved. They really mean “a product that has the minimum essential functionality to meet market needs."

This is an admirable goal. Product managers often don’t understand customer needs well enough to be able to determine what is really “required” for the product to be successful. As a result, products get laden with unnecessary features and functionality, which causes time-to-market and costs to increase. So, the desire to focus on the minimum essential functionality makes sense.

However, "the minimum essential functionality to meet market needs” does not describe an MVP – it describes product requirements.

I know what you’re thinking: “Product requirement documents (PRDs)? You’re talking about those big long documents we used to write back when we used to spend more time updating the document than actually building the product, and at the end of the day, no one read the document, anyway?"

Well, unfortunately, that’s how many companies implemented product requirements documents, but at SiriusDecisions, we define the product requirements deliverable as explaining in non-technical terms what the offering must provide or do in order to meet market needs. (And note that I’m referring to this as a product requirements deliverable rather than as a product requirements document, because we don’t recommend actually creating them as documents.)

Regardless of what process you follow – agile, waterfall, lean iterative kanban scrummerfall – wouldn’t you agree that it’s necessary for a product manager to articulate what the product needs to provide or do to meet the needs of buyers and users?

Unfortunately, “requirements” (and “PRD”) has become a loaded word in many companies because of the association with heavy documentation and unwieldy and front-loaded development processes. However, we see many organizations overreacting and overcorrecting. They throw out the concept of requirements (and other essential components like roadmaps and business cases) altogether, declaring “we’re lean” and thinking they can MVP their way into a product strategy.

I’m fairly confident that part of the reason that this incorrect understanding of MVP has taken hold is that product managers, developers and executives are sick of products with bloated feature sets, frustrated with development projects where the team is so caught up in what would be “nice to have” that they keep adding features and never get around to launching, and fed up with products where customers can’t find the really valuable capabilities because they are buried amongst all of the non-value-adding functionality. 

One reason that MVP appeals to people – even if they interpret it incorrectly – is that they see it as a way for product managers to boil the product down to its fundamental essence and have the right things in the product that will meet buyer and user needs — no more, no less. An MVP approach is one good way to determine what the product must provide or do in order to meet market needs. But product managers then need to then capture those learnings and that information in the product requirements deliverable, which will be used to support the development process as well as related areas such as training and support.

Clients of our product management advisory service have access to several research pieces on this topic, including the Core Strategy Report “Developing Product Requirements,” which provides a template, examples and guidelines that product managers can use to develop product requirements.

Interested in learning more about how product requirements fit in to the overall innovation and go-to-market process? Learn about how The SiriusDecisions Product Marketing and Management (PMM) Model™ can help you achieve Intelligent Growth™ Through an Improved Product Management Framework.