Communities & Groups
Publications & Resources
Career Center

Making the product development process work

By Leslie O. Magsalay

Executive Summary
New product development and introduction can be the lifeblood of corporate success. But flying by the seat of your pants is no way to ensure innovation. Companies that aim to bring new products to the market consistently must have a solid framework for its product lifecycle process and use best practices so teams develop quality products that meet their customers’ needs, all while adhering to the target launch dates.

A new product development process is the overarching framework that manages an idea from its ideation and concept phases through launch. Each functional area that handles the work for each phase has its own procedures. This framework is supposed to contain these processes, which are the recipes for how things are completed. Most companies have forged their own product development process. The process involves a cross-functional team represented by people in different functional roles. You have to deal with various interests and make judgments about what’s important and what isn’t. Organizations should design a product development process that fits the company. There is a difference between a product lifecycle management framework that takes into account every product development and a quality process such as waterfall, agile, Six Sigma, TQM (total quality management) or lean manufacturing.

Be sure to involve functional teams in the creation of your company’s product lifecycle process to manage new product introduction or new product development programs. Put someone in charge of not only making sure people are following the process but that they also are making changes (with input from others) when necessary. The person in charge usually is an executive or someone who reports to an executive, and often is called a process owner or program manager. Many companies assign program managers for their product development processes. The program manager is responsible for making sure the process is successful and for changing and improving it over time.

Best in class for product development

Best in class is defined as the average performance of organizations in the top 20 percent of those surveyed. They exhibit an efficient, structured methodology; empowered product teams that drive execution; highly effective decision making; investment in tools; and actively reviewed metrics to manage processes. Figure 1 represents an undefined product lifecycle process. Figure 2 shows a mature, solid and phased process that will help your company turn out new, high-quality products on a regular basis.To exit each phase in the process consistently, senior program managers need a solid understanding of basic product lifecycle process definitions:

  • Product lifecycle (PLC) process: The collection of a company’s business activities that develop, deliver and manage products through their lifecycle.
  • PLC phase: A logical grouping of related business activities, requirements and events, which represent a distinguishable aspect of a product’s lifecycle.
  • PLC subprocess: A set of activities, deliverables and tasks that are outside the direct scope of the company’s PLC but are referenced from it.
  • PLC activity: The “what” component of a process. All activities result in a deliverable.
  • PLC deliverable: The output of an activity. All deliverables are produced to meet a requirement.
  • PLC task: A specific “how” component of an activity.

To have more effective phase exits, senior program managers also will need to have a solid understanding of their programs and product definitions.

How many phases?

The right number of phases for a company’s product development process equals the number of phases needed to divide the workflow into logical chunks. Most product development processes have between four and eight phases. At a minimum, no matter what kind of products the company produces or what industry it does business in, it needs the following basic phases in the process:

A front end or concept phase. The concept phase is where ideas or concepts are developed. Many companies now have a phase zero because when they designed their product development processes they did not appreciate the importance of the earliest phases. The front end is where leaders select from a large variety of product development options. Without it, the company probably will end up with few development options. The concept phase is not the same as the ideation phase, where many ideas for new products are entertained. The ideation phase is where product concepts are considered. The concept phase is where product development options to create the idea are considered.

A business case or plan phase. The product development process allows management to make business decisions about how to invest the company’s resources. The business case phase provides executives with critical information so that they can get their jobs done. No matter what type of product the company develops – hardware, software, chemicals, food, mobile phones or services – leaders must have business case information. The business case also should have supporting data to address the competitive landscape. It should answer “What makes this product different?” or “Why would a customer buy this product instead of the one from a competitor?”

A development and testing phase. The program team in charge of new product introduction or new product development has to get its work done to design, develop and test the product concept. This basic phase is where the greatest variability comes in:

• If the product is fairly straightforward (for example, an improvement to a product or product line that’s already in the market), it may need only one phase to outline the deliverables for this stage.

• If the product is complex, needs to be manufactured or requires the development of processes, it may be a good idea to add distinct phases or subphases. An example would be a new product, such as the iPad, that requires new technology to be developed to meet new customer requirements.

• If the product requires extensive testing to meet regulatory or other requirements, you may include phases that tie directly to that requirement. Pharmaceutical development processes, for example, usually include a clinical trial phase because trials are a major issue in getting a drug into the market. In the high-technology industry, a complex product, such as the next generation iPad or Google advertisement platform, needs a “customer acceptance test” or “beta program” to flush out the product.

• If the company is producing software, the process needs to allow for the iterative “design/test/design” process that typically goes with software development. On the other hand, the process doesn’t have to specify a manufacturing phase because after the product is designed, developed and tested, it is good to go. Common processes for this type of development are agile or the scrum methodology.

In addition, a company will need at least one phase for your product’s design, development and testing, but the number of phases varies depending on your product and your industry. Every product that gets all the way through the development process needs to end up in a phase that precedes its entry into the market, or the launch or commercialization phase. The core product team will need to start planning for launch about one to two phases prior to the launch phase.

