Outsourcing product development can make any OEM nervous. All of us with experience in the field have seen firsthand what happens when outsourcing goes wrong -- higher costs and time-to-market delays reduce sales volume, lower profitability, and shorten product life cycle.
In a perfect world, OEM project managers communicate their general product requirements to the development partner and establish a collaborative relationship with them. Both parties work together to define the exact requirements for the new product, and the development partner demonstrates the capability to execute.
But this 30,000-foot view makes outsourcing product development sound easier than it really is. In the real world, projects stall due to myriad problems such as:
- Vague or conflicting product requirements
- Design solutions that fail to perform as expected
- Processes that don’t include validation and functional testing
Understanding why outsourcing problems arise -- and knowing how to prevent them -- takes experience. Product development issues manifest in many ways, and a few of the more common examples include: system interfaces aren’t well defined; firmware features are improperly implemented; and components or subsystems don’t meet required performance. Any of these can result in additional development cost or increased time to market.
To avoid problems in the first place, begin by recognizing vulnerability in three key areas:
- Product requirements
- Technology application
- Development practices
When you evaluate prospective product development resources with these three areas in mind, you improve your chances of finding a partner able to deliver the right product for you.
There can be no ambiguity when it comes to product requirements. It’s critical that you first agree, in detail, to what your development team will design. They must be able to leverage experience and challenge your product requirements when appropriate. For example, if you have a requirement that will create issues with electromagnetic interference (EMI), you want a development partner who can suggest a design change that will eliminate the problem.
Identifying issues like this empowers the development team to dig deeper. Sure, they’ll document the overall architecture, but they’ll also team with you to evaluate expectations for individual components, environmental requirements, types of testing, and required certifications. Good communication eliminates the unknown and puts everyone on the same page, working toward the same goals.
Unknowns create uncertainty about costs, deadlines, and functionality. If you don’t define and agree on product requirements, how can you be sure your development partner possesses capabilities needed to complete the project on time and on budget? How do you know when you’re done?