TECHNOLOGIES
Digital and analog
Internet comms.
Miniaturization
Power Supply
Process controls 
Wireless and paging

INDUSTRIES (partial)
Automotive
Consumer elec.
Medical
Robotics
Semiconductors
Telecommunications

OPERATING SYSTEMS
Linux ©
PalmOS ©
pSOS ©
RTXC ™
VRTX ©
VxWorks ©
Windows © CE

LANGUAGES
C++, C
Assembly
Java ™
Visual Basic ©
Visual C++ ©

Can companies do anything to give their products a longer life and more functionality, and still reduce costs? This session offers an inside look into how product design can improve "shelf life." It also describes how product re-designs can save money and how a streamlined design increases functionality – all at the same time. Such an approach begins with a "manufacturability review." Conducted by an experienced design engineer, such a review will explore product development and direction, design opportunities and their effect on the bottom line. This session will also discuss how the pressure to "over design" a product and tight development deadlines push engineers to create "extra robust" versions of existing products, the resulting negative implications and how to overcome such situations.

This paper will cover several elements of Longer-Lasting Product Designs (LLPD). First, understanding your environment and communicating effectively will allow everyone to work less and have more fun. Second, there are three different methods to produce LLPDs. Next, outsourcing your LLPD can dramatically improve your chances of achieving LLPD. Last, a Manufacturability Review is defined, including the people involved, agenda, and action items from this review.

The engineering team is interested in the following:

• Reducing time-to-market (reducing the R&D cycle (without more work)
• Reducing their sustaining engineering role
• Limiting or removing late night work hours

The marketing team is interested in the following:

• Reducing time-to-market (reducing the R&D cycle without more work)
• Confidence that the right product will get designed correctly and on-time

Other departments have their goals and needs as well. This paper primarily focuses on engineering and marketing.

Product life cycles are decreasing at an alarming rate. Technology advancements and competitive pressures have made short life cycles the industry norm. Also, automation has been the key to shortening the manufacturing process. Take note of the following chart. Design time is not decreasing. This implies that all the new design tools are allowing engineers to produce more complicated designs in the same amount of time as before, but not significantly reducing the design time to match the change in product life cycle.

Product Life is defined as the life of the product in the market before being replaced with a new model. This is not to be confused with reliability.

It will be helpful to understand a typical product life cycle to determine when and how LLPD issues must be addressed. Figure 1 shows a very high-level view of product life cycle for any new product, be it a house or an embedded system. The job functions that typically participate in the development and sale of a product are shown with the activities generally associated with those functions above. In many companies, the lines between these job functions may be blurred, but the activities and responsibilities are universal.

The primary function of marketing is to determine or generate a market need for a product. The marketing job function is primarily to provide the product concept and to help validate the commercial specification. These people are responsible for identifying the tradeoffs for additional feature sets versus time. They are responsible for evaluating competing products, market share, name recognition, etc. They are also responsible for working with the media. It is important that marketing communicates clearly the new product features and availability. To under-promise and over-deliver is always best. Remember, the competition is watching your performance as well.

The role of the sales job function is to take the final product identified by or created by marketing to the market place. Sales teams are generally in very close contact with the client base and can serve to validate the product concept and assist in the creation and validation of the commercial specification.

Engineering’s role in product development is to translate the product concept into an actual product. Engineering can have a valuable role in developing the commercial specification and validating the technical assumptions made by the marketing and sales functions. Engineering is responsible for communicating with the design team, including which features are easily implemented and which require additional design costs and/or recurring costs, thus escalating the total costs and delaying market introduction.

The role of program management is to represent the customer’s interest in the product and to be a champion for the product within the company. Program management provides important information concerning the validation of the design and feedback of information from the product users and potential users.

The role of manufacturing is, obviously, to build and ship the product. Manufacturing also plays a valuable role in verifying the ability to economically produce and test the product and determining how to improve the quality of the product. Its input is vital to the design team to make sure that the proper test points and materials are used to ensure quality and ease of manufacturing. Certain component package types and board geometry can lead to unnecessarily higher costs and longer manufacturing time.

Almost all new projects are on an accelerated schedule in order to make it into the shrinking market window. Purchasing needs to identify exactly what the process is to make purchasing requests and, in turn, for those requests to become purchase orders. Purchasing can provide formidable information regarding vendor and component selection, second sourcing and scheduling. Often engineers select wonderful components only to find out that the product availability really isn’t what was promised or that "in stock" means the material to make the electronic components are co-located on earth. This kind of problem ends up in a re-design of the circuit, further delaying the project. If we had only known…

After the product is sold, the customer support team actually becomes the "sales force" for future sales. No matter how great the product is, people will remember service for a long time. The customer support team has a great deal of valuable experience and ideas to make sure that future projects and versions can be serviced quickly and inexpensively. This group is responsible for conveying these ideas to the design team.

The diagram below shows the flow of activities from one to the next without any backtracking. If this was used as an actual implementation model, the resulting product is not likely to meet the customer needs, not likely to be reliable and will probably be short lived in the market place. All departments need to be involved in each step, however, the chart outlines the principle players at each stage.

Figure 1: Simplified Product Life Cycle

The remainder of this paper will discuss a more detailed view of the activities shown in Figure 1 and how these activities can be structured to ensure high reliability products.

It is the methodology used to produce products that fit not only into today’s market, but also into the future. Future-proof. (Schedule: normal vs. LLPD market life)

• Less sustaining engineering
• Company can generate more revenue early on and establish firm position in market
• Employees can be part of a more successful less stressful product-design process and work environment

• Tendency for creeping elegance, over design under the name of "LLPD"

Research and Development costs are at an all-time high. In the past, a particular R&D expense could be amortized over a longer product life, therefore reducing the R&D cost associated with each unit. Now R&D departments have to work harder at creating LLPD cycles to stay competitive.

Every time a new product is created, a significant number of steps, amount of cost and degree of risk are in order. Marketing must be educated to the pros and cons of the new product features. Sales must begin to sell the new product at the risk of not selling remaining inventory of the prior product. Manufacturing has to re-tool (even with simple EPROM/Flash changes). In some cases, each of the steps may be minimal, but in every case there is an expense. Each new product, no matter how extensive the design process is, will need to be tested in the field for reliability, functionality and user acceptance. "Bigger, better and faster" isn’t always better in the customer’s eyes.

Recently, the chief information officer of Netscape Communications said, "Netscape generates 100 percent of its revenues from products released in the last 12 months." He has witnessed that product life cycle is shrinking at an alarming rate. In other words, all the engineering effort expended over one year is not directly toward a product in the marketplace.

Every product that has a product life cycle is decreasing faster relative to the development time.

Competition is the driving force. (If you won’t, they will!) Look at PCs, cellular phones, DSS, DVD players, etc. The printed price is very seldom correct. The price has been reduced since the brochure artwork went to the printer. Those who enter the market early get to sell their product at higher margins and therefore recover the R&D expense earlier, which in turn allows more money to be expended on R&D the next time around.

There are 3 methods to create Longer-Lasting Product Designs.

1. Decrease development time on the front end
2. Increase the product life
3. Modularize the product so that the next product is an extension of the first. I know that everyone re-uses some part of the previous product to make the next, but that is not what I am talking about. I am talking about a conscious effort in the requirements-specification stage to allow for the expansion of the product. Sometimes it is a fine line between designing for expansion and creeping elegance.

In each method above, the starting point is communication. Next, assemble the team and get agreement and buy-in on the goals. Consider everyone’s input and opinions and think them through before rejecting any bad ideas. Also, keep in mind that other departments have other goals and objectives that are completely understood by the other groups. Build trust with other departments. Nobody wins if marketing and engineering and other departments are at each other’s throats. Determine if the time and personnel resources with on-time and on-budget experience are available. If not, consider outsourcing your LLPD project.

LLPD begins with the product specification phase. At this point, all departments need to determine the requirements and define the statement of work. Each department’s input is very important to obtain a LLPD.

Special attention must be taken to ensure that the product is not over-designed or under-designed.

The product team must be a TEAM. This includes all the departments together. Any error along the way will delay market introduction, whether it be a software bug or product packaging problem.

There must be a process to differentiate and communicate design-change requirements from wish list items. It is sometimes confusing which features change along the way because they are required for market introduction are included just for fun.

Communications between departments is essential. It is here that the real product is defined and the feature set is weighed against time to market.

Every day a product is late to market is a direct reduction in the life of the product, especially in the early days of product introduction. This is where name recognition, market share and maximum sales prices are obtained. DSS systems were introduced at $900 with no discounts. Now you can purchase the same system for under $99.

By outsourcing, the product requirements must be defined in order to communicate them to an outside firm. If any changes or additions are discovered later, they must be internally and externally evaluated before allowing the product development to stop and shift gears. The outsourced partner is focused on meeting the requirements and careful not to deviate just because someone "suggested" a new feature.

Selecting a development outsourced partner is very much like selecting a manufacturing partner. The same pros and cons apply.

1. Outsourcing creates LLPD and an internal team ready to roll out the product that is not burnt out
2. Outsourcing product development is often less expensive than in-house resources. For example, most companies do not consider the costs of sustaining and clean-up work or the costs of "down time" when analyzing outsourced vs. internal costs. Our experience shows that these areas may increase internal costs by 20 percent.
3. Outsourcing partners typically can juggle resources more effectively in the event that the project requires temporary resource adjustments.
4. Outsourcing partners are not involved in other aspects of the company and are therefore not lured into meetings, discussions and other details that, although interesting, may not be important to the mission.

1. Selecting a bad outsourcing partner could mean late product delivery, poor quality and workmanship and a lack of documentation.
2. If the outsourcing partner and the existing engineering staff cannot work together and communicate freely, the cost and schedule will definitely suffer.

Many medical equipment companies design products with disposable components such as catheters, tubing, barriers, etc. These companies’ core competency is designing, manufacturing and cost reducing these disposables rather than focusing on the instrument (electronic box). Therefore, the development team may not be up-to-date on the newest GUI or development tools and processes. Because the time between development cycles is long, experienced engineers get bored with sustaining work and tend to move on to other divisions or different companies. Outsourcing the embedded electronic and software development will keep the in-house team focused on the disposable development while the outsourcing partner focuses on the instrument itself.

How is the consulting role different from outsourcing? Consultants have a purpose in this world. Getting the work done is not one of them. I am talking about true consultants. These are people who can teach and train people to be more focused and teach people new processes, but are rarely involved in getting the product developed. Contractors, on the other hand, are simply temporary employees (even though the IRS has separate rules).

Longer-Lasting Product Designs can be accomplished for new designs as well as for existing products and designs.

The newest fanciest STBs end up in the best, busiest and big-name hotels that cater to the traveling businessperson. When replaced, they can be placed into other hotels, sold to private hotel owners who wish to manage their own Pay-Per-View (PPV) system, or sold to foreign countries, nursing homes, etc.

Also, take a step back and think about the product that you have in front of you. Is this a cable television PPV system? The answer is yes and no! A cable STB system is much more. It is a computer network capable of A/V distribution, two-way data communications between thousands of nodes that operates perfectly in a noisy environment. The host software application could be written or edited to install or monitor movie-channel selections, but turn on/off devices remotely, monitor remote sensors, etc. Keep in mind that all the true embedded software can be re-used. Only the application layer software should be changed.

Hospital equipment entails the same process. In the end, it moves to smaller private hospitals, small-budget county hospitals, foreign countries, universities, veterinarians, etc.

Engineering can take features and turn them into future options in order to enter the market sooner and extend the life of the product with upgrades. For example, NorTel PBX systems have several upgrades that are available after password entry. Also, the advent of FLASH memory allows products of all sizes and shapes to accept upgrades. Some companies would rather introduce products with known and unknown bugs, but meet the feature list. These companies assume that they will send out bug fix releases later. The better plan is to release a smaller feature set now fully debugged with the system-designed hooks available to introduce the upgraded feature list later. The end user will associate your product with quality.

Before the advent of FLASH memory and other new technology, some Cable Set-Top Box manufacturers made a common and substantial design flaw. They placed significant intelligence -- and therefore more chance for design flaws and reliability problems -- in the Set-Top Box instead of at the head end or centralized server computer system. The problem could have been avoided with adequate communication. In the case of one company, the engineering department had no idea that the cost to update software in the Set-Top Boxes was enormous, especially in a 1,000-room hotel. Below is a list of all the problems:

• Access to every room is not easy. Many hotel guests do not allow maintenance people in the room during their entire stay and hotel management always obliges. Flight crew rooms are reserved by contract and often have sleeping people during the day and night.
• Gaining access to units that are often bolted down permanently to furniture often with different security style screws isn’t easy.
• Asking contract maintenance people to remove a 64-pin, ROM-based microprocessor and replace it with another one without bending the pins while observing ESD precautions is a difficult proposition. And when is Quality Control performed?
• Re-programming features to match the room number, feature setups, attachments to in-room bar, etc. also must be undertaken.

Engineering did not design a less-than-perfect product on purpose. They just didn’t have all the input from the other departments to make the difference. All departments are to blame for not communicating. Some possible solutions below can help each department understand the relationship with the other departments.

• Send engineers out in the field for a new installation or a retrofit. Engineers

are bright people with awesome ideas if they understand the problem.

• Marketing, manufacturing and customer service should attend design reviews.

Although marketing people may not fully understand schematic, controlled impedance, and other technical jargon, they will begin to understand the complexities of a given feature or provide an opinion about whether or not path A or path B is better. Care should be taken to make sure that the design review does not migrate to a new system-level design meeting. The specification should be frozen before a detailed engineering design review.

• Other departments should learn more about the engineering process. For example, if a design change is necessary, it is far better and less costly to make that change one day before PCB fabrication than afterwards. The cost to rebuild a PCB fabrication is very expensive in time and money. Unfortunately, the speed-turn cost of the new PCB fabrication is the least expensive component to the design change. Last-minute changes delay other departments such as manufacturing, marketing demonstrations, potential stock impacts for delayed introduction and a lot of labor being expended to make last-minute changes. Finally, the chance for error is greater.

A manufacturability review is a meeting to review all aspects of the product development cycle to ensure that the product can not only be manufactured, but will live through the market window and potentially give a head start into the next product cycle.

Preferably, the first meeting should be conducted early in the project. At least one subsequent meeting should be scheduled to address all the issues. Remember, LLPD is a process that continues from the start of one project/product to the next project/product. If the project goals change considerably, or if the development cycle is delayed due to external influences such as competitor product introductions and material shortages, the manufacturability review should be conducted again. The product development team should lead the meetings and personnel from manufacturing, purchasing, shipping, program management, customer support, sales and marketing need to attend.

The meeting format is designed to maximize the time spent together as a diverse group and to keep focused. Attracting this many people to a meeting is often difficult to schedule. Additionally, longer meetings tend to have people coming and going and lots of information not being communicated or being repeated. The first meeting purpose is primarily an introduction of key players, an overall review of the project and an assignment of tasks. The second meeting, and potentially other meetings, are designed to coordinate and communicate information followed by decision making on the approach. Depending on the size of the project, additional meeting(s) may be required to perform the decision making. It is very important not to schedule meetings just for the sake of another meeting. Often a quick conference call from one department to another can resolve an action item from the previous meeting.

Prepare in advance. Send out a notice for the meeting and include enough in the agenda so everyone else can be prepared. It is difficult to keep on schedule if someone attends a meeting totally unprepared.

Make sure an assistant to a technician or engineer is assigned to be scribe for the meeting so that everyone can be notified with the meeting results. If not, a week after the meeting, there will be several opinions about what was decided in the meeting and the action item list will be foggy.

Review the rules of conduct for the meeting. With so many people and approaches to the same project goals, it is difficult to keep staff members focused during the meeting and not step on any toes in the process. Typically, some people are more vocal than others.

Include an introduction of attendees. Often, people within different departments have not met other team members. Everyone should introduce themselves and their responsibility in the project. Make sure everyone has telephone numbers, fax numbers, e-mail addresses, pagers, etc., to stay in touch. Each person should express the best method to receive communication. Not everyone has access to or responds well to all forms of communication.

Assign someone or some e-mail address to be the default routing address for all communications so that everyone is kept abreast of the message traffic.

Care must be taken by the facilitator to get input from everyone including those that are shy and reserved. Often they are the ones listening and compiling the most information.

Discuss, in general, the nature of the project and the information to be gathered before the second meeting, and how that information impacts the project.

In turn, each department should enlighten the rest of group to the concerns and issues that its department is facing. A short amount of time should be allocated for the group to probe and make suggestions. Between the first and second meeting is the time to think ideas and concerns through completely and make suggestions. Otherwise, the meeting could go on for hours. Let’s review the following two examples of potential issues that affect multiple departments.

• To match the new lower-voltage technology components, engineering would like to use a new input power supply for a new cellular phone design. While this potential cost reduction might be a great idea, other departments need to review and resolve any issues. For example, marketing may have determined that the attraction to their product line is due to a significant line of accessories including wall chargers, cigarette lighter power cords and aircraft power plugs. This idea may require a whole new set of products to be re-designed and confused with the previous series. Manufacturing may have to re-tool its burn-in and factory test fixtures. Until now, manufacturing has been able to share its floor space, tooling, burn-in equipment, etc., among multiple products being manufactured. If the change is approved, customer service may want the new "cable" or "connector" to be used differently or use a different connector. They may also suggest adapters for existing model chargers.

A better approach may have been to anticipate the change to lower-voltage parts and design chargers (typically lower volume, higher margins) with another terminal for the other voltage requirement. While hindsight is 20/20, some companies are blind even today about mixed voltage designs. Mixed voltage logic issues have been around since ECL and CMOS were introduced. Furthermore, three-volt logic has been around for almost a decade. After all, tomorrow’s logic is not going to run at higher voltages

• Marketing has suggested a new packaging design. Manufacturing should leave the meeting to determine the cost impact, if any. Engineering should leave the meeting to research whether the product will fit and be secure in the container. Manufacturing may be able to save money and time by using very similar packaging from another product but with different graphics applied.

Each department should leave with action items specific to their department and how they can address the concerns and issues of the other attendees.

Lastly, with everyone present, determine the second meeting time.

The second meeting, and potentially subsequent meetings are needed to communicate information and make decisions based on the action items and research after the first meeting. Group buy-in and acceptance is very important. Depending on the size of the project, additional meeting(s) may be required to perform the decision making.

As before, always prepare in advance. Even though most people will remember everyone’s name involved, other will not. Let everyone introduce themselves again. This also avoids embarrassment to those who forgot someone’s name or position. Lastly, remind everyone of the rules of conduct for the meeting.

Each department should leave with action items specific to their department and how they can address the concerns and issues of the other attendees.

Lastly and as before, with everyone present, determine the second meeting time.

Managing reliability means managing documentation and the validation of that documentation. All documentation must be thoroughly reviewed by those who have a stake in the resulting product.

Companies that establish sound documentation and validation procedures have consistently better performance to schedule and budget. Resulting products are more easily maintained and more reliable in the consumer’s application. Companies are also given more flexibility to outsource if there are sound documentation practices. If the documentation for a project is complete and validated, then it is easier to make the choice to use a services company or independent contractor because all of the valuable intellectual property is left in the company in a useable form.

Longer-lasting product design is a process, not an end in itself. One does not set out to create longer lasting products and one day say, "I have finished making this product." This goal is best achieved by documenting and validating during every step of the development cycle.

This paper diagrammed one method of breaking down the steps in a project and validating through documentation and review. There are many other procedures and groups of documents that can achieve the same purpose. The key to developing longer lasting product designs is to follow the following three steps through every phase of development and understand that the road is not always straight. The reason for validation is that we all make mistakes. When validation uncovers a problem, we must be willing to go back to the drawing board and try again.

Research - Document - Validate

2100 10th Street, Suite 100 / Plano, Texas 75074-8016 / 972-265-6000 / info@paragoninnovations.com

© Copyright 1996-2000 Paragon Innovations Inc. All rights reserved. Paragon Innovations is Year 2000 compliant.
This page was last modified on 11/03/2000 .