Preston Smith's Corner

Quick Tips

Preston Smith Quick Tips

March 2008 Quick Tip

Bob Becker nicely shows how a development project can be guided by one of three approaches:

  • M, where MANAGEMENT primarily makes the decisions that move the project forward,
  • P, where an established PROCESS provides the guidance, and
  • T, where TEAM members are relied on to guide progress.

Every actual project employs a blend of these, but what counts is the relative emphasis of the three. As Becker describes, each of the three has its strengths and weaknesses. Thus, our opportunity is to adjust the blend to the project’s needs.

Most companies start with a predominant M style, because the P and T styles aren’t developed yet. As the organization matures, management becomes overloaded, and project complexity grows, they move toward a P style. This overlooks the T style. The T style requires an investment in people, training, and sometimes management coaching if the M style has been predominant, but often there is no compelling motivation to develop the T style.

The T style isn’t a magic cure, but it can have strong advantages, especially for projects experiencing a great deal of change (where prescriptive P approaches don’t fit and M approaches can’t provide timely guidance). Chapter 6 of our book, Flexible Product Development, covers strong teams and guides you in developing them.

In short, M and P styles tend to develop of their own accord, but often the T style needs specific nurturing to evolve. Every project needs a blend, and certain projects can benefit greatly from a T emphasis. Have you developed your T strength so that you will have it when you need it?

(c) Copyright 2013 Preston G. Smith. All Rights Reserved.

June 2003 Quick Tip

In the last Quick Tip, we discussed how difficult it is for many people to discuss a subjective, rather negative subject like risk. If you are going to be successful in managing project risk in your organization, you must find a way to “bring risk out of the closet.” Fortunately, there is an excellent way to do this.

The solution is to paint a picture of each risk. Unlike an abstract Picasso, the picture is in a standardized format that is familiar to everyone in the organization. We call our version of the picture a risk model, but this term perhaps scares some individuals needlessly.

Regardless of what you call it, the picture should show the components of the risk in familiar locations, and the relationships between the components should be clear. There should be places to list all of the facts you know about the risk. Facts are critical, because they are the key to making a risk less threatening or subjective. Team members can discuss facts rationally, whereas they will argue about the risk itself and never reach consensus on it. Furthermore, these facts will lead you directly to effective actions that you can take to mitigate the risk.

To see how this works, including two case studies, read our article, “A Portrait of Risk.

(c) Copyright 2013 Preston G. Smith. All Rights Reserved.

March 2005 Quick Tip

Many clients place great emphasis on rapid development, both for its direct market payoff and for its beneficial side effects. For instance, speed often ties to efficiency. Consider the efficient movements of a speed skater or the clean tack of a racing yacht.

But often you have other important objectives in developing a new product, such as high reliability in a life-critical device, or tight cost constraints on a mass-market consumer item. How can you blend such objectives with speed?

Barry Boehm, in his recent book, Balancing Agility and Discipline, shows how to do this for software development, and you can adapt the technique to non-software products. See a review of this book. Boehm assesses a project’s objectives on five relatively independent axes. For instance, one axis is dynamism, which measures flux in product requirements.

Associated with this, you can ask, “How much requirements planning is best?” If you spend lots of time in detailed requirements planning when the requirements are likely to change anyway, you risk much wasted planning effort. On the other hand, if you do not plan requirements enough, you risk missing an important requirement or not understanding one well enough. Between these two extremes is a “sweet spot” where the opposing risks are acceptable. The sweet spot’s location varies by project but depends on several factors that become apparent as you assess the opposing risks.

Furthermore, exploration of the opposing risks may suggest effective management techniques that control both risks at low cost. For instance, rapid prototyping may allow robust assessment of requirements without extensive requirements planning.

(c) Copyright 2013 Preston G. Smith. All Rights Reserved.

January 2006 Quick Tip

We are slowly realizing that many of the Earth’s resources are finite, and, in the end, things must balance. This has big implications for product development, which often depends on proliferation.

According to Jacquelyn Ottman, a pioneer in the field, “‘Green’ product development, also known as design-for-environment or eco-design, is about minimizing impacts upon the environment at every stage of a product’s life, from concept, design, raw materials and production, through to distribution, marketing, use, and disposal/recycling.”

You can determine the “greenness” of a product by using a tool called life cycle assessment (LCA), which helps measure the impact of a product on the environment.