Product, and other, definitions

Generally, a product is something of value offered for sale or trade to an external or internal customer, even if that results in zero tangible return to the seller.

However, none of the obvious definitions of “product” are an exact fit. For example, a complex system that contains multiple products (such as boards, a central processing unit and operating system) is not one product but one product solution. Many products that can be sold on their own create that solution. Similarly, a software component burned on a CD or made available for download can contain multiple products.

A project is an atomic addition or change to a company’s product portfolio. Generally, one or more projects make up a program that will release a product or products. A project may depend on other projects, and others may depend on it. A project can become a product through application of additional product-level processes that will make it sellable.

Releasing a product in the high-tech industry requires a program with cross-functional team leadership. A program is composed of many projects that make up a product, along with subfunctional programs that support the product. A product program represents the specific product development and lifecycle efforts that are managed within the product lifecycle process.

Any product that is not owned, developed or authored by the company is a third-party product. Partners often produce third-party products.

This stems from third-party development (also known as collaborative product development), where two companies work together to develop and commercialize a product solution. The smaller company may contribute technical or creative expertise, while the larger organization may be more likely to contribute capital, marketing and distribution capabilities. When two corporations of equal size collaborate, each may bring some specialized capability to the table in developing a complex product or system that requires expertise in both technologies.

Collaborative product development has several variations. In customer collaboration, a supplier reaches out to the partners with a key or lead customer. In supplier collaboration, a company partners with the provider(s) of technologies, components or services to create an integrated solution. In collaborative contract manufacturing, a company contracts with a manufacturing partner to produce the intended product.

Collaborative development (also known as co-development) differs from simple outsourcing in its levels of partnership depth in that the collaborative firms are linked in the process of delivering the final solution to the customer.

Best practices

Best-in-class companies generally feature several best practices in their product lifecycle processes. These practices help define the guiding principles for product lifecycle processes and ensure that the team exits each phase only when the necessary criteria have been met. Adopting these practices into the “how” level of the company’s product lifecycle process will improve each deliverable, consequently improving the quality of the product. A companywide adoption of these practices will improve execution effectiveness and predictability.

1. Focus on the customer. Customers should be involved early and often during product concept definition and planning. Customers’ critical requirements should be identified and documented. Critical require ments fall in three classifications. One, the customer demands them but will not pay extra for them. Consider these the necessary price of admission. Two, the customer likes them and will pay extra. These are the differentiators. Third, the customer didn’t know about them but loves them at first sight. Fulfilling this third class can make the difference between a new product being run of the mill or having a “wow” factor.

2. Define success factors. Identify success factors at the beginning of each new product program. When not executed correctly, these factors will result in poor-quality products that do not meet fundamental customer requirements. Ensure through regular product program reviews and measurement that these factors remain in strict control throughout the product lifecycle.

3. Use defined quality methodology and metrics. Whether it is Six Sigma, lean manufacturing or total quality management, use the company’s defined quality metrics. Design specifications should be defined with full knowledge of design and production process capabilities. Whenever possible, parameters for these quality metrics should be designed with a quality methodology and toolset in mind. A core product team should define minimum acceptable targets for quality levels for things such as reliability, accessibility and serviceability.

4. Freeze product specifications. A common mistake that must be avoided is artificially locking down product program specifications based on inadequate or poorly defined customer requirements. When that happens, product programs often miss their commitments
as the product team is forced to consider customer needs later in the product development. Approval to develop or integrate the product or exit the test phase should be granted only when the team demonstrates the technical capability to deliver a product that meets the specifications defined in the overall program plan. Use the product plan document and overall program plan as a contract process to maintain these specifications. Do not allow specification changes without a contract renegotiation. For example, each revision of the product plan document should be renegotiated with the product approval committee.

5. Program teams for products. Many high-tech companies use the terms core product team and program team interchangeably. Program teams always should be multifunctional. Strategic suppliers should be members of the product team. Dedicated core product team members should communicate daily with methods and tools that emulate co-location. Critical path activities and tasks always should have dedicated resources.

6. Product commonality/use and reuse technologies. New products should be created by leveraging existing systems, platforms, components and standard parts. Product roadmaps should be used to identify the company’s platform opportunities to be incorporated in system and component architectures. Component and platform roadmaps should be defined in such a way as to maximize reuse of existing technologies and commonality. New components should be used as a last option, and only where cost-performance benefits warrant their introduction.

7. Risk management. Use a disciplined process to assess and classify risks (technical, business, program, quality, resource, schedule, legal or cost) for all product programs. Every business and technical review should include a risk review supported by data and summarized in a dashboard. Risks should be tracked on a regular basis to the threshold defined as acceptable by the product team in the overall program plan that was approved by the product approval committee. For each risk, identify the owner, a mitigation plan and the target date for when the risk will be resolved. Business leaders should participate actively in product program reviews to ensure risks are addressed proactively.

8. Exception management. Exceptions to the overall program plan commitments must be identified and documented. All exceptions should be summarized and documented together with the original commitment, the reason for the exception and the recommended new commitment. Risks associated with each new commitment should be assessed and abatement activities documented. The core product team should hold a review with the product approval committee to approve/modify/cancel the exceptions and recommend corrective actions. Decisions should be made promptly to minimize their impact on the product program’s cost, schedule and product quality. Whenever the product program commitments are changed, the core product team must re-plan. Build the exception management process into the company’s overall change management process.

9. Product integration. Product integration should be a continuous process that develops the kernel functionality first, then adds additional functionality, step by step, until the full product has been developed, integrated and tested.

10. Process activity management. Phase exit criteria are process steps that should be completed to satisfy phase exit requirements. Product teams setting these criteria should ensure all process activities and tasks result in the highest quality output. This allows the teams to manage project risks by aligning the process steps with the phase exit criteria. The process should not slow down or prevent the program teams from delivering products to market.

11. Measurements. All new product programs should be launched with clearly defined targets developed by the product team and approved by the product approval committee. These measurements/targets should be reported through dashboards. Quality methodology, commonality, reliability, defects (bugs) tracking, product cost, product development cost, and product program schedule are examples of the minimum measurements required for each product program

12. Product quality. Customer-driven critical requirements should be recognized as an important subset of the new product functional specifications, which should be defined and frozen in the definition phase. Quality acceptance goals and boundaries (such as mean time before failure or defects per million opportunities) should be defined clearly before product plan approvals for the system test phase, customer acceptance phase and launch phase. These are real requirements, not lofty goals that can be traded off later against the product program schedule. This view of quality should be derived from customer inputs and from benchmarking studies of the new product against competitive world-class products. Internal design specifications, internal interface specifications, and component and integration tests should be defined and frozen early in the develop/integrate and test phase.

The quality of the product lifecycle process phase exit criteria and the quality of other supporting business processes are critical elements of predictable and well-executed product development.

13. Product costs. A market-driven product cost target assures that new products can be priced competitively. A detailed product plan vdocument should be developed to assure the most effective product design, thus taking advantage of proven manufacturing processes and established suppliers. Service-related costs, such as field replacement units and service delivery, are important program goals, and they should be tracked throughout the product lifecycle by the product team. Total product lifecycle costs should be considered in the product plan document. They should include costs and provisions for disposing of old products returned from the field. The cost of maintaining old products and maintaining sources for field replacement units may be substantial and could hurt the overall profitability of the new product introduction.

14. Product and process benchmarking. Within the scope of any company’s product lifecycle process, benchmarking compares your products and processes to the best, regardless of industry or geographical location, and learns from that comparison. Benchmarking seeks understanding of products and development processes and continually compares them to internal or external best practices to improve performance and competitive advantage. Product teams should begin their search for best practices and develop a benchmarking process during the definition phase.

15. Lessons learned. Inevitably, every product program contains some level of mistakes. To improve execution effectiveness, each product team should maintain and regularly update a list of lessons learned, including “worst practices,” so that the same mistakes can be avoided by future teams. A core product team should document lessons learned and conduct reviews to learn from mistakes. Sharing and adopting best practices should be in the company’s DNA and should become a significant part of the company’s product lifecycle process. Product teams should share their pitfalls and successes with colleagues in other organizations and functions and to learn from their experiences.

When celebrating successes, a product team should display mistakes so that people will see them grow and learn not to repeat the same ones. Product teams and product approval committees should remain focused on systemic problems. Lessons learned should be compiled and communicated during the launch, sustain and retire phases. The program team should make it a habit to seek out best practices through open communication with other teams within the company.

16. Phase exits. Program reviews or phase exit reviews connect the ongoing work of the program team with the business acumen of executives. How many reviews should the team include in the product development process? The team will need a review that kicks the program off as well as a review that assesses the business merits of the program. It also should be reviewed when it completes a phase and starts a new one. Finally, the program team should hold a review before it launches the product into the market. That’s a point of no return, and both the core program team and the company’s leadership should be comfortable with the decision.

As long as the team completes those reviews, many programs can proceed to market without other reviews – as long as the programs continue to meet the objectives in the business cases.

Teams should have more reviews when the product team built a business case but the program has major uncertainties, will cost significantly more as development proceeds, must pass outside hurdles or breaks new ground.

Leslie O. Magsalay is the founder and chief operating officer of The PMO Practice. She graduated summa cum laude with a master’s degree in electronic business management from Notre Dame de Namur University. She has received lifetime achievement awards for her work in portfolio execution and operations. As COO, Magsalay has led more than six merger and acquisition program integrations for Fortune 500 clients and has saved or added millions of dollars to clients’ bottom lines.

Print: Share: