Faster, Cheaper, Better Products?

Originally Published MDDI January 2004

Product Development



Tips and tricks from insiders for freeing the product development logjam.

Bill Evans and Lisa Scheinkopf

When you started your career in product development, every hurdle you encountered on the path to shipping a product probably seemed new and unique to that project. But as you advanced, you quickly learned that the same problems tend to rear their ugly heads time after time, even across companies. Wouldn't it be great to access some of the collective experience of product developers throughout the industry? A practical workshop session at a recent Medical Device & Manufacturing conference did just that. The workshop, “Obstacles to Streamlining Your Product Development Process,” culled the experiences of about 20 designers, project managers, and engineers to produce a list of the most vexing problems that were preventing them from getting their work done efficiently. In the process of creating this list, the participants also shared some hard-won management techniques to overcome these obstacles.

The concerns of the group generally spoke to three distinct problems:

•Failure to adequately define a product before initiating the design process.
•A lack of resources to do the job in the desired time.
•A corporate culture and leadership that were not supportive of the new product development process.
What follows is an exposé of these issues and some practical insights into techniques that have worked in helping break the product development logjam. We've also included some advice on what doesn't work.

Improving Product Definition

From this workshop group's point of view, product definition falls into two distinct steps. The first is the gathering and documenting of the requirements. The group expressed frustration that, in general, they are often insufficiently informed to their potential end-users' needs and wants. When data are presented to them, they are ambiguous, badly organized, poorly communicated, or all three. The second step of product definition concerns gathering user feedback once the product development process has begun. The group said they believe customer feedback is not done often enough, and, when it is done, it lacks consistency and is poorly communicated back to the project team.

These types of issues can result in a product that seriously fails to address its market, or a process that wastes resources and time (see Figure 1). The group had some positive ideas about how to rectify these problems.

Spend Time with Your End-User. Although large-scale market research surveys collect plenty of data, they don't fulfill a very important need—to directly connect the project team to the user and the environment in which the user works. To that end, the technical personnel who design a product should be part of the team who observes the user environment and discusses product ideas with real users in informal interviews. By doing so, the technical team will not only be better informed, but more motivated to solve the problems that have now become “personalized.” Designers who visit end-users in the clinical environment can also bring back vital photos, sound bites, and samples to enrich the explanations in the specification documents that are passed to upper management for sign-off. 

Workshop participants noted that the further down the organizational hierarchy this market connection is pushed, the more successful the final products seem to be. Of course, not all product definition should be left to the “techies,” but it helps product development when they play a role and meet their future customers. Just beware of the “one-dog” clinical study problem, where generalizations are made as a result of feedback from very few end-users. Make sure that a good representative sample of potential customers is surveyed. Integrating the results of a larger-scale marketing-driven quantitative survey with a few site visits by technical personnel can be a powerful combination.

Watch Out for Unwieldy Customer Requirements 

Documents. It is unlikely that customers will consider every product feature before making a buying decision. What will be your product's big selling points? Define them early, then check with the market by showing customers simple mock-ups or cartoon storyboards. Conference participants suggested prioritizing features into simple classifications, such as “must have,” “nice to have,” and “acceptable.”

As the project progresses, keep reminding the development team of the top customer requirements, and use them to judge the product's progress. They can also be used to help judge the value of competing solutions to product development setbacks.

Product Definition during the Development Process

The key to gathering successful feedback during product development is to prototype early, appropriately, and often. Use the most suitable techniques for where you are in the project, and seek feedback as often as possible. For instance, instead of waiting until the CAD model is built, consider making an informal presentation to customers. Show them preliminary sketches, storyboards, or simple hand-made foam models. At this point, pictures and models are worth a thousand words. The workshop group supported the idea of using every trick in the book to get ideas out to customers as early as possible to validate the designs, noting that presentation techniques, such as simple animations, are now easier to create for product demonstrations. Once customer feedback is gathered, it must be presented to the whole team in a timely fashion.

How Not to Define Your Product. The workshop group recounted some war stories of what did not work for product definition. Developing the product requirements while designing the product had proved problematic, as had trying to predict customers' needs instead of asking customers what they wanted. Participants also reported that when the various subdisciplines of the project team tried to gather data in isolation of the others, poor product definition was often a consequence. And, of course, the group noted cases of “analysis paralysis”: too much data, poorly organized and presented to a large, unwieldy project team who did not have good tools for analysis. Such situations can lead to unwillingness to make the timely decisions necessary to make the product launch date. Fear of revealing ideas early was also cited as a cause of delay, as the potential users do not get a chance to nip bad ideas in the bud early in the design phase.

Managing Resources for Timeliness

If you have never heard the phrase, “We could do it if only we had more money/people/ time,” then you are not—nor have you spent time with—a manager or engineer responsible for product development. We spent a half-day with this workshop group at the conference, and, as one might predict, resourcing was brought up as a major impediment to developing new medical devices while meeting business goals.

Something's Got to Give. The three-way tug-of-war inherent in the product development world, often referred to as the “triple constraint,” takes place among the competing demands of quality, cost, and time. 

Quality also refers to scope. In our experience, discrepancies often occur in the way that management, customers, and engineers define quality for a given product. For instance, if a “nice to have” feature is dropped because of cost or deadline constraints, engineers often perceive that the product's quality has been compromised. 

Cost relates directly to the resources made available for the project in the forms of money, people, technology, materials, and outsourcing. 
Time seems always to be in short supply. Projects start too late to meet their set completion dates. The pressure can come from needing to have a product ready for an annual trade show, from the presence of a competitor lurking nearby, from a customer who requires delivery by a certain time, or from a management team whose annual bonus is at risk. The old adage “time is money” is evident when it comes to developing a product. 

Conventional wisdom claims it is always possible to meet two of the three demands but generally impossible to meet all three. And, in fact, workshop participants said, “We typically do not get enough R&D time to develop a refined product,” and “Funding resources are limited: scaling and objectives need careful clarification.” In other words, “Unless you give us more time, we cannot achieve desired quality,” and “Limited money means limited quality, or scope.” 

The group identified several resourcing solutions that have worked for their companies, as well as a few that haven't. In addition to providing these solutions, it is important to identify the assumptions that make the successful solutions viable, and those that fail, unworkable. 

Which Is Most Important: Faster, Cheaper, or Better? If you can't have all three, then which are most important? The solutions that translate into highly competitive, successful product launches are those that place time and quality at the top of the list (see Figure 2). The companies that do so recognize that being first to market means more than saving a few pennies or even tens of thousands of dollars. These are not firms that are putting inventory into their pipelines too early, or starting more projects than they have the resources to handle. Rather, they are companies that invest in the capacity required to develop and launch high-quality products fast. 

Teams behind successful product launches also understand that uncertainty and variability are inherent in a product development environment. They make sure their plans do not commit more than 70% of their capacity and that those plans utilize time buffers. 

It is wise to identify tasks and parts that are high risk and make explicit contingency plans just in case the worst scenario happens. This includes maintaining a list of on-call outside resources. Ongoing communication with these contractors helps them to anticipate what assignments may be coming and prepare to allocate the resources necessary to perform for the work.

Finally, learn from past projects. Put in place an auditing system so that resource needs can be forecast clearly and improvement projects can be targeted to those tasks, parts, and resources that are most variable or that will require the most time.

Resourcing: Taking Variability into Account. One comment made about resourcing during the workshop was this: “On paper [a resource plan often] looks fine, when in reality it's not—for instance, allocating 20% of someone's time as a resource.” Another was, “Resource allocation is good for the long term, but it doesn't mean we get things when we need them.”