The following four design strategies will generally reduce environmental impacts:


  • Design for Recycling: Save money or new raw materials and meet customer demands for waste disposal and recycled content; even exploit a new design aesthetic by using recycled materials in designs.
  • Reduce Toxicity: Impacts to air, land, and water can affect humans and animals. Reducing them can also save money, reduce liability, improve marketability, and accelerate development by eliminating legal hurdles. For instance, Nike has eliminated PVC from its footwear.
  • Energy and Fuel Efficiency: Reduce electricity generation, the single largest source of air pollution and greenhouse gas emissions in the U.S., and protect against rising energy prices by using energy-efficient technologies. Toyota’s hybrid Prius wins in fuel efficiency while setting new standards for responsible cars.
  • Provide a Service Alternative to Physical Products: The iPod, with its downloadable tunes, replaces physical CDs; consumers do not need physical products, just the service a product provides.

For more, visit

(c) Copyright 2013 Preston G. Smith. All Rights Reserved.

September 2004 Quick Tip

Lean product development stems from lean manufacturing, which in turn, is largely a repackaging of the Toyota Production System (TPS). As many companies have adopted lean manufacturing, they have sought to make similar transformations upstream in their new products entering the factory.

Although some of lean manufacturing translates to product development, much of it can cause problems in translation. The classic in making the translation is Don Reinertsen’s Managing the Design Factory. Don succeeds by carefully selecting the techniques that do translate well and by translating them at a high level. For instance, pull systems, small batches, and queueing theory lend valuable insight to effective product development.

Other techniques can get you into trouble. The core practice of lean manufacturing, for instance, is eliminating waste. Sometimes you have to look carefully, even in the factory, to identify waste. Shingo, one of the leaders of the TPS, identified seven types of waste, such as correction, inventory, and waiting. Correction includes rework, which is undesirable in the factory.

In product development, rework also would seem to be waste. Our mantra is “do it right the first time.” However, the essence of innovation is re-trying things until they work. If you drive out rework, you will have no innovation. Consequently, the key in re-trying things is to do it efficiently and learn as much from each failure as possible, not to eliminate the failures.

Probably the most useful recent book on lean development is Poppendieck’s Lean Software Development, although you may have to translate some from software to hardware.

(c) Copyright 2013 Preston G. Smith. All Rights Reserved.

December 2005 Quick Tip

This term confuses me. Fortunately, lean development consultant Katherine Radeka of Whittier Consulting Group has brought us some clarity. She interviewed 42 experts in the lean product development community and discovered that there are five basic varieties of lean development:

  • Lean design, design for six sigma, and design for lean manufacturing, which ensure that new products are designed to fit with lean manufacturing.
  • Direct applications of lean manufacturing tools to product development, especially value stream mapping to eliminate waste and improve flow, 5S, and kaizen events.
  • Direct applications of Toyota’s product development practices, which differ fundamentally both from lean manufacturing and from conventional product development practices, especially in using A3 reports, set-based design, knowledge reuse, and chief engineers.
  • A principles-based approach, which abstracts ideas from the spectrum of lean literature and integrates them with “best” practices in product development to create a system of lean product development. This system differs radically from the product development practices of most companies today.
  • Those who re-label “best” practices in product development as “lean” because they appear to eliminate waste, thus exploiting the lean label as a marketing tool. They use the label without a deep understanding of lean principles or a systemic approach.

Radeka observed that few of those she interviewed fit completely into one category (none in the last one). The differences usually stem from differing backgrounds and experiences in manufacturing, design, or product development.

Consequently, if you suspected that “lean” hadn’t jelled in product development as it has in manufacturing, now you know why.

(c) Copyright 2013 Preston G. Smith. All Rights Reserved.

September 2007 Quick Tip

Our new book, Flexible Product Development will appear next week, so it is appropriate to ask: How does it differ from our last book, Proactive Risk Management?

Proactive Risk Management is a mainstream approach for managing the risk in a project. It is appropriate – and the best way of proceeding – when there is little change during a project, as it is a methodical process that identifies risks, understands them, then generates plans to mitigate them.

Unfortunately, product development, especially of more innovative — thus coveted — products, seldom proceeds sequentially without change. When change during development becomes the norm rather than the exception, mainstream risk management approaches are unresponsive and even wasteful.

Consequently, risk management for a flexible project takes on a fundamentally different character. Rather than being an identifiable process within the entire project management process, as it is for a well-run mainstream project, it becomes intrinsic to running the project.

By intrinsic, I mean that everything you do to execute the project is done to control the project’s risk. You proceed with short iterations to control the risk in what you are doing, and you check in with customers often to control customer risk. You run experiments continuously to ensure that you are on the right track and to develop options in case of change. You delay decisions to deal with the risk of locking into a poor choice when things might change.

In short, instead of being an identifiable process, project risk management becomes a way of life.

Quick Tip Index

Is the CEO important to flexible product development?

July 2007

A recent research report “Managing the Future: CEO Attention and Innovation Outcomes” finds that “forward-thinking CEOs are the main drivers of successful innovation” in their companies. So, specifically, how do CEOs figure in flexible development? One key ingredient of adopting flexibility is the significant changes in organizational values and behavior required. Thus, the question becomes: is the CEO a key factor in organizational change?

When writing my forthcoming book, Flexible Product Development, several months ago, I polled 35 product development experts regarding their experiences with organizational change. The one consistent response was that the CEO had to lead the transition for it to be successful. While desirable, this creates two problems. First, the person wishing to initiate change is unlikely to be the CEO, and second, my discussions with CEOs clarify for me that they, working alone, lack the time, connections, credibility, and skills needed to implement change. As Mary Lynn Manns and Linda Rising explain, “It is not top-down or bottom-up, but participative at all levels.”

Consequently, I created a multifaceted approach to organizational change. It includes the top-down approach of John Kotter as a framework, the bottom-up tools of Manns and Rising to execute the details, and the transitions perspective of William Bridges to knit the pieces together effectively. See the bottom of our Resources page for more on their books.

Better yet, order Flexible Product Development and read Chapter 10.

In short, the CEO must be on board (eventually), but don’t depend on this executive to lead the effort.

(c) Copyright 2013 Preston G. Smith. All Rights Reserved.

June 2007 Quick Tip

I regard flexible product development simply as an extension of time to market into the twenty-first century. We have learned since Developing Products in Half the Time was published that there are many ways to view development cycle time.

One view is to recognize that the product development environment has become more chaotic recently as customers change their minds more frequently, disruptive competitors appear more often, and technologies evolve faster. In other words, change is increasingly likely happen during the project. Thus, time to market doesn’t really run from the time that you start a development project but instead from the moment that you can last make changes easily. Flexible development is simply a matter of pushing the “design freeze” point later in the project without costly consequences.

One way of portraying this is to consider development as comprising two phases: a conceptual phase during which you can make changes easily and an implementation phase where you realize the concept. Design freeze occurs at the end of the conceptual phase.

If these phases are not overlapped, there is no flexibility, that is, you do not start implementing until you freeze the design. To the extent that your process is flexible, you can start implementing before you freeze the design, that is, you can overlap these phases. In this case, time to market can be considered to run from the end of the first phase to the end of the second one. The more overlap you can tolerate without undue consequences the shorter is your time to market— and the greater is your flexibility.

(c) Copyright 2013 Preston G. Smith. All Rights Reserved.

October 1999 Quick Tip

There are two critical factors to keep in mind in managing risk:
– Risk must be managed proactively.
– Risk management must extend outside of engineering.

Proactive risk management is especially crucial when time to market is important. By starting early and addressing risk in an ongoing manner, you basically push the surprises earlier in the project, where they are less damaging to the schedule. Earlier awareness of risk issues provides you with more time to deal with them, which is essential as you shrink your schedules. Finally, because risk remedies get scarcer and more expensive as you get locked into prior project decisions, early risk resolution provides a richer, cheaper set of solutions.

Risk management is normally thought of as a technical issue. Engineers have many tools for dealing with risk. Unfortunately, this is the least lucrative place to look for risks. Numerous studies of product development failures show that most of these failures stem from market and business risks, not technical ones. When we assign risk management to the engineers, we are ignoring the majority of the issue.

In keeping with the proactive and cross-functional nature of risk, there are many ways of identifying and tracking project risks. Some examples appear in a recent article, “Managing Risk As Product Development Schedules Shrink.”

When project risk is treated proactively and cross-functionally, it becomes a central means of managing the whole project. It naturally becomes the basis of phase review discussions, and it takes on a project role no less than the project’s budget or schedule.

(c) Copyright 2013 Preston G. Smith. All Rights Reserved.

October 2008 Quick Tip

As realtors are fond of saying about buying houses, there are three important factors to consider in improving how you develop new products: people, people, and people. But how quickly we forget this and put our energy instead into processes, approaches, and tools. Chapter 6 (page 126) of Flexible Product Development has a chart showing that people are about ten times more important than processes (see this chart in “Change: Embrace It, Don’t Deny It”) published in Research Technology Management, July-August 2008, (Vol 51, Issue No. 4), pgs 34-40).

One reason that people are paramount is that experienced, motivated people tend to fix anything else that gets in their way, such as a process bottleneck or an organizational reporting problem.

People includes connections between people, that is, teams. You can do plenty to improve teams, but in fact, we have mostly moved backwards on teams over the past couple of decades. One area we have weakened is in failing to dedicate a person to one project. Dedication provides a host of benefits, one of which is accountability (if you are assigned to multiple projects, you can always claim that you were working on another one when asked what you accomplished on a certain one).

Another powerful team characteristic that we have slipped away from as we globalize is co-location. In the Flexible Product Development book (pages 141-150) I provide three types of 21st century support for co-location and show how you can derive great benefit from co-locating partially when complete co-location is impractical.

For more on this topic, see our recent article, “Effective Development Begins and Ends with People” in Cutter Consortium’s Agile Product & Project Management Advisory Service.

Quick Tip Index

(c) Copyright 2013 Preston G. Smith. All Rights Reserved.

June 2004 Quick Tip

I see two trends – and they are on a collision course.

The first one stems from the relentless pressure to cut costs and from management’s inherent desire for predictability. It leads to our award-winning risk management technique and to popular phased-development processes, such as stages-and-gates or product lifecycle management, that control investments carefully.

The opposing trend recognizes that innovation is essentially unpredictable and that excessive control is an unlikely route to breakthrough products. Add to this the fact that our world is becoming more chaotic: lead engineers quit, management changes, suppliers go bankrupt, new technologies exhibit unexpected side effects, customers change their minds, and a competitors launch products that exceed the ones we have under development.

Rather than an emphasis on controlling development, managers following this trend instead find ways to deal with change more cheaply and less disruptively. They enhance their organization’s agility by

  • Obtaining direct customer input early and often – and use it to guide their designing
  • Applying technology to automate design and testing (automating change, so to speak)
  • Carefully deferring, staggering, and avoiding decisions that close doors
  • Employing small, empowered teams
  • Failing early – and learning from these failures

To learn more about leading the flexible organization,  read Stefan Thomke’s book, Experimentation Matters.

(c) Copyright 2013 Preston G. Smith. All Rights Reserved.

April 2001 Quick Tip

You may recall that a few months ago a Quick Tip suggested where you could read about the latest product development advances in print media: “Where can I read about new product development techniques?

As part of that research, we discovered that many developers were instead getting their information straight from the Internet, so we partnered with Management Roundtable,, to discover how product developers use the Internet. Ironically, one discovery from the 6112 developers polled was that the Internet doesn’t seem to be as popular as the hype would suggest: the response rate for this survey was only 3.2%, compared with 21% for the print media survey!

We thank those of you who responded to this survey.

We found that online sources differ, depending on the objective. When seeking answers to a specific question, the three top tools, in order of popularity, are search engines, specific Websites, and corporate libraries/intranets. But if they instead want to keep up to date regularly, developers turn to e-mail newsletters, online publications, and corporate libraries/intranets.

The top search engine by far is the Google/Yahoo pair; followed by AltaVista; then, at a distance, Excite, Northern Light, and Dogpile.

Corporate online libraries and intranets are especially popular among large, well-established companies, but we found that they (probably unknowingly) discourage developer’s access to challenging, alternative means for developing new products or understanding competitors.

For details see our article with hyperlinks to leading sources or a version having additional context.

(c) Copyright 2013 Preston G. Smith. All Rights Reserved.

January 2000 Quick Tip

No better topic for starting a new year. Several years ago, I gave the following answer to a Silicon Valley CFO who asked this question, and my response remains the same:

This last point is the essence of leadership — as contrasted with management. Leaders recognize that the individuals and teams doing the work have better, more timely information to make decisions than they do, so they view their role as enabling rather than controlling progress.

