CHAPTER 35
New Product Development: Issues for Project Management

DENNIS M. SMITH, CEO, DENSMITH, LLC

Product development is a specialized case of the project methods described in the PMBOK^® Guide. By adding product-specific focus, the product development leader can increase the probability of success over what otherwise would be attained by implementing a process that might be applicable to other types of projects, such as IT, construction, or public works.

Focus areas include understanding and factoring customers’ requirements, ensuring distribution channels, cost and price goals, and building competitive differentiators.

If one of these were to be singled out as the most important, it is clear that the majority of product development projects that fail do so because of defects in requirements. New product development failure rates are reported to be as high as 85 percent to 95 percent.¹

Failures due to problems with requirements account for 50 percent to 60 percent of those total failures. Too often enthusiasm predates facts, and that enthusiasm—while a necessary ingredient—if not surrounded by practices that make sense, can be the downfall of a project.

A second reason commonly cited for failure of product development projects is failure of distribution. Especially in engineering or technology driven companies, not having sales, marketing, physical distribution, and appropriate access to customers in place when the product is ready leads to loss of competitive advantage due to a slow rollout or canceling of a great product idea due to inadequate access to customers.

Unclear or unrealistic goals for product factory cost (cost) and net sales price to the customer (price) are also leading causes for failure. Too often in the excitement of a product development project, the financial goals are unclear, ignored, or the project goes forward without ever agreeing as to whether the product costs meet the needs of market reality.

And last of the top four issues is having a clear and realistic understanding of the product’s or businesses’ competitive differentiators. There are many strategies or competencies for building, and whichever of those is selected, they must be built into the team’s culture. Lowest price sounds like a simple strategy; however, there are few markets where that strategy can work and few companies who can deliver that strategy. Products based on a competency of best service are also well founded, but the strategy must meet the customers’ needs. Selling an exquisitely supported product into a market where price is “king” is at best a fleeting strategy, for once buyers know the product works, and the differentiation value of services fades to insignificance.

These themes will be woven through this chapter as basic tenets of product development projects. Much of what is required for product development beyond the PMBOK^® Guide practices ties back to these four concepts. A wealth of additional information is available through the Product Development and Management Association.²

STARTING THE PRODUCT DEVELOPMENT

Most product development projects start without requirements. The ideas come from a customer’s need to solve a particular problem, a marketing need to counter a competitive product, a new technology that might disrupt the marketplace, a cost reduction of a current product, or a whim of a great idea. All of these are legitimate, and most do not have enough detail to start a project, but this is where product development starts—it starts when the idea is born or when the challenge is presented, both long before the project team is assembled.

The first challenge is to assemble the core team. This is usually made up of two to four part-time people who will build enough clarity around the product idea to gain project approval and justify startup of the project team. Critical to this step is that it is a small number of dedicated people who are committed to move forward—too many people at this time and the project will probably stall.

If a product champion is not apparent when this team starts, they will emerge early in the process. The champion is not the formal organizational leader, but is the first-among-peers who wants to live the challenge of insuring that the project moves forward both now in the formative stages and later when the project is formalized.

If there is not an apparent champion, then the sponsors should question the project. There are many people who need to be influenced and many customers to be listened to and persuaded. If there is no active, leading, assertive, believing champion, it is unlikely that the product development will succeed. The best champions are self-proclaimed; appointing one rarely works other than for the least-contentious product developments.

REQUIREMENTS

Clarification of requirements starts at the source of the idea for the product. The idea can come from any source, and that source needs to be involved in the first expansion of the idea into requirements. The first descriptions of the idea should be expanded into six to ten use-cases.³ Use-cases are brief written cases or scenarios that clarify the actual use of the product from the point of view of the user. For a car, one use-case might be from the time the person reaches for the door handle until they are driving down the road. For a vacuum cleaner, it might be from the time it is noticed that the bag is full until vacuuming has resumed with a clean bag. For a software application it might adding a new user to a system.

Scenarios capture many requirements but also provide a framework for capturing the details of the product. The goal of scenarios is to write in prose-like flowcharts. PowerPoint should not be used for use-cases, as its organization is not conducive to writing good cases.

It is important at this stage to focus on completing a high level of requirements prior to moving to details. There is a tendency to write the most about the things that one knows best, but the objective is to write completely at the highest levels first, and then move through two or three additional levels of detail toward a complete definition of the product.

For best overall quality and schedule predictability, the people who will be responsible for qualification testing, manufacturing, and field support should be on the team as the requirements are written. Writing requirements and project plans with the needs of these teams in hand will reduce confusion and improve schedule predictability as the project nears completion.

