Preston Smith's Corner

Quick Tips

Preston Smith Quick Tips

April 2003 Quick Tip

Let’s admit it: discussing what might potentially go wrong with your project is difficult for a few reasons. First, it is an unpleasant subject about things we would rather not think about. Second, it suggests that you cannot handle these things yourself. And third, your boss probably has many actual problems to deal with now, so discussing potential ones seems like a luxury.

Risk is an unpleasant subject. But it is your job to identify what might go wrong with the product you are developing – perhaps someone might get hurt using it or a key supplier might go out of business, for example. And it is your job as a manager to do something about such problems.

By discussing risk, you aren’t saying that you can’t handle it. Quite the opposite, you are saying that you are very much aware of it, and you know just what you will do about it when the time comes.

As for your boss, his or her concentration on present problems is a self-fulfilling prophesy: tomorrow’s potential problems will become actual problems tomorrow, and they will be much more expensive to deal with then. This is the essence of firefighting.

The key to managing project risks well is to list the facts influencing the risk and then manage these facts rather than managing the risk itself. To the extent that you keep your discussion at the facts level, it will be much easier to communicate with management.

For more on this topic, see our article “The Risk of Talking About Risk.”

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

October 2003 Quick Tip

The last person you should ask regarding this question, according to Harvard Business School professor Alan MacCormack, is your boss. MacCormack’s research paired a “good” and a “bad” project from the same company, as chosen by executives of that company. Quite surprisingly, he found that the “bad” project was a marketplace success, while the “good” one wasn’t.

Further investigation showed that managers rated a project highly when it had a product specification up front that remained stable, and they delivered a product that satisfied the original spec. In a “bad” one, the final product looked completely different than the original spec.

The strongest indicator of the marketplace successes (the “bad” projects) was that the team placed a working version of the product in customer’s hands very early and used customer feedback to revise product direction and features accordingly. These folks knew they didn’t have all the answers, so they used early releases and customer reactions to set the direction, in contrast to setting an inflexible direction at the outset.

MacCormack also discovered some other elements of flexibility. The teams that designed the marketplace successes found ways to react quickly to market feedback, and they chose product architectures that allowed changes to be made easily rather than using the lowest-cost architecture.

MacCormack’s research focused on Internet software projects, where market uncertainty is high, so his findings may not be as applicable to established products. However, he provides a sobering reminder that it isn’t so bad to listen to customers and redirect your project accordingly.

Announcement: this Quick Tip completes five years of publication (40 issues) of this series.

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

December 2001 Quick Tip

Many product development teams waste both time and labor repeatedly revisiting their decisions. Are your team decisions determined by the loudest or most eloquent speaker? Does management overturn your decisions because they lack a solid foundation of logic or facts?

Cross-functional team decisions are at the very core of the product development process. If you dissect a project, you will find decisions – many of them cross-functional ones – in the “inner loop” of the process. You will make thousands of these decisions to complete your project. It follows that if you can accelerate or improve decision-making, you will be repaid a thousand fold.

The value of speed in making decisions is obvious, but what distinguishes a “good” decision? A good decision is tough; it is robust. It is resistant to being overturned, because it is built on solid facts that team members agree on.

Fortunately, there is a pragmatic theory of robust decision-making. It centers on the fact that each person’s contribution to a decision has two dimensions, his/her certainty about how well a particular solution performs and knowledge about the performance. If a person expresses great certainly but has no knowledge, they are likely to be wrong, no matter how convincingly they argue.

Robust decisions not only save time. They also strengthen the team and improve its morale. Who wants to be on a team that the boss is always overruling? A robust decision will stand up to the boss’ scrutiny, because it is the best one that can be made under the circumstances.

To explore robust decision-making further, visit (naturally) https://www.robustdecisions.com.

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

March 2003 Quick Tip

This is an insightful question, because if you dissect the product development process, you will find that decisions are at its core, and accelerating them will speed up your whole process greatly.

Decisions in the fuzzy front end of development have major downstream ramifications, so various parties — engineering, marketing, suppliers, and executives — think about them carefully. These decisions often involve alternative product concepts or variations in a concept.

What better way is there to communicate a concept or its possible variations than to build a prototype of it? Prototypes bring realism to something that doesn’t exist yet. Unlike engineering drawings, everyone can “read” them. Well-positioned prototypes bring closure to concept decisions.

However, to accelerate fuzzy-front-end decision-making, you must build a sequence of prototypes that parallel the decision-making sequence. This means that you must build a sequence of simple prototypes, each of which resolves only one question. The biggest mistake that prototypers make is in building prototypes that are too complex, too late in the process, and too final. Too complex means that multiple decisions become intertwined, too late means that people become wedded to a concept, and too final means that these highly refined prototypes are time-consuming and expensive to make.

Various prototyping technologies can model products that exist as software, digital circuits, analog circuits, or paper documents, but probably the most interesting prototypes model mechanical objects. Such prototypes now cost US$10-20, enabling you to afford the dozens needed for fast, precise decision-making.

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

May 2005 Quick Tip

Conventional project risk management, as described in our book, Proactive Risk Management, can be time-consuming, especially for fast-moving projects. We recently faced this problem in an agile software development project, which had to produce a new, working version of the software every month. With 30 days to deliver a product, you can’t afford to take days to pass through the conventional risk management process – it must be done in an hour or two.

You can accelerate the process by greatly simplifying the risk analysis and prioritization steps. Rather than filling in the complete risk model and prioritizing your risks quantitatively, as the conventional process requires, simply have the team prioritize the risks using their perception of which risks are most serious. Then you can plan actions against your most serious risks.

Although such a radical shortcut would be dangerous for most projects, it works for an agile project because it exploits three characteristics of such projects:

  • Short (one month) iteration cycles, which makes forecasting risks much easier over such short periods
  • Frequent (monthly) opportunities for reassessment, which minimizes the effect of any errors in perception
  • A close-knit, co-located team, which has intimate knowledge of the project and thus is in a strong position to appreciate its risks

You can learn more about this technique by reading our recent article, “Agile Risks/Agile Rewards.”

Can you find similar characteristics of your projects that you can exploit to accelerate managing their risks?

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

July 2000 Quick Tip

Too many engineers have been warned by their marketing counterparts to avoid “technology push.” Consequently, they are reluctant to mention using new technology at all. This is dangerous today, because many new technologies can greatly improve products or their associated processes, such as manufacturing or field service. Failing to apply technology appropriately can leave your firm open to fast, young competitors.

On the other hand, new technology does get applied before it is ready, it appears in applications for which customers have indicated no interest, and it can add cost, development cycle time, and complications without adding commensurate value.

Two popular books, Crossing the Chasm and The Innovator’s Dilemma, address such difficulties in dealing with technology. However, to me, they are rather theoretical and lack practical how-to information. A book that is more useful for managing technology on a daily basis is F. Michael Hruby’s TechnoLeverage.

TechnoLeverage shows through examples how to apply technology to new products in both mature and brand new markets. In fact, the book’s strength is in showing how competition differs in mature and new markets, and how technology must be managed differently as a market evolves from exotic to commodity.

To pursue this topic, see our review of TechnoLeverage.

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

April 2004 Quick Tip

Creativity is a highly admired trait. Most organizations wish they had more or higher-quality ideas for truly new products. Although you can learn and manage creativity, few managers are willing to invest what it takes to raise their level of creativity.

Unfortunately, there are many obstacles to creativity in today’s workplace. The biggest is perhaps simply the time available to create. High-quality ideas take time to ferment; the best ones are seldom the first that come to mind, and pushing beyond the initial outflow is not natural.

Motivation for high-quality ideas must be intrinsic. Paying bonuses for ideas fosters me-too excursions, not risky, breakthrough concepts.

The performance and metrics orientation of “best-in-class” companies encourages sticking to one’s knitting rather than venturing into the unmeasured. I have seen several small, entrepreneurial organizations acquired by larger command-and-control organizations that then squelched the very creativity they purchased.

Luckily, you can overcome most of these obstacles with attention once you recognize them, and there are ways to stimulate organizational creativity. See our review of the book, Creativity, Inc for details.

