The Biggest Challenge in Product Innovation May Surprise You

Ask 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. 

Survey data backs this up (1). In a recent survey, 61% say that too many projects for the available resources was the number one “pain point” in managing a project portfolio. That response has remained consistent for several years. A related statistic indicated that only about 25% of those surveyed felt their organization was effective at resource allocation planning. The difficulty stems from the fact that every project is different, projects tend to be susceptible to scope creep, and development often takes longer than anticipated.

And what about the risk to the organization as a result of overloading resources? In the same survey cited above, the top five risks include late projects, inability to innovate fast enough, increased project costs, missed business opportunities and dissatisfied customers. The top two risks on this list speak to the challenge of reducing time-to-market. In today’s hyper-competitive global economy, getting to market faster is an imperative.

Let’s look at five key ways to address this vexing innovation management problem.

Implement a Resource Allocation Process

Do you know how your development resources are being utilized now and into the future? In my experience, companies either operate blindly because they have absolutely no process in place or they implement very heavy-handed processes with too much granularity. I lean toward the use of simple processes and tools if no process is currently implemented (2). There are specialized software tools available, but make sure they are user-friendly or they will not be worth the cost to implement.

The Danger of Loading at 100% of Capacity

The focus in most organizations is “efficiency”. That translates to senior management insisting that development resources be utilized fully. Slack in the system is be avoided if you value your career. There is just one problem with this mentality. In most organizations, there are development resource dependencies. What happens on one project affects other projects. Figure 1 illustrates the point, though the exact shape of this curve will vary by company. The new product development process is a complex system, and as you approach 100% loading, in my experience you have a 100% chance that many or all projects will be delayed (3).

Figure 1

Choosing the Right Projects

Since development resources are valuable but scarce, the ability to pick the right projects becomes even more important for long-term innovation success. This so-called “fuzzy front end” is a challenge for even the most successful serial innovators. An effective project portfolio management process will help you select the right projects in the first place (4).

Multi-tasking is Not Your Friend

The mantra in every organization is “doing more with less”. In new product development, that often means key development resources work on many projects simultaneously. This is especially true where there might be a single resource with a specialized skill set who invariably ends up on the critical path of every project. Asking your key development resources to work on more than about two projects simultaneously not only reduces their effectiveness, as shown in Figure 2, but increases project dependencies.


 Avoid Scope Creep

A final key issue is to resist the temptation for the scope of projects to expand. Scope creep will likely delay that specific project, and impact all projects due to resource dependencies. The first way to combat scope creep is to fully define new products before development starts (5).  You are better served spending more time up front fully defining a new product, rather than jumping headlong into development. Second, senior management must provide organization discipline to insure stable definition over time.

In summary, while many factors lead to long-term innovation success, the number one problem in managing new product development is too many projects given the available resources. The risk to the organization is multi-faceted but in particular, new products will be late to market dramatically impacting business performance, increasing time-to-market and reducing competitiveness.

Managing innovation requires a robust resource allocation planning process. If no process is in place, simple tools can be used. As with other processes, the planning and dialog involved is more important than the elegance and complexity of the tool used. Second, realize that there is a penalty to pay if you attempt to load the development resource pool at 100%. Next, choosing the right projects to begin with is essential. And finally, resisting the temptation of having critical resources multi-task across many projects and avoiding scope creep support long-term success.


  1. See these surveys from Planview: Fourth Product Portfolio Management Benchmark Study, Capacity Planning Fuels Innovation Speed.
  2. For assistance in evaluating your innovation management practices consider Your Innovation Coach online coaching service.
  3. For an interesting example of this same issue but related to another type of complex system, see: Fairly, Peter. 2016. Averting the Blackout of the Century. March 2016: 44-51.
  4. See for example these articles: The Importance of a Balanced Project Portfolio, Critical Aspects of Project Portfolio Management in NPD Success
  5. See for example these articles: The Role of Product Definition in Innovation Success – Part 1 and Part 2

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, and MyInnovationCoach online training. 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.

Specialties: NPD consultants, new product development consulting, developing new products, new product development seminars, small business consulting, new product development expert, product development process, new product development strategies, integrating NPD for mergers & acquisitions, organizing for innovation, management role in NPD, project risk analysis, innovation management


3 thoughts on “The Biggest Challenge in Product Innovation May Surprise You

  1. Jeff, I am interested to know your views about the types of projects for which the Agile method of development might apply. See for instance the book about Scrum by Jeff Sutherland. Your advice to “fully define new products” before you start work may be (?) at variance with his advice to define a “Minimum Viable Product”, get it in front of customers as fast as possible, and then evolve it based on their feedback. What is your take on that?

    • Richard that is a great question. I think one of the problems, is that the term “agile” has a variety of meanings. Sometimes it is also referred to as “lean”. In software development there is the “scrum” technique. There is a common thread. All of the definitions or applications rely on the tried-and-true “Plan-Do-Check-Act” learning cycle. It’s the basis of the concept of “iterate-and-learn”. It is a fundamental tool that every project manager should be familiar with.

      If you look at project uncertainty, there are four (4) key sources of uncertainty in projects: 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-an-learn, or the other method of learning through parallel trials. In both cases, you accept that 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, and “fail fast and fail cheap”. This is really what you are talking about when you reference a “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) is probably a waste of time. You really need to learn exactly what needs to be developed before you even get to the point where you can define it. But, once you get to that point, fully defining it 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.

      Now, if actually 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, and again, that will help prevent scope creep. In addition, your project is probably dominated by task variation and foreseeable uncertainty, so tools like Gantt charts, critical chain, and risk lists are typically used.

      Bottom line, is that it is very context specific. New products, services or business models are on a continuum from incremental all the way to radical, new-to-the-world projects. 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 going to be incremental. There is nothing wrong with that. It pays the bills.

      Another tangential topic is “lean project management”. That is another application of the “lean” or “agile” mentality. That is a tool that takes some elements of agile techniques and applies them to an overall project management tool. The tool I like (as described by Mascitelli in “Mastering Lean Product Development”) utilizes stand-up meetings (a feature of Scrum and Lean Manufacturing) in combination with a visual-project board. What I especially like about this tool is that is allows the project manager to break workflow into smaller chunks, and because it relies on short daily stand-up meetings, speeds the feedback loops in the project. It focuses on task management, and then the typical weekly or monthly core team meetings can focus strictly on strategic issues.

      If your project is only subject to task variation (rarely the case), then a simple Gantt chart (developed using the critical chain technique), is probably all you need. So I think the “lean project management” tool described above is really powerful. That does not mean that Gantt charts will not be used, it is just that they will be incorporated as necessary to pieces of the project, and not the primary tool used to manage the project.

      Just to plug my new service, Your Innovation Coach (, the last two month’s webinars were focused on this exact topic.

  2. Pingback: Is Fully Defining a New Product at Odds with a “Minimum Viable Product”? | New Product Visions

Leave a Reply

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