Top 10 Reasons Why Product Development Projects Fail

Introduction

The sole purpose of product development is to generate a positive return on investment. Consequently, it is interesting to note that more than 70% of product development projects fail to produce a positive return on investment. Product Development is risky and always requires some trial and error. However, great companies continuously improve, and product development is certainly an area where opportunities for improvement abound. It is important to treat product development failures the same as other challenges in business. It is essential to understand what went wrong, why it went wrong, and what can be done to prevent it from going wrong next time.

Finish Line has often been engaged to assist clients with projects that had failed or were failing. As a result, we encountered the same mistakes repeated over-and-over again. The following is our top ten list of why product development fails:

Reason 1: Requirements

In most cases of failed product development, the Requirements Document was insufficient, subjective, or did not even exist. The best execution in the world is worthless if it produces the wrong product. The first step in product development should be generating a Requirements Document. A good requirements Document will objectively define all the characteristics necessary for the product to succeed in the market. Also, it will:

• Establish common goals and expectations for the product
• Get everyone (engineering, marketing, sales, manufacturing) on the same page
• Create a discussion between engineering and marketing about what trade-offs should be made
• Provide the basis for generating Conceptual Designs and determining which one is the best
• Provide evidence to kill projects that should not proceed beyond the initial investigative phase
• Create an environment where innovation can flourish

Reason 2: Innovation

Successful new products require novel and innovative ideas. Having an “idea pool” that is too small to stimulate innovation and make effective decisions cripples product development right from the start. We are amazed at how often we see product development conducted by only one or two people. No design reviews, no engineers from other disciplines or industries, no peer reviews, no devil’s advocates, etc. Great designs come from teams with large “idea pools.” Diverse teams deliver better products. Design reviews should be attended by as many people as possible, and the more diverse the audience, the better. Leadership should have a goal to provide teams with as large an “idea pool” as possible. All ideas and viewpoints should be welcome and encouraged. A wild and crazy idea may not be viable in-and-of-itself. However, it may stimulate someone else to produce the perfect idea or concept.

Reason 3: Design Focus

Every product is composed of smaller systems. Typically, many of these systems have already been designed by someone else. They are proven and available at a lower cost than “in-house” development from scratch. The primary design effort should be focused on the product’s core technology that must be developed in-house. The core technology defines the competitive nature of the product and creates barriers to market entry by competitors. The non-core technologies should be leveraged from prior products or outsourced to partners that have already done the design or something very similar. This reduces the cost of development, decreases the time to market, and increases the reliability of the product. To make this happen, you must know and communicate what technologies are core and which are not. You must also have a culture that embraces leveraging existing designs and eschews the NIH (Not Invented Here) syndrome.

Reason 4: Goals

Frequently, we have encountered development projects where the primary development goal was producing the first prototype. This is problematic for many reasons. Typically, it takes at least as long to go from prototype to production as it did from concept to prototype. Why would anyone set the primary goal as the mid-point of the race? Making a prototype that has not been documented, cannot be manufactured, and, at best, meets some unknown requirements that will not lead to a positive ROI. As far as product development goes, marketing’s job is to decide “what to do,” engineering’s job is to decide “how to do it” and manufacturing’s job is to “do it” consistently and efficiently. Focusing the engineering group on building a prototype might prove that they have the technical skills to do part of their job. However, generating a prototype is not a complete engineering job. It will not result in a manufacturable and profitable product that will yield a positive cash flow.

The goal of engineering should be to produce documentation that will produce a product that meets the requirements. They know the documentation will produce a product that satisfies the requirements because manufacturing built the product from their documentation and someone performed a Design Verification test to verify that the product met the requirements. This is an entirely different focus from just building a prototype. The output of engineering is a comprehensive set of documents that can be followed by a manufacturer to produce a product that meets a defined set of requirements.

Reason 5: Team Composition