If you plan to apply your creativity to new-product ideas, keep one other point in mind. Most organizations already have more new-product ideas than they can squeeze through their funnel. If you stimulate creativity without making other changes, this problem will become worse. You want higher-quality ideas, not more ideas. Along with enhanced ideation, develop more efficient front-end filtering mechanisms so that you can eliminate the weaker ideas earlier and faster.

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

December 2004 Quick Tip

This frequent complaint is a symptom of weak cross-functional team interaction.

Several years ago, product development managers recognized this weakness and instituted new organizational forms, such as a vice president of product development or core teams, and team training to improve interaction between departments. Unfortunately, these improvements often have reverted to the former silos, and globalization has exacerbated the deterioration.

Although development managers have put effective teams behind them as “conquered land,” when I lead training sessions in time-to-market, the item that consistently comes to the top of participants lists as an opportunity for improvement is better cross-functional teamwork. That is, the product developers see an opportunity here that is not apparent to their bosses.

What can you do? I’ve found that different opportunities exist for each organization, and thus the best solution works out differently in each case. There are no universal answers.

Consequently, I suggest that you look at some of the current team literature and search for approaches that will help you overcome your current obstructions.Here are some leads:

  • Our recent handbook chapter on Concurrent-Product-Development-Teams
  • A book and some articles by Christopher Avery, who emphasizes the individual skills required for good teamwork: https://www.christopheravery.com
  • If you are especially interested in the disruption that marketing initiates with product requirements changes, consider how some of the agile software development methodologies, such as Scrum and Extreme Programming, overcome this: agilealliance.org

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

July 2002 Quick Tip

Over the past several years, many companies have moved to a formal, documented product development process. However, this just leads to the next issue: How do we get teams to follow our process? I’ll list six important factors, leading up to the most important ones at the end.

6. Draw an attractive diagram of the process. Engage an artist to help you and use color. Your diagram shouldn’t look like an engineering flow chart. Test: does a top executive have it on his or her wall and use it to explain your development process to visitors?

5. Create a glossary explaining your terminology. What does an “engineering prototype” have to do? How complete does “voice of the customer” data need to be? What is a “field trial” supposed to demonstrate?

4. Train teams in using the process. Instead of just walking through the steps, resolve why the process is needed and how much work is involved — the real questions in the backs of their minds.

3. Train management too. If management doesn’t understand the process and ask developers questions consistent with it, your process will eventually wither.

2. Plan to continually improve the process. Simplify and clarify. This demonstrates that you are serious about making it work.

1. (Most important) Have everyone participate in developing the process so that they understand it and own it. Expose it to real developers as you create it. Prototype parts of it on real projects as you formulate it.

For more on product development processes, see our article Stage Gate® Process Versus Time to Market.

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

August 2005 Quick Tip

Recall that the last Quick Tip “How is flexibility beneficial in developing new products?” explained the benefits of flexible product development. Now I mention some techniques you can apply to make your product development more flexible.

One, making decisions at the last responsible moment, was covered in an earlier Quick Tip “My boss frequently stalls on decisions. Is this fast time to market?

Another is timeboxing. Because the plan is in flux in a flexible project, measuring progress relative to an overall plan doesn’t work. Instead, carve out small, measurable chunks of work and put each one in a “timebox” of time and resources. Then measure each of these tasks relative to its timebox – it counts only when it is finished. This technique is also valuable for controlling scope creep.

One more approach to planning a flexible project is rolling-wave project planning. Recognize that the long-range plan will change, so complete it only at a general level. At the start of each facet of the project, do your detailed planning only for that facet, and then plan the next facet or two moderately, leaving everything after this at the general level. When you start on the next facet, plan it in detail, and perhaps do another step of moderate planning. Thus, the wave rolls on and you haven’t wasted time planning something that will change anyway.

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

October 2001 Quick Tip

The tragic events on 11 September 2001 prompted changes for all of us. Beyond the enormous human toll, many businesses faced a new and different world. In many cases, the products and services they offered no longer fit the new circumstances. They needed to make changes – quickly.

To me, the prime benefit of a rapid development capability is this agility to make changes in product offerings quickly. This is not the majority view. When time to market was a hot topic nearly a decade ago, most managers believed that it was something they should apply to every one of their projects.

Instead, we advised that rapid development was a kit of tools – a capability if you will – that should be applied selectively only when the economics of the project at hand demanded it. Few managers have appreciated the latent benefit in being able to move quickly if their market demanded it. Today, many wish that they had cultivated such agility.

Many companies have pursued a Web-enabled, do-it-right-the-first-time, stages-and-gates development process that is efficient in stable times. But such processes often have baggage built into them that channels every project through the process in the same predictable way. They lack the agility to put certain projects in the fast lane.

Many of the publications on this Website will help you build agility into your process. To learn more about the limitations of gated processes, read our last Quick Tip “Should we be using a stages-and-gates product development process?“. For more on the fallacy of do-it-right-the-first-time, see our PDBPR column.

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

June 2000 Quick Tip

Rapid prototyping has arisen over the past fifteen years. It allows product developers to make physical parts from designs in hours, in contrast to the weeks required by traditional machining methods. Most of those doing rapid prototyping focus on making parts still faster or on making better parts. For instance, they strive to make parts that are stronger, cheaper, or more environmentally friendly.

Amazingly, few companies are taking full advantage of the latent timesavings in rapid prototyping. Yes, they do make models faster, and this saves them some time overall. But they have not redesigned their development processes to reap major gains. To use an analogy, they now use cellular phones — but only from their offices — as this is where they have always done their phoning.

