Top 10 Mistakes to Avoid in Product Development

Mistakes are a part of life and certainly part of the learning process. There’s a saying that goes, “If you’re not making mistakes, you’re not learning.” In product development, as in life, mistakes are inevitable. But knowing some of the most common pitfalls to watch out for can help you and your team avoid them so you’re stronger and more ready to take on bigger issues as they arise. As George Bernard Shaw espoused, “Success does not consist in never making mistakes but in never making the same one a second time.” Here are some of the key mistakes observed in hundreds of product development teams.

Top 10 Mistakes to Avoid in Product Development:

1. Losing Control of the Product Development Costs

A team is armed with a good kick-off scenario. The project is launching with a well-defined scope and set of requirements. Targets have been properly designated. The team knows the mission and its goals. Six months into the project, the project engineer runs a projected, costed bill of materials and then… SHOCK. The bill of materials projection rollup vastly exceeds the target cost. What happened?

In this scenario, the team lost focus on the projected cost implications in a myriad of technical decisions in the course of execution. Bad news can happen but, what you want is to have bad news discovered early. One tip for helping to identify bad news early (when there is time to course correct) is to start with sub-system and key component cost budgets. These need to be established early and validated frequently — bi-weekly is not too frequent.

As an example, on complex product development and design projects involving electronics systems, establish early budget targets for the electronics (to the board level) and mechanical components or expected cost drivers. The numbers will likely vary as the project progresses but constant monitoring will enable the “puts and takes” to be assessed and over-runs remediated in a timely way. Worst case, cost vs. feature vs. requirements trade-offs can be made early in scenarios where it is anticipated that “the wheels are falling off the bus.” The sooner variances are confronted, the lower the impact to the project cost and schedule, or the disappointment when the features have been delivered at a cost that kills market acceptability.

2. Losing Focus on the Product Requirements

In the heat of the project, it is easy to lose sight of the complete nature of the requirements that need to be driven into the product being developed. Often, these oversights are not discovered until late in the development process. The design may be so far along that missing features cannot practically be incorporated. Best case, correcting for the missing requirements may be quite costly in terms of schedule or development budget. Missing requirements can play havoc with cost projections as well.

3. Failure to Monitor Schedule

Again, in the heat of the project, it is not unusual for the team to lose sight of the project schedule. While hindsight is 20:20 and easy to realize, it takes effort to monitor and track schedules to completion. Some companies have elaborate tools for monitoring estimates to completion (ETC). Managing very large projects may involve regular activity to keep ETC under control. In smaller companies, startups, and smaller projects, such controls are often missing or not monitored frequently enough. There is an old saying that there is no project so small that it cannot be mismanaged. Often, the loss of schedule control is a factor in making even small projects grossly over-run in schedule. And, by the way, time is indeed money. In almost every case, for a given set of work, the one that takes longer on the calendar will cost more than one completed more quickly.

4. Unchecked Scope Creep

This is often the “death of a thousand cuts.” A small, incremental change to adjust the product functionality can have a huge impact. This small change in itself may not kill a project’s schedule, budget, or product cost. However, the cumulative effect of change after change can wreak havoc with project control. Careful review of requirement changes along with the effects on project cost, schedule, or product cost needs to be performed. Companies frequently will do this for big changes, but routine review of the baseline and any changes is a key to keeping the scope under control.

5. Inadequately Resourced Project

A well-designed project starts with a reasonable definition of requirements and features along with projections for budget and schedule. Once a decision is made to “go,” organizations are ready to get moving right away. However, often the project starts slowly with gradual ramp up of the necessary talents and funding. As an example, consider a project with a kick-off plan starting with a team of five engineers ramping up to an eventual team of 15. What happens when the project team kicks off but only two of the engineers are actually working the program? What happens when the five engineers show up but each of them is beginning the new project while still ramping down from older projects? What results is a slow project start. Often, no amount of overcompensation with extra resources on the backend can resolve the problems of a slow launch.

6. Failure to Confront the Issues

Bad news is, at best, painful. It is not uncommon for poorly managed teams or companies to want to “shoot the messenger.” Is it any wonder that team members will sit on problems, trying to brute force through obvious failure rather than raise their hand to identify the issue? Eventually the smell of the decomposing body becomes obvious to all. At that point, it is often much more costly in terms of time and expense to deal with the issue.

7. Losing Control of the BOM

This is crucial. The project starts out with a target Bill of Materials (BOM) cost, derived from the following chain:

                             Retail price > Average Selling Price >
Wholesale Price > Manufactured Cost > BOM cost

In a well-structured set of product requirements, this “top down” approach is validated through a rough “bottoms up” evaluation to ensure that the goals are right from a business standpoint and are realistically achievable. Assume, for this example, everything was done right at the start.

Now, after several months’ effort, the design is fairly mature. At this point, someone on the team starts to do a roll up of what the BOM cost looks like. Disaster strikes. The BOM cost projection is significantly higher than originally projected. At best, the business value of the project is compromised. At worst, the projected BOM cost totally invalidates the business assumptions.

How to avoid this? At project kickoff, make sure the BOM budget target is broken down into subsystem targets. Make sure team members are making early and frequent updates to their projections. It may be impossible to fix things easily at the end of the project whereas, if addressed early enough, issues can be investigated and managed within the team. As with item #6 here, getting bad news on the table early allows for the issues to be resolved with the least impact.

8. Wrong Team

There is no project so small that it cannot be screwed up. Thinking that a project of lower priority or seemingly lower complexity can be staffed without senior engineering oversight or with team members who have performance issues, is short sighted and often doomed to fail. Even the seemingly simplest projects can fail if the right team is not assembled to execute them.

9. Ignoring Market Intelligence

The world is a dynamic place and the pace of change and new product introductions is accelerating. It is not uncommon for new product development processes to take nine months to two years (or more in some product categories — especially medical devices). The competitive landscape is not fixed. Often, the product requirements which were originally conceived can be compromised by the announcement or introduction of similar products from other companies. Failure to recognize that the original requirements or feature sets need to change due to market realities can result in a product launched according to plan but months too late. Everyone hates change and scope creep, but it is better to deal with the world as it is than to ignore the realities of the marketplace.

10. Failure to Execute on the Full Set of Deliverables

Many products suites are composed of a core product with a range of complementary accessories required at product release. In the best projects, the core product teams are properly staffed and are working to a set of appropriate, well-defined requirements. The need for mandatory accessories in the requirements set is identified. However, how often are the accessories not defined or staffed until very late in the project? In many cases, the product cannot be launched because the necessary accessories are not available. If one thinks this is only the purview of poorly run product development processes, consider a cellphone recently released. This product launched recently without an audio jack. However, several months after launch, the manufacturer still does not have its wireless earpieces ready for release. While this manufacturer will survive the issue, clearly an opportunity has been missed to capitalize on the full product set. It is easy to put the accessories on the “back burner” but failure to plan for their readiness and to execute in accordance with the product plan can delay or compromise a product release or business case.

Conclusion

So, there you have it — ten product development issues to avoid. Keep these areas in mind in product development to help you avoid unsuccessful projects, delayed launches, and missed market opportunities. You’ll be leagues ahead of the competition—and much better positioned to deliver a successful product, on-time, and on-budget.

‍