jump to navigation

Starting a Product Development Team November 12, 2012

Posted by Tim Rodgers in Management & leadership, Product design, Project management, Quality.
Tags: , , , , , ,

A few weeks ago I interviewed for a job with a local company that decided they wanted to bring product development in-house and transition out of a contract engineering partnership. I didn’t get the job, but that experience got me thinking about how I would create a product development team from scratch, specifically how to organize the team and what skills are required.

In this case the firm had an established product line with suppliers and a contract manufacturing partner, so the general “make vs. buy” decisions had already been made. Regardless of the status quo, it’s a good idea to review those decisions from the standpoint of the firm’s expected source of competitive advantage. In other words, how does the firm plan to differentiate itself in the market? What are the critical-to-function or critical-to-performance characteristics of its products? Can these be reliably sourced from external suppliers today, and can those suppliers keep up with the anticipated trends in technology to maintain that advantage? If not, then those design elements and product characteristics should be developed internally.

In order to keep the internal staff at a small and manageable size, this suggests three distinct (but possibly overlapping) functions within the product development team:

1. Specialized engineering with domain expertise in the critical design functions that must be developed in-house. These are the people who have deep technical understanding and design experience with the key parts and sub-assemblies. The skills needed here are engineering expertise in the target areas of differentiation.

2. System-level design architects and product integration engineering. These are the people with responsibility for high-level product design and system integration issues. This could include overall project management for the entire product development effort.

3. External supplier and partner management. This isn’t necessarily the same thing as traditional supply chain management because it requires technical oversight to the designs and other deliveries from the suppliers. The skills needed here include remote management and communication.

Two other considerations are the lead time for any invention or innovation required for new products (possibly leading to a dedicated concept or research team); and the expectations for ongoing support or upgrades for products already sold (possibly leading to a dedicated sustaining engineering team).

My inclination is to avoid separate teams for these purposes, unless the expected volume of work in either area is significant. Without morale-boosting attention from management, sustaining engineering teams tend to suffer from an inferiority complex, working within design constraints and fixing problems created by others. I’d rather assign product maintenance to the same team that designed the product, which also avoids the need for knowledge transfer. Similarly, a dedicated research team that doesn’t have ultimate responsibility for product development may underestimate sourcing limitations, integration issues, and production ramp snags. In order to have value, technology must be successfully implemented within cost, schedule, and quality margins, and not just thrown over the wall to a development team.

That’s the framework that I would use to build a new product development team, or analyze an existing team for skill gaps. The next step would be to perform a process and development lifecycle assessment, but that might better addressed in a future blog post. At minimum there should be separate phases for product design, factory prototyping, and production ramp, with phase gate review meetings and quantitative go/no-go criteria. I’ve written about lifecycle considerations in earlier posts (see for example Ramp Readiness Indicators for Product Development). Of course standard project management processes such as early stakeholder alignment, issue tracking, change management, and end-of-project reviews should also be in-place.



No comments yet — be the first.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: