5 More Mistakes to Avoid in Product Development

iosphere/freedigitalphotos.net

By Mitch Maiman

January 2, 2017

[Design News]

Here are some of the key mistakes observed in hundreds of product development teams.

If you read my column in June entitled, 5 Mistakes to Avoid in Product Development, you are now likely avoiding a bunch of common problems, such as losing control of the product development costs, losing focus on the product requirements, failure to monitor schedule, unchecked scope creep, and inadequately resourced projects.

In the spirit of continuous improvement, here are five more mistakes to avoid. I suspect these will ring true, too.

1. Failure to Confront the Issues

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

2. 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 #1 here, getting bad news on the table early allows for the issues to be resolved with the least impact.

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

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

5. 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 is it the case that the accessories do not get 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.

So, there you have it. Another five product development issues to avoid. Is this list complete (we are up to 10 items now)? Probably not. What are the problems you have seen? By sharing, perhaps we can all help each other avoid pitfalls and improve our development processes.

Mitch Maiman is the president and co-founder of Intelligent Product Solutions (IPS), building on a vision of delivering a new model for software and hardware product development that integrates the full spectrum of design and engineering disciplines as a single-source solution.