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.

 

The Biggest Challenge in Product Innovation May Surprise You

overloadAsk senior executives at manufacturing firms what their biggest challenge is managing new product innovation and you might hear answers such as lack of creative thinking, development teams need to work harder, or maybe that the organization does not have the right skill sets. The truth might surprise you: consistently year-in and year-out, the single biggest pain point in managing product innovation is too many projects for available development resources.  Continue reading