As the first scenarios and product descriptions are completed, the first customer reviews should take place. Customer interaction should start here and run through project completion.

Now is the time for the first round of competitive analysis,⁴ long before the development project starts. Analysis must include costs, price features, functions, and benefits. With customers, the emphasis is on benefits, but to your business the emphasis is on competitive differentiators. The differentiators must be compelling to both the sponsors and to your customers. If differentiators are marginally competitive, boring, or lack sizzle, the product should be reconsidered. If you don’t see a way to achieve the product cost requirements, proceed with skepticism and plan to revisit the cost estimates at short intervals with the intention of showing that the cost requirements can be met or stopping the project.

At this time it will also become apparent that there is probably more work to do than is allowed by the project end date and budget. Start now to prioritize the features and benefits, with those priorities set at the macro level of features, well above the details of the product.

Now with a top-level description in place, several use scenarios that describe the product in operation—with leadership of a motivated champion and the support of excited potential customers—and it’s time to start thinking about building a project.

These steps are summarized in Table 35-1.

PROJECT APPROACHES

Unstructured Projects

Most organizations that develop products use a structured approach. The costs of project failure and the high likelihood of failure in the best of projects support the need for structured approaches, yet most businesses do not build project plans or build only token plans that are not useful in managing the project.

Before we dive into structured approaches, I want to emphasize that for teams of eight to twelve people, with experienced participants, great teamwork, great communications, and strong focus on the customers, an unstructured process may lead to higher productivity, shorter time to market, and build a superior product.⁵ These groups can be driven by leaders, product champions, or even by the soul of the team. This approach has been proven time and again by small startups that rock the market. What you read about are the well-publicized exceptions that succeed—most projects run in this fashion disappoint or fail.

TABLE 35-1. REQUIREMENTS FOR REQUIREMENTS

The conditions for the success of nonstructured product development are hard to achieve. Too often small teams believe they meet the criteria for an unstructured project, only to learn in failure that they were shortsighted in their understanding of their customers, skills, focus, commitment, or chemistry; or to learn that they simply overlooked some area that was critical to their success.

For the other more than 95 percent of product development projects, structure approaches are best. Structure fed by enthusiasm and competency builds great products.

Buying Outside

Many companies build their new products but just as many choose a development partner or outright buy their products from other businesses. These alternate sources are especially favored by companies that have unique opportunities, are anxious to enter markets, or are too bureaucratic to tolerate the risks and uncertainties of product development.

Outside procurement of a product should be carefully considered when your team is not experienced with the product’s technology, time is more important than investment, an external source has the product in deliverable form, and you have adequate expertise and resources to manage an external project or to complete due diligence on a potential acquisition. Due diligence on acquiring a product from an outside source must include testing the product to its specifications.

The most common cause of disappointment with outside sourced products is caused by failure to adequately project-manage or exercise continuous due diligence with the outside partner.

Iterative or Waterfall

Waterfall methodology is based on defining the entirety of the product in advance of starting the project and then proceeding step by step to completion—kind of like fitting yourself into a barrel and then falling over the edge of the waterfall … movement to completion with no reassessment or change in scope.

There are many types of projects where the waterfall methodology makes sense such as repetitive construction, but it is rarely used in development of innovative products.

Iterative or spiral methodologies are based on the idea that you need to change features and implementation during the course of the project as the team and the customer-partners get smarter about the product and how it meets the needs of the customers. In practice this is usually accomplished via an evolving prototype. While this process will likely produce better results, it is less predictable in terms of total investment and end date.

Most product development projects are started without all of the details known and without all of the features defined. This means that even if the leaders want a fixed project cost and time, in fact the project will invent some of the features and design during the life of the project. In its simplest form, if a great idea emerges part way through the project, the iterative methodology will capitalize on it. Most waterfall projects will probably make the change either through an approved change process or in a manner hidden from the project managers. Mature iterative processes are better able to take changes and improvements in stride.

For product development, building project and sponsor teams that can deal with the ambiguities of iterative methodologies is a superior approach to the control-from-the-top mentality that is often part of waterfall methods.

STAGES AND PROGRESS

Work in product development projects proceeds in chunks. Whether these chunks are called stages, phases, periods, quartiles, or steps, they are basically a coherent chunk of work followed by a review or checkpoint that ensures that the previous work was completed and that the team is justified in proceeding with the next chunk of work.

Since 40 to 50 percent of product development runtime is spent before the project team starts, when working to reducing time-to-market, give half of your attention to pre-project time.