Thus, under a true leadership environment, responsibility for success shifts back from the boss to the individual. In seminars I lead, participants often say, “I wish my manager were here to hear this.” There is certainly some truth here, but the most powerful thing most managers can do is to lead their organizations out of the Dilbert mentality.

For more on management’s role in general, see our article “Faster To Market” on the subject.

(c) Copyright 2013 Preston G. Smith. All Rights Reserved.

April 2007 Quick Tip

The other day I read a funeral announcement for best practices. This is sad. I hadn’t seen best practices around much lately and wondered if they were feeling ill. I guess they passed quietly.

Best practices came from a bygone era of benchmarking and business process reengineering, of pioneers searching for a promised land where there is One Best Way to develop a product.

Today we view the world as being more complex. What is best probably differs from time to time. Each project has its own unique needs, so it needs a unique blend of approaches suited to it. Boehm and Turner in their book Balancing Agility and Discipline: A Guide for the Perplexed (see page 4) show us how to create these blends.

Of course, if you wish to move beyond the era of the One Best Way, your process will need regular monitoring as you adapt it to new situations. Here again, we have made great progress since the Stone Age when processes were chiseled on tablets. Today we’ve moved beyond postmortems to retrospectives, where Derby and Larsen in their book Agile Retrospectives: Making Good Teams Great show us how to improve processes as we go rather than waiting until the project is all over, thus too late to improve anything.

You may have noticed that all three links above point to software development sources. Many of these techniques can be re-interpreted for other kinds of products, which is the topic of my forthcoming book, Flexible Product Development.

(c) Copyright 2013 Preston G. Smith. All Rights Reserved.

January 2003 Quick Tip

If you have read our book, Developing Products in Half the Time, you will recognize that we strongly advocate physically locating cross-functional team members close together (within 10 meters of each other), which greatly improves the speed and accuracy of the voluminous cross-functional communication needed to develop a winning product.

Unfortunately, in today’s fragmented world, true co-location is increasingly difficult to implement. Electronic tools, such as e-mail and Internet conferencing have attempted to fill the gap, but they fall far short of the richness of real face-to-face conversation.

The trick to dealing with this reality is to recognize that even partial co-location pays large dividends. If you can’t totally co-locate your team, consider:

  • Co-locating your team for only part of the project (which should be the initial period – the first two hours or the first two months of the project)
  • Identifying the most critical communication partners, such as the lead design engineer and the marketing representative, and co-locating them
  • Co-locating all team members in each city in a single small room so that your team is at least clustered
  • Reconvening the team in a single location periodically to rebuild relationships and deal with particularly difficult, abstract, or political issues

For more help on overcoming the difficulties of “virtual” teams, see our article on dispersed teams.

(c) Copyright 2013 Preston G. Smith. All Rights Reserved.

December 2000 Quick Tip

This is more difficult than it sounds, as product development spans several disciplines and many industries. But I wanted to know the answer to this question too, so I asked the 1000+ readers of these Quick Tips what they read that helps them to improve their product development practices. Thanks to all who responded, here is the top ten list of what you read (with the number of mentions of each):

Harvard Business Review (52)
Journal of Product Innovation Management (27)
Machine Design (24)
Design News (22)
Wall Street Journal (19)
Project Management Journal (17)
Fast Company (16)
Business Week (14)
Mechanical Engineering (14)
Research-Technology Management (13)

Just as interesting, many readers responded by saying that when they want to learn about product development practices, they don’t turn to magazines or journals at all. Instead, they would conduct an online search. Some sources of online product development help are in this article. Perhaps we should conduct a survey of Quick Tip readers to discover other such sites.

For greater detail, see our periodicals survey.

(c) Copyright 2013 Preston G. Smith. All Rights Reserved.

July 2004 Quick Tip

Your first step should be to determine what flavor of time to market you need. Faster product development seems to be a straightforward concept, but there are some important distinctions to make. Here are some of the possibilities:

1. Launch the product as soon as possible
2. Minimize variations in launch time
3. Minimize rework and wasted effort
4. Minimize development expense
5. Agility (ability to make late changes easily)

Raw speed (number 1) is important in some fast-moving industries, such as fashions and consumer electronics. Minimizing variation (number 2) is more critical for seasonal products or those launched through trade shows. Minimizing waste seems to be the unspoken objective behind some approaches to accelerated development, such as stages-and-gates. Due to increasing uncertainty in markets, supply chains, and technologies, agility is increasingly important for many companies.