These statements illustrate what happens when organizations fail to take variability into account. Developing—and attempting to control—project plans that assume infinite resources and specific start/stop times for tasks will likely result in unmet goals. The same can be said of plans started regardless of the capacity requirements placed by other projects, and plans that have not strategically provided for variability. 

Nurturing a Supportive Corporate Culture and Leadership Style

Show Me How You'll Measure Me, and Watch How I'll Behave. The effects of corporate culture and leadership style on an organization's ability to achieve successful product launches constituted the third major focus of the workshop discussion. One common perception expressed by the workshop participants is that many people resist new approaches or ideas. Another is that senior staff do not follow through on their commitments. Accountability seemed to be the word of the day. Participants tended to believe that “if only those senior staff members were held accountable, all would be well in our product development world.”

Nurturing the culture seems easy if one assumes that the organization is made up of adults who can and should be trusted and respected. Good communication and information flow are essential. And for those things, you need trust and respect. It should be noted that team members and managers need to communicate in more ways than by e-mail alone! Believe it or not, the statement at the top of the workshop participants' “doesn't work” list was “e-mail hell.”

Take Risks and Find Errors Quickly. The wise advice not to punish people for taking risks and making mistakes goes hand in hand with encouraging cross-functional team input and buy-in to the project plan. When the whole team offers input, more risks can be identified up front, more assumptions can be examined, and, quite often, alternative solutions that reduce risk can be found. These methods will work best in an environment in which all assumptions are considered challengable. 

In such an environment, real core needs are identified. For instance, a visual prototype may be acceptable for the investor review coming up in three months, but a working prototype will be needed for the trade show that's six months away. When project plans are developed, real communication should take place between the project manager and senior management regarding any trade-off issues. Free-flowing communication is preferable to the typical “I need more time or resources” requests by the project manager being countered with the typical “We don't have more time or more money, but make it happen anyway” response by senior management. 

Don't cross your fingers and anticipate lots of overtime and weekend work to make deadlines. Use the planning tools available in numerous software packages—in conjunction with the tool you've got between your ears. Share the results with the team leadership to help them juggle resource and schedule commitments. And when a project must be stopped, communication should flow to those people who have worked on it, so that they can understand the business reasons that called for pulling the plug. 

Enlist an Experienced Project Leader. The vast majority of the workshop group said that one of the most important requirements for a successful product is a single, experienced project leader. You need someone who understands the product, the customer, and the organization. This individual should know how to make things happen, smooth ruffled feathers, and see the big picture as well as the details. 

This leader must be able to drum up creative solutions and distinguish “noise” from real problems. Not only should every project have such a leader, but every leader should be actively mentoring at least one team member to take the leadership role on the next project. Companies that are aware of the importance of strong leadership and consciously nurturing potential new managers are not only better places to work—they tend to create more successful products as well.

Finally, the measures that are used to judge whether individuals and teams are doing a good job must be in alignment with the overall project plan. As an example, if project tasks are to move from one group to the next without stopping, then don't measure the groups on “task due dates,” and don't treat the task estimation process like a typical budget negotiation. Instead, measure the groups on achievements such as project success, project innovation, and development of the knowledge and skills needed by the organization.

The Common Threads of Success

It is clear, based on the feedback from this group of product developers, that team members are not alone in the typical issues they face when charged with bringing a new product to market successfully. The keys to success in product development are similar to those of the other great challenges in life, such as marriage or parenting. They are:

•Communication.
•Leadership.
•Monitoring what works and what doesn't.
•Taking risks and learning from mistakes.

Despite having about 50 years' collective project experience, one of us from a technical product design background and the other from a business-process design background, we both learned new things from this lively group of workshop participants. We expect to continue learning. Perhaps project managers should be even more conscientious about sharing their experiences—warts and all—with their peer groups. We know that the ever-changing world will never let us rest, and we'll finish this next project and then turn around and do another one—only better next time. 

Copyright ©2004 Medical Device & Diagnostic Industry