For products, the chunks should be related to the evolution of the product, not to arbitrary process milestones. While there are many standard processes, potential milestones can include things such as: completion of scenarios, first budget estimate, first completion estimate, demonstration of major subsystems, completion of design, start of qualification testing, engineering complete, all features available, and quality verification milestones. While a team could use a set of company-wide milestones, using milestones that make sense to the project team will ensure both their buy-in to the deliverables and the applicability of the milestones.

At the reviews between the chunks of work, the tone must be set by the leadership that creates an open and honest discussion of the state of the product and project. The objective is neither to fail the review nor to pass the review. The objective is to openly share the project information from all perspectives and to reach agreement between the reviewers that it’s time to proceed to the next chunk of work. The norm should be developed that it is any attendee’s responsibility to speak up with their concern; it is not just their right.

The most important thing that this group can do at the review is to kill a bad product or bad project. When all energy is focused on success, it’s the hard job to proclaim that the product should be stopped. Open and honest communications and dialog in full view of the facts is the fuel for the best decision.

Two other processes that should be in place as the work chunks and reviews move forward are a change board and a risk management process. The change board is a group of three or four people who have final say if a change to the product is accepted for inclusion in the current release of the product. At a minimum the product champion, the product development leader, and the testing leader should be on this board.

Risk management is a difficult process. At best it is exposing your worst fears about the product to your executives and sponsors. Talking about the risks and letting everyone on the team suggest mitigations is always better than hiding them under the table. Building norms around openness, shared responsibility, and rational behavior are necessary to make this practice work. If those norms are not in place, open risk management planning will fall to the wayside as it becomes too uncomfortable for any of the participants.

CUSTOMER INVOLVEMENT

Involving customers as early and often as possible to talk about your product is the best step you can take to ensure your product’s success.

While signed nondisclosure agreements with the individuals are almost universally required, the ethics of the individual should be taken as the first defense of your product secrets.

Customer involvement comes in several levels. First and easiest are customers that your sales department has concluded might be influenced for current purchases or for early sales of the new product. These casual reviewers should be avoided until your project team has demonstrated that they are near completion, generally when beta testing is in progress. Presenting new products to customers can increase company viability, but also can severely stress the team and compromise product development progress.

The second level of customer participation is critical reviewers. These are people who listen to your preliminary presentation on the product and give you their immediate feedback based on what they have seen. These opinions can be valuable, but care must be taken to ensure that the background of the reviewers is known and understood. Their feedback should be considered and factored into the product development, but only after it is viewed through the lens of their knowledge, biases, affiliations, and predispositions.

The third level of customer participation in an ongoing relationship between the customer and the product development team. These customer-partners see the progress of the team and arrive at review meetings or participate in calls with deep background and knowledge of both the product and the motivations for the product. Their role must be carefully defined, their company agreeable to the relationship, and their integrity and openness unquestionable. While bringing partners into this role from the beginning of the project is challenging, it is well worth the effort. Not only do you get great insight from a credible and unbiased source, the relationship can easily develop into a field trial arrangement and ongoing sponsorship of the product.

While focus groups are a standard means of gathering customer opinion, at best they present casual reviewers. Anyone venturing into the one-time or paid relationships of focus groups must exercise great caution both in the validity of the opinions presented and in carefully asking questions so that the questions do not bias the answers. It is essential that the leaders of the focus group manage participation to ensure that a few vocal participants don’t block participation by others.

The practice of paying customers to participate in reviewing your product is questionable. If possible, do not compensate or pay expenses for customer partners. If their interest in genuine, the most you should consider is covering their travel and living expenses for the reviews.

A common error on the part of product managers or product champions is that in their quest for achieving total customer satisfaction, they fail to recognize and account for questionable or biased opinions. Customers have biases towards products they have purchased or supported and technologies that they believe are desirable—those biases can negatively impact your product features unless the needs and motivations have been adequately vetted.

In all cases of customer participation, the critical skill for the product team is to be able to separate the fact-based, sincere, well-thought opinions from the seat-of-the-pants or otherwise biased opinions that some customers bring. In most cases, a customer’s opinion can be found to support any position and any product feature. It is a required skill for product managers and product champions to sort the important opinions from the unimportant and the team must understand and trust that opinion.

PRODUCT JUSTIFICATION

The best justification for a project is a customer-savvy person with a clear understanding of the potential product, its customer benefits, and how to get customers to say “this is a great idea.” Many of the most important products of the past decade came to market with that level of justification and that kind of a vision.

The worst way to justify products is by careful calculation of Return on Investment (ROI) with a pass/fail decision made on that exact calculation. A large number of the most influential products of the past decade would never have been started, continued, or finished if straight ROI were the guiding principle. Businesses using straight ROI run the risk of killing the very projects that might make them great.⁶ ROI is necessary but not sufficient as a tool to judge product opportunities. While neither of these justification processes is sufficient, completing both is necessary to justify a project.

