Is Fully Defining a New Product at Odds with a “Minimum Viable Product”?

A recent article focused on the number one problem in new product development: too many projects for the available development resources (1). In that article, one of the prescriptions proposed was to resist the temptation for the scope of a project to expand. Scope creep not only impacts that specific project but the entire project portfolio because of resource dependencies.

It was proposed that to avoid scope creep, it is best to fully define new products before development starts. That means a fully agreed-upon written description. The requirements for defining new products should be enshrined in your phased development process.

But is that advice at variance with the lean concept of a “minimum viable product”, or MVP? This is a popular “best practice” for creating new products, services and business models (2). The idea is to create a prototype quickly and get customer feedback. The new product, service or business model then “emerges” during that process.

To address that question, you must step back and first understand project uncertainty (3). There are four key sources of uncertainty in any project, whether for a product, service or new business model. These include task variation, foreseeable uncertainty, unforeseeable uncertainty (also known as “unknown unknowns”) and complexity.

When you are faced with a development (or even a new business model) that is dominated by “unk-unks”, then the best way to “define” that product is by using iterate-and-learn, based on the “plan-do-check-act” learning cycle. This is the fundamental basis of all the lean methodologies.

You accept the fact that you really don’t quite know how to define the product or service or business model, and so you want to prototype and test; to “fail fast and fail cheap”. This is really the purpose of an “MVP”. It’s the basis of the “lean startup” mentality. It is also embedded in the scrum technique for software development, for the same reason.

So my comment about “fully defining” a product to avoid scope creep can be refined somewhat based on the above comments. In other words, if you really do not understand what the customer wants then “fully defining” (e.g. writing a detailed description) the product (or service or business model) and moving to development is a waste of time and resources. You really need to learn exactly what needs to be developed before you even get to the point where you can fully define it, let alone expend scarce resources in development.

But make no mistake, once you get to that point, fully defining a new product and making sure all the stakeholders in the organization agree on a written description is absolutely necessary to prevent endless scope creep that delays the development and impacts the entire project portfolio.

If you do not face significant “unk unks” or complexity in a development, then the previous discussion might not apply. For instance, if you are incrementally improving an existing product, the concept of an “MVP” is really not applicable. In that case, you can “fully define” the product from the beginning, reducing the risk of scope creep.

Bottom line? How you will get to the documented, written product definition is context specific. New products, services or business models are on a continuum from incremental all the way to radical, new-to-the-world developments. You have to choose the right tools that are applicable for that specific project.

Getting caught up in the desire to create a “MVP” for every development does not make sense. The reality is that for most companies, 80% of their projects are incremental, where the use of an “MVP” is not necessarily needed. There is nothing wrong with incremental projects. It pays the bills.

Notes:

  1. See this article: “The Biggest Problem in Product Innovation May Surprise You”
  2. See for example: Eric Ries, The Lean Startup. (New York, NY: Crown Publishing, 2011)
  3. See these articles: “How Risk Impacts New Product Development” and “Tools to Manage Risk in New Product Development”

About the Author

Jeff Groh is President of New Product Visions located in Flat Rock, NC. New Product Visions helps companies drive revenue and earnings growth by improving their innovation management practices. We focus on processes, organization, management engagement and culture. Services include consulting, Innovation Coach™ Workshops, Your Innovation Coach online consulting service and software enablers. Mr. Groh spent 30+ years in industry in a variety of management roles in sales, manufacturing and new product development prior to starting New Product Visions. For additional information or to join our mailing list, contact us. Available for select speaking engagements.

 

2 thoughts on “Is Fully Defining a New Product at Odds with a “Minimum Viable Product”?

  1. Great article, Jeff. I would only add two thoughts:
    1. It is a certainty that as you go through the MVP development process, you will find out that some of your (and your customer’s) assumptions were wrong. And there are implications to the things you didn’t know you didn’t know – we learned in my last company that scale and security interacted in our architecture to make the product all but impossible for consultants to use, and they were a target user.
    2. In addition to fully documenting the product, it is critical to prioritize and get buy-in on that priority from all stakeholders and STICK TO THE PLAN.

  2. Good perspective, Jeff. The biggest problem I see with MVPs is that they’re too feature based. When MVPs are user-scenario based (what & why), it gives product teams a lot more wiggle room to figure out feature sets that help users accomplish their job tasks (how).

Leave a Reply

Your email address will not be published. Required fields are marked *