No matter how well-staffed a team is, they will develop “groupthink,” and that can have a big impact on decision-making. Ironically, the better a team works together, the more likely it is that “group think” will play a role in ineffective decision-making. Always involve resources outside the team on the Design Verification task and at critical design reviews. Constantly challenge decision-making by injecting outsiders, who will not have the same bias as the team members.

Reason 6: Documentation

“Tribal knowledge” is knowledge about a product or process that is not documented. It exists only in the heads of a few individuals. Management must make it clear that nothing less than complete, accurate, and tangible documentation is required for every aspect of the product design and manufacture. Spending millions of dollars to develop ideas and not documenting all the details is just not smart – yet we see it happen every day. The product deliverable from engineering is not the great new product itself. The work product from engineering is the documentation that permits manufacturing to produce that product consistently and efficiently.

Reason 7: Local Optimization

The goal of product development is to produce a positive return on investment. Focusing on “Local Optimizations” as a means of developing that product distracts from that objective. Measuring and monitoring how many man hours are spent per drawing, how many lines of code per unit measure are generated, how precisely the budget is met month to month, how many patents were filed and ensuring that outsourcing always goes to the “lowest bidder” are all local optimizations. Independently, they appear to be beneficial. Collectively, they can be very counterproductive. The primary focus should be on ROI, how many dollars were invested to yield the margin contribution received? Decisions should be made with this focus in mind: “will it increase our ROI?”

Reason 8: Artificial Budgeting

The cost of product development projects is typically more than 90% “knowledge worker” cost. Project managers should be held responsible for the total cost of the project. Too often, we see project managers who assume internal resources are free. This misconception leads to some irrational decision-making that usually involves making sure that “people are busy.” This “keeping people busy” idea has its own set of unintended consequences. Ultimately you want to spend X on product development and end up with X plus a whole lot more, and thus X needs to be as small as possible. The product development budget should include the hourly cost of peoples’ time at a competitive rate. Project managers should be allowed to control how many hours any person works on their project, and should be rewarded for keeping these hours low. Too often, we see exactly the opposite; that is, the project manager being rewarded for having a lot of people spending a lot of time on the project.

Reason 9: Problem Identification

The solution to most product development problems is usually process and communication-related. If a product development project is not living up to expectations, then it is likely that the wrong processes are being used, there is poor communication, or the expectations are inappropriate. Problems in product development are often described as technical problems, but root-cause analysis usually concludes that the real problem is underdeveloped processes, poor communication and/or misalignment of goals and expectations.

Reason 10: Failure to Adapt

Doing the same thing over-and-over-and-over again and expecting a different result is a chronic problem. We see this manifested in all forms of excuses for failed or failing product development projects:

• We just need some “good / better” engineers.
• We just couldn’t get that new widget to work right.
• Luck was not on our side.
• The market moved away from us.
• Management will not let us set realistic schedules and budgets.

I am sure you have heard these and many other excuses as well. However, complaining is not going to make a difference. If you want to change the result, then you need to change something upstream in the process and try something different. Like every other part of a business, product development is improved with leadership and operations. True, it is inherently more risky than most other business activities, but that does not relegate it to the world of the unmanageable. Focusing on processes will reduce risk, cost, and create better products. Changing from the old tried-and-true is the only way to escape the same old failures.

Finish Line has completed more than 1,000 projects for 200+ companies, creating market-dominating products by combining clients’ ideas and market reach with our talents, team, and processes. We can do the same for you.

About the author: Steve Owens, Founder and CTO of Finish Line Product Development Services, has over 30 years of successful product development experience in many different industries and is a sought-after adviser and speaker on the subject. Steve has founded four successful start-ups and holds over twenty-five patents. Steve has worked for companies such as Halliburton and Baker Hughes. He has experience in the Internet of Things, M2M, Oil and Gas, and Industrial Controls. Steve’s insight into the product development process has generated millions of dollars in revenue for start-ups and small businesses.