If you can’t find an excited person—a potential champion for the project, someone who can tie the customer need to the product and can envision how to get the product into a distribution system that will sell and deliver it to potential customers—then the idea is not ready to move forward. Let the pre-project team further develop the idea or kill it.

ROI is an important exercise, but it is more important for the rigor of developing all of the product cost, project costs, and sales estimates that comprise it than it is important for the final numeric result. Look for the final numeric result to be reasonable and little else.

ROI is also not a useful concept for comparing product ideas that are in competition for funding. It is too easy to misjudge estimates of costs or sales for any product in pre-development. It is also too easy for a less than reputable or overly enthusiastic champion to consciously or subconsciously raise or lower estimates in a way that might bias the resultant number.

Cash flow is probably the most important element of the financial analysis. There is no point in starting a project that you can’t afford to finish, although with a great product idea, cash sometimes appears.

A cost overrun on a product development project is financially insignificant compared to the financial gains of a successful product. Build a successful product and the financial sins of the project are quickly forgotten—build an unsuccessful product on plan and on budget and no one will care.

Timing is one of the most critical factors in any financial analysis. In the 1980s it was likely that a new concept, an innovative product, might enjoy two years in the market before competitors responded in kind. For Internet-based products, that competitive-timing advantage is now likely measured in days or weeks. For some technology products, such as notebook computers, the product life can be shorter than the product development time.

So a product having a great “gut feel” is best. If a team shares that feeling, all the better. If the ROI is credibly interesting, all the better. The challenge of a large business is to be able to spend the leaders’ time to invest in the understanding of the product success factors in order to make an informed judgment that goes beyond a rote review of numbers.

This process requires time and nonadversarial authentic dialog—two things that are often in short supply and that might take years to develop in a small to mid-sized organization and may be unattainable in the largest of organizations. Successful large organizations generally answer this need by delegating those decisions to the lowest organizational level possible in an attempt to streamline the process.

MANUFACTURING AND FIELD SUPPORT

For physical products, manufacturing and field support must be a part of the product development process from the beginning. Manufacturing must own the cost estimates and they must certify the manufacturability by developing the manufacturing processes during the product development project.

The field support team needs to provide requirements to the project to ensure that the product is supportable once in the field. Support requirements, along with manufacturability requirements, should be considered a priority equal to those expressed by the customers.

This can be a challenge to a product development team, as their work is strategic, while the priorities of manufacturing and field support are usually driven by hourly or daily priorities. The process can be further complicated by a common if not traditional rivalry that exists between product development, manufacturing engineering, and field support over designs, support, customer ethics, and many more issues.

The product team must assure the participation of the manufacturing and field service teams before the formal product development project is designed and committed. If rivalry exists, structured team building should be an explicit part of the project plan.

PREPARING FOR SALES

The first step in preparing for sales is to have a clear set of terms describing the level of commitment of the organization to the dates that are shown on the project plans. I recommend these:

• Target. The team has thought about the project and is working to the target date, but there are not yet supporting plans and resources in place.

• Estimate. The team has built a project plan and is in the process of executing against that plan, but there are sufficient risks or unknowns that make the team not yet ready to commit to the dates.

• Commitment. The team is committed to the product delivery dates.

Sales often feels that every date is a commitment and every product is available for sale. Any information presented to sales or to customers needs to be explicit about the meaning of dates with clear expectations set about how the sales force may use the dates outside of the company. Releasing a product for sale is an informed business decision with the current state of the project being just one of many considerations leading up to that decision.

CONCLUSIONS

Product development is a specialized case of project management. If the team pays careful attention to customers, differentiators, product costs, sales channels and support, the platform for product development provided by project management will drive the team to success.

REFERENCES

¹ Primary data on these failure rates is not current in that it does not include the affects of distributed and offshore development teams and rapid advances in tools. The fallacy of most data of this type is the ambiguity of the point in time where failure is determined. For example, whether or not the project is determined a failure after one month (perhaps due to unattainable cost goals) or after two years of low sales strongly biases the insights that might come from the data.

² See the PDMA Web site at www.pdma.org.

³ Kurt Bittner and Ian Spence, Use Case Modeling, Addison-Wesley, 2002.

⁴ Competitive Strategy: Techniques for Analyzing Industries and Competitors by Michael E. Porter. Free Press; 1998.

⁵ Tom DeMarco and S. Lister, Peopleware: Productive Projects and Team, Dorset House, 1987, pp. 24–29.

⁶ Rebecca Henderson of the MIT Sloan School, quoted from a presentation to the New England Chapter of PDMA held at Northeastern University, November 20, 2002.