The purpose of product development is to generate a positive return on investment Research shows more than 70% of product development projects fail to produce a positive return on investment.
Product Development is risky and will always require some trial and error. However, great companies continuously improve, and product development is certainly an area where opportunities for improvement abound. In order to improve, we need to understand what went wrong, why it went wrong, and what can be done to prevent it from going wrong next time.
Our research has found that there are five root causes for product development failure that account for more than 90% of all failures:
Reason 1: Low Quality or No Requirements
Doing the wrong thing really well will not result in success. In product development, a Requirements Document is used to ensure that we do the right thing. Too often it is assumed that the “right thing” is known by all team members, or worse, requirements are written in a way that leave very little latitude or room for creativity.
Requirements generation is an opportunity for the team to be truly collaborative. It’s the one place where non-technical members don’t get lost in technical jargon. This collaboration often brings in new insight and leads to products that more closely meet the needs of the client, and thus, the market. Skipping or rushing through the requirements phase robs the team of this opportunity.
These requirements discussions need to be led run by a leader with good facilitation skills and one familiar with requirements generation. This effort will result in:
- Establishment of common goals and expectations for the product
- The team (engineering, marketing, sales, manufacturing) understanding the common goal
- Creating discussions between engineering and marketing about what trade-offs should be made
- Providing the basis for generating Conceptual Designs and determining which design will best meet the requirements
- Providing evidence to kill projects that should not proceed beyond the initial investigative phase
- Creating an environment where innovation can flourish
Don’t skip or underfund the requirements phase. A good requirements document should have all of these traits:
- Each requirement is quantifiable. Instead of “long battery life” write “Battery Life > 10 years.”
- Includes a development budget/timeline and unit cost that engineering believes is achievable—not just wishful thinking.
- Will sell in the marketplace, “Market Validation.”
- Includes statements about how the requirements will be validated during the Design Verification stage of product development.
- Each requirement is to the point and enumerated.
- Avoids describing “how” something is done. A good test is to ask, “Will customers not buy it if we use a different method to meet this requirement?”
Reason 2: Artificial Budgeting
The cost of product development projects is typically more than 90% “knowledge worker” cost. Too often project managers assume that internal resources are free. It is not uncommon for these managers to believe that the money spent “outside” the company to be THE budget they are held accountable for, and not the engineering payroll and overhead. As any behavioral economist will tell you, anything that is “free” will be used inefficiently.
A recent study
(https://www.slideshare.net/FinishLinePDS/why-does-product-development-cost-so-much?qid=429f6e84-6d7a-4de4-a5e8-859b02779c99&v=&b=&from_search=1)
shows that the average hourly cost for a product development engineer was almost $300/hr. It’s important for managers to know the true cost of an engineering hour if they are to use these resources effectively. Managers must know when it is better to outsource, use an internal resource, or hire a new person or persons. If internal resources are always “free,” then this decision is predetermined and the results will be to use less qualified people in at least some instances.
Action steps you can take:
- Calculate and publish the average hourly cost of your people
- Hire for your core and outsource non-core activities
- Keep track of how much everyone spends on each project
- Review progress at least monthly—do we still have a positive ROI?
- Reward and model time management skills
Reason 3: Small Idea Pool
Successful new products require innovative ideas and diverse, knowledgeable teams. Ideally, these teams have a diversity of technologies, marketing, manufacturing, and finance team members. 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 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 products 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.
Small companies can use consultants and product development teams to increase their idea pool without increasing additional fixed cost overhead. Large companies should encourage, if not mandate, that teams interact with each other in as many ways as possible.
- Action steps you can take:
- Model and reward these behaviours:
- Open mindedness
- Respect for other’s ideas
- Good listening skills
- Collaboration
- Knowledge sharing
- Adequately fund the Conceptual Design phase and include as many people as possible. This phase sets 90% of the development budget and 90% of the unit cost
- Build a network of experts and use them to as part of your team
Reason 4: Local Optimisation
Local optimisations include measuring and monitoring how many man hours are spent per drawing, how many lines of code per hour, how precisely the budget is met month to month, and how many patents were filed, ensuring that any outsourcing activities goes to the “lowest bidder.” Intuitively, these all seem reasonable and rational methods of managing people and activities; however, the Theory of Constraints shows us just how destructive they can be. (See The Goal by Eliyahu M. Goldratt.)
The ROI of any product development project is going to be predominantly determined by effective risk management, good decision making, and market fit. Focusing on speed and cost of each task generally leads to greater risk taking and lower quality decisions. In our rush to get everything done, we ignore the market.
Action steps you can take:
- Model and reward behaviours that focus on:
- Good decision making
- Risk management
- Market validation
- Insure incentive systems are based on ROI, and not just cost
- Outsource tasks to the best value, not the lowest cost
- Hire the best value employees
- Don’t set unrealistic budgets or time goals
Reason 5: Documentation
“Tribal knowledge” is knowledge about a product or process that is undocumented and exists only in the heads of a few individuals. Management must make it clear that nothing less than completely accurate and tangible documentation is required. Spending millions of dollars to develop ideas and not documenting all the details is just not smart. 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.
Lack of good documentation practices often results in what is often referred to as “the last 10% of the project taking 90% of time.” Time to market is important, and missed steps can be costly. It is common to see product recalls that were the result of sloppy documentation. New product launch is difficult enough, and these types of errors can be fatal.
Action steps you can take:
- Mandate documentation standards for software, drawings, processes and reports
- Implement good drawing control procedures
- Use checklists to approve drawings
- Create a drawing trees at the start of detail design to make it clear what drawing will be produced
Finish Line has completed more than 1,500 projects for 275+ 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.