This topic is timely, because the newest generation of rapid prototypers, variously called desktop modelers, conceptual modelers, or 3D printers, offer great potential for overcoming major development delays. These rapid prototyping systems are especially valuable in the fuzzy front end of development (for details on the fuzzy front end, see Chapter 3 of Developing Products in Half the Time.

For example, large fuzzy-front-end delays often stem from obtaining approval from marketing or sales for a concept that engineering has developed. Lots of quick models are perfect for “forcing” a decision at this point, which often saves weeks or months from normal corporate decision-making cycles. Few companies recognize this opportunity; still fewer are doing anything about it.

To pursue this topic, see our article “Rapid Prototyping Accelerates the Design Process.”

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

October 2005 Quick Tip

The world is undergoing some enormous changes, and you are likely to be either a victim or a beneficiary of them. For example, some people in the United States worry about job losses due to outsourcing (for example, see the book, Outsourcing America. However, job losses are a far larger threat to some developing countries, which can ill afford them.

But, being product developers, these displacements also create great opportunities for those who watch trends and think creatively – and globally! For example, Paul Laudicina, in his recent book, World-Out-Of-Balance, illustrates how General Electric spotted trends in world water shortages and air pollution and turned them into profitable, growing new businesses.

Laudicina describes three areas that will affect product developers: global market shifts, closing some markets and opening others; changes in how consumers evaluate, use, and dispose of products; and demographic, environmental, and regulatory changes in how we will be able to develop products. These changes stem from five broad factors: globalization, demographics, consumers, natural resources and the environment, and regulation and the environment.

What to do? I suggest that we start thinking out of the box – or, in this case, way beyond the 12-mile limit from our shores. I was amazed today at how insular my thinking was when I looked at the list of product developers to whom I’m sending this Quick Tip – from a nominally American firm. The ten most numerous names on the list are, in order: Chan, Wong, Lee, Smith, Wang, Tan, Johnson, Zhang, Cheung, and Li!

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

June 1999 Quick Tip

Many managers chase the “best practices” that helped someone else months ago. Why not find your own?

Start by identifying gaps between what you are doing now and what you think might be possible, based on what you read, the conferences you attend, or just your gut feeling. Don’t judge these gaps yet, but create a second list of the things your organization should be doing differently, based on either your gaps list or – again – your own intuition. Lastly, build a third list (the hardest one) of what you, personally can do in the next thirty days to initiate improvement in apparent areas.

Now map these three lists onto a cost-benefit map (See such a map). Interpret cost on this map broadly, including not only procurement cost, but also training, and even any required cultural change.

The low-cost, high-benefit quadrant on this cost-benefit map I call the No-Brainers. Because we all have brains, these easy opportunities were probably exploited long ago.

Your third list will generally map into the low-cost, low-benefit quadrant, called the Quick Hits. These are like the kindling that is essential to get a campfire started.

The high-cost, high-benefit quadrant is your Investments area, which is analogous to the logs on the campfire – lots of staying power, but in need of the kindling to ignite them. The items on your second list often map here.

Finally, the high-cost, low-benefit quadrant is the “No Way” one. Your first list (gaps) is likely to land here. However, don’t discard these sleepers. Often, they have great potential value. Once you see their potential, these may migrate to your Investments quadrant.

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

October 2000 Quick Tip

Product developers have learned over the past decade that they should listen to the “voice of the customer” as they design their products. But this just begs the more difficult question: “How do I ‘hear’ this ‘voice’?”

The good news is that we all have the voice of a customer inside of us, based on our life experiences over the years. In computer lingo, we come with a “default” voice “installed” inside of us.

The not-so-good news is that this default customer can be highly untypical, so it is a dangerous design reference. Alan Cooper, in his book, The Inmates Are Running the Asylum, explains why so many computer products are maddening to use. (See our column: Are Your Inmates Out of Touch? Many computer and software products are designed by engineers living in Silicon Valley, which is a highly atypical place. Everywhere you turn in Silicon Valley, you run into engineers, so the engineers who work there soon think that all customers are as capable of using their product as the people they encounter every day.

To design products for typical users and customers, take some time and effort to get out into their world. The best ways of doing this are creative and highly industry specific. For instance, Black & Decker sends their designers out with service technicians in vans that visit construction sites and do-it-yourself stores. Hewlett-Packard stations them in shopping malls to watch customers fumble with HP products. This isn’t hard to do, but you have to make the effort to identify typical customers and then take the time to “hear” them regularly.

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

September 2008 Quick Tip

Let’s start with the easier (and often more common) situation where there is little change during a project. This is the situation tacitly assumed in the project management literature, and it is the one covered by our book, Proactive Risk Management. In this case, you have a project plan that is relatively stable, and from it you can build, in a methodical way, a risk management plan. Proactive Risk Management shows you how to do this, as do other books on project risk management.

When your project is subject to constant change, you lack a stable project plan for building your risk management plan. However, managing risk becomes even more important in this volatile environment. This calls for a radical change in risk management strategy.

I call the more stable situation integrated risk management: risk management is integrated into the project planning, and each significant risk becomes just one more task in the project. When change is the norm, you must shift to intrinsic risk management, which means that everything you do to manage the project is done with the aim of managing its risk. You keep in touch with customers to manage customer-initiated changes, you use modular architectures to encapsulate design changes, and you conduct lots of experiments to understand the ramifications of changes. These topics happen to be chapters 2-4 of my book, Flexible Product Development, and, in fact, the whole book is about intrinsically managing risk in a changing environment.

For more on this, see a recent article, “Managing Project Risks When Change is the Norm.”

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

March 2002 Quick Tip

One reason why teams manage their project’s risks poorly is that they simply cannot agree on the risks their project faces. Each person has his or her own notion of the project’s most serious risk, based on personal experience or stake in the project.

The “secret” to taking risks out of the realm of opinions is to base each project risk solidly on the facts that support it; we call these facts “drivers” of the risk. If you fail to work with risks based on their facts, you will never reach agreement on the risks that you may identify, and you will be unable to take concerted action against them.

Fact-based risk management requires two disciplines. One is to simply require facts to support alleged risks, and the other is a framework on which to “hang” these facts.

Drivers (facts) are essential ingredients of an effective risk management process. They allow you to

  • Quantify a risk, so you can determine how serious it is
  • Prioritize your project’s risks, enabling you to focus on serious ones
  • Formulate effective plans for resolving your project’s risks

A model of a risk provides an exceedingly useful framework for working with these drivers. A model shows you which drivers influence which parts of the risk, clarifying your options for resolving the risk and enabling you to monitor risk resolution progress.

We cover this subject in depth in our forthcoming book, Proactive Risk Management. (May 2002) In the meantime, see our online articles, “Just the Facts, Ma’am” and “Using a Risk Model to Build Development Team Consensus.”

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

July 2005 Quick Tip

Product developers are being squeezed from many directions: lower-cost products, lower headcount, higher quality, more product features, and faster to market. With all this pressure, another important factor has gone relatively unnoticed – except in software development: flexibility. Flexibility is the ability to make changes in the product’s design, marketing, sourcing, or other factors relatively late in development without being too disruptive.

Flexibility is becoming important for the same root reason that the other factors – time, cost, etc. – are important: the world in which we live is becoming more competitive and chaotic. Changes are occurring faster than they did formerly. With quick changes, there is greater value in being able to react quickly but smoothly. Research shows that the companies that can react to customer requirement changes, evolving technologies, market shifts, political and regulatory turbulence, and management shuffles are the ones that win in the end.

However, this isn’t easy. Management techniques generally place value in stability, for instance in finalizing product requirements before starting design. Resource planning systems, six sigma programs, and most metrics approaches emphasize a plan-your-work then work-your-plan style. Consequently, managers unwittingly work toward stability at the expense of flexibility.

You can enhance flexibility in several ways: teamwork, product architecture, decision-making strategies, and prototyping approaches. I will discuss these in our next Quick Tip.

For more, see our 5 March 2004 Quick Tip “What can we do to “freeze” our product’s specifications?” or plan to attend our first workshop on flexibility in Shanghai in December.

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

September 1999 Quick Tip

Many companies have spent a great deal of money to achieve rapid product development without seeing much benefit. It isn’t difficult to spend millions of dollars on CAD (computer-aided design) systems, development workstations, or rapid prototyping systems.

Interestingly, these firms have paid the price of admission, but the ongoing “dues” to really see improvement are quite cheap in financial terms. Sophisticated CAD and computer systems are often the price required to even play the game today, but since your competitors can buy these too, they aren’t enough.

The firms that I have seen really compress their time to market also invest in management tools that act to reinforce these technology tools.

What are some of these management tools? Early, ongoing customer involvement is one. Dedicated, co-located development teams is another. Still another is a product architecture that supports component and design reuse. MBWA (management by walking around) is a perfect example of one that costs nothing financially but eludes many companies. This one is a speed enhancer because it gives management fresher, more accurate information for taking action quickly than do monthly or quarterly management reviews.

As you might now suspect, these management tools have their price too. It is often paid more in organizational or behavioral change than in financial terms. For instance, co-location or MBWA are powerful accelerators, but they require individuals to change how they operate.

For more on getting benefit from what you put into improving your product development, refer to the article, ” Reaping Benefit from Speed to Market.”

To pursue process improvements as a corporate investment, see “Your Product Development Process Demands Ongoing Improvement.”

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

December 2003 Quick Tip

Modern computer technologies can accomplish wondrous things. I recently accepted a volunteer position that required keeping track of many disparate pieces of information, coordinating them, and making commitments based on them. Database technologies, unavailable just a few years ago, were the perfect match to my needs.

However, many managers who apply computerized tools to their development processes, be they computer-aided engineering tools or a complete Web-based development process, do not obtain the benefits they seek.

To obtain real business benefit, you must do two things – neither of them involving technology. First, you must analyze your current business situation and objectives before you chose a technology. Otherwise, you will be solving the problems that the technology’s developer had in mind, not necessarily your own needs. In short, analyze your needs first, then go shopping for technologies that resolve your need.

Second, once you install the technology, recognize that the hard work lies ahead. Now you must change behaviors, and perhaps even your culture, to reap the benefits of your new technology. For example, for my new database technology, whose objective was to track disparate bits of information and commitments I had made, I had to adopt a new habit of stopping whenever new information arrived to enter it into the database so that the database remained up to date. Without this change in behavior, the new technology was useless.

Most companies are willing to invest lavishly on new technology, but they greatly underestimate the labor, time, and money needed to make the associated behavioral changes. For more on this, see our recent column, “It’s Not About the Technology.”

(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.

mdrotar@strategy2market.com

708-829-7470

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