Understanding your objective is the first step because the tools you use to reduce “time to market” – as well as the results you obtain – will depend on your objective. For instance, high-performance project teams are effective for objective number 1, project risk management aims at objective number 2, strong phase reviews fit with number 3, functional and matrix organizations align with number 4, and front-loaded experimentation matches number 5.

Unless you select tools that fit your objective, you will not achieve the results you desire.

For help in making these choices, calculate your project economics (see Chapter 2 of Developing Products in Half the Time) or read our article, “Developing Your Products in Half the Time.”

(c) Copyright 2013 Preston G. Smith. All Rights Reserved.

January 2002 Quick Tip

Fire fighting is usually a result of dealing with project uncertainty reactively, rather than working proactively to resolve project surprises before they happen.

As companies have adopted formal product development processes, they have started listing project risks explicitly in the initial phase of the project. Curiously, however, this list of risks is often considered as a “deliverable” in itself, and the vital work of developing and monitoring action plans to resolve the risks never happens, due to the push to get on with the “real” work of the project.

We have just finished writing a new book, “Proactive Risk Management: Controlling Uncertainty in Product Development.” A panel of nearly 50 reviewers chose the chapters they wanted to review. Interestingly, one of the most popular chapters was the one on identifying project risks, and least popular were the ones on planning and executing action plans! No wonder we keep having last-minute surprises in projects!

And no wonder that we have no time to work on resolving risks — we are too busy fighting fires! The objective of effective project risk management is to identify and deal with risks before they happen, precluding the fire fighting. From this viewpoint, project management is risk management.

(c) Copyright 2013 Preston G. Smith. All Rights Reserved.

March 1999 Quick Tip

Under pressure to be competitive, management often assigns its best product developers to multiple projects. This destroys time to market in several ways.

First, it causes direct dilution of project effort. If a developer is given two projects and could be working full time effectively on either of them, then each will take twice as long to complete — an immediate doubling of cycle time.

Then there is a loss of efficiency in shuffling multiple projects. This is illustrated in two charts on our Web site, which show that if time to market is important, even two projects per engineer is counterproductive.

Beyond these quantifiable effects, several others can be just as important. One is a loss of accountability. When individuals are assigned to multiple projects, control over which project they are working on at the moment essentially shifts from management to the individual, based on any pressures the individual happens to feel. When people are working on too many projects, it becomes unrealistic to hold them accountable for due dates on any of them.

Multiple projects also contribute to lack of focus and commitment on specific projects, and they undermine project communication. Beyond this, fragmented effort on multiple projects makes it virtually impossible to apply two of the most powerful tools of rapid product development: co-location and proactive behavior, which keeps tasks from appearing on the critical path later.

In the next Quick Tip we will explore some solutions.

(c) Copyright 2013 Preston G. Smith. All Rights Reserved.

July 2008 Quick Tip

In the last Quick Tip Isn’t the iteration that accompanies flexible product development wasteful?” I emphasized the power of iterating: placing a “first try” of your product into customers’ hands quickly and adjusting from there. As usual, there were some astute observations to this advice. One respondent said, “You need to be very smart in order to realize when you have done something wrong.”

Such feedback usually is not obvious. It is subtle, so you must be open to it and watching for it. There is a great tendency among product developers to believe that they are the world experts on their products (in a certain sense they are!), and this blinds them to conflicting information. They say, “The customer wouldn’t possibly want to do this. I never do it.” Being the expert often gets in the way of listening. “Amateur” customers don’t use products in the same way that experts do.

In short, if you are going to use the powerful technique of iterating with customers to develop products that will truly appeal to them, you must also develop ways of being open to what they are telling you.

New subject: I receive many questions about flexible product development: what is it and where does it apply? A recent article, “Change: Embrace It, Don’t Deny It,” explaining flexibility concisely, is now available for download.

(c) Copyright 2013 Preston G. Smith. All Rights Reserved.

Learn about our other services

For more information, contact:

Mary Drotar, Partner

Strategy 2 Market, Inc.


or complete this contact form

Note: As this is an archive of Preston’s New Products Dynamics Website, some off-site links may no longer exist.

Scroll to Top