Product Management for Strategic Advantage

Product Management is a critical process for your company: managing your products effectively throughout their lifecycle ensures optimal use of resources to maximize productivity and profitability.

Much has been written about Product Management, Product Lifecycle Management, New Product Introduction, and Product Portfolio Management. I don't want to add to the canon of excellent texts on the subject. However, I think it's important that I explain my own philosophy and how it colors my own work.

Role of the Product Manager
In the best-run organizations, the Product Manager is the overall business manager for a particular product across its entire life. As such, the Product Manager must have adequate knowledge to manage numerous diverse activities: design, manufacturing, operations, finance, marketing, sales, support, service, and even (in the WEEE world in which many of us live now) disposal. While Product Management may exist within the aegis of the engineering (development) or marketing organizations, it's always something of a "force fit." Product Managers tend to be more interested in market research than promotion, because that "incoming" marketing informs what should happen to the products next. And while the best Product Managers for technical products have engineering backgrounds, one of the hardest things for many Product Managers to accept is that they don't do engineering.  Indeed, the role of the Product Manager usually isn't to solve a problem, the role is really to see the problem, pose it to the concerned parties, and facilitate the solution.

To do this effectively, the Product Manager must have an understanding of all the aspects of business. Because of this, I strongly advocate hiring MBAs as Product Managers. The MBA isn't a magical degree that confers all knowledge and wisdom to its holder, but it is the best indication that a person at least has a rudimentary understanding of at least most of the "moving parts" of business. Combined with a technical degree and several years work in a technical capacity, the MBA provides a solid foundation for a Product Manager.

Product Management Process
"Process" is a funny word in high-technology business: some regard process as almost religion, while other recoil in horror at the mere mention of the word. I regard both reactions as disappointing; to be successful, you want to have just enough process to ensure you're not having to re-invent everything every time you create a product or run a program, but process should never become an impediment to good ideas or an end unto itself. The function of the product management process is, simply, to ensure the best products come to market and make the most money for the company. (Note: I once worked for an organization in which the primary goal wasn't to make money; the key to success is that you define, clearly, what constitutes success, measure progress toward that goal, and reward success. In most organizations, however, the measurement will be profitability.)

In my experience, the primary process the Product Manager uses and drives is the Product Lifecycle Process. There are many forms of the product lifecycle process, with varying numbers of steps and decision points - I advocate a seven-phase process with six decision points.

The Concept phase is where a set of requirements and desires become an idea for a product. This phase is typically initiated with market research, customer input, sales won/loss analysis, and other market intelligence. Sometimes the idea for a new product comes from engineering, seeing an opportunity to apply new technology or develop a product for a perceived need in the market - sometimes these are great ideas, but they must be evaluated for strategic fit and validated by market research before proceeding. I have been in organizations that have developed wonderful products that their sales force couldn't sell because no one had asked whether the product was appropriate to the customers they were calling on, and I have seen amazing technical accomplishments that didn't do any good for the company because they didn't address the most important needs of the customers.

The output of the Concept phase should be a Product Requirements Document (PRD), authored by the Product Manager: a paper that explains exactly what problems the product solves, for whom, how big the market is for the product, and how it fits into the company's existing product lines. It should not define the features or function of the product, just describe the requirements. The Product Approval Committee (PAC) should review all PRDs and approve (move to Development), reject, or redirect (ask for changes to the PRD) the concept.

The first step in this phase is the translation of the PRD into an Product Development Plan (or Engineering Specification), which describes the features and functions of the product and how it meets the requirements of the PRD. This document should be authored by the Engineering lead, and approved by the Product Manager. In some companies, this constitutes another phase and PAC approval is required to move forward; in some others, this step is considered part of the Concept phase. In some organizations, the output of this phase is a product ready for testing, but that frequently involves a large investment without much management visibility.

I like to exit this phase with a Product Development Plan and a conceptual prototype to prove the feasibility of the concept. This may entail several months of engineering, but it's nearly always only a small fraction of the work required to bring the product to market.

At the end of this phase, the PAC is approving the proposed solution to the requirements posed in the PRD and the expenditure needed to bring this to a point where it can be shown to customers.

In this phase, the product is developed further and perfected. Successive prototypes are developed and tested against the specifications developed and documented in the previous phase.

At the end of this phase, the PAC approves the product for beta testing (testing in the hands of real or prospective customers), meaning it meets all the requirements of the PRD, it has complete engineering specifications (drawings, instructions, etc.) to be produced in small quantities, and a detailed set of requirements it must meet in beta testing.


This phase is also sometimes called "Acceptance Testing" - the product is placed in the hands of actual customers (or prospects) to see if it actually delivers the benefits originally envisioned. A clear set of requirements must be defined for exit from this stage, from both a technical aspect (the user is able to get the product to do what it was designed to do) and a marketing aspect (the user sees the value in the product and will pay for it).

The PAC should approve exit from this phase only when the product is ready to be sold and all the plans are in place for the next phase: Production, Marketing, Sales, and Support & Service.


This phase typically passes fairly quickly: it is the introduction of the product to the market. In this phase, initial manufacturing of the product begins (to meet anticipated demand), the sales and support teams are trained on the product, and the marketing group executes the market launch.
At the end of this phase, the product is generally available (i.e. manufacturing quantities meet demand and channels have access to the product without delays), the sales, service, and support teams are fully supporting the product, and the initial marketing campaigns are underway.

For a successful product, this phase may go on for years. It is the phase in which the product is being actively marketed and sold, and fully supported by the organization. Marketing and sales groups should be working together to maximize the sales potential of the product, while manufacturing and operations work to reduce the cost of producing, shipping, and selling the product. While it seems that this is a time to "coast," this is usually a busy time for the product manager, with hundreds of decisions to be made. For instance, there are usually opportunities to save cost by changing manufacturing or packaging methods, but they must be traded off against the customer's perception of the product. Sales figures must be monitored, market research watched, and customer behavior understood in order to predict the end of this phase and the beginning of the next.

The Product Manager should recommend moving the product from this phase when new opportunities offer better returns, or when ongoing support for the product is simply not as profitable as the company requires.

The environment into which a product is being sold is always dynamic. Of course, the most obvious sign of the changing environment is declining sales: the product is just not as appealing to customers as it used to be. Sometimes external forces move products out of the market, like new regulations (RoHS, WEEE) or sudden shifts in consumer preference (touch-screen smartphones). And sometimes internal pressures force the product out of the market, such as a strategic decision not to serve that particular market any more or the introduction of a superior product to replace this one.

The PAC should approve the transition to the End-of-Life phase when the prospects for the product have diminished to the point that the resources being expended to support that product could be better used on other products (or, in some cases, those resources simply disappear.) The transition should be approved with a clear plan for withdrawing the product from the market, with plans for the marketing, manufacturing, sales, and support/service transitions spelled out in detail.


This last phase of the product lifecycle is critical, because the goal is to minimize the costs of withdrawing the product and stopping its manufacture.
The Product Manager must work with Manufacturing, Sales, and Support to understand all the effects that the end-of-life will have. There are two possibilities for the end-of-life: orderly or forced.

An orderly end-of-life occurs when the product can still be produced in the quantities demanded by the customers and can be sold and supported for those customers. In this case, a transition plan must be carefully worked out with all the groups affected by the withdrawal: Manufacturing and Sales to determine an end-of-production plan and date, Support and Service to determine end-of-support plans and dates, and Marketing, Sales, Support, and Service to create a customer communications plan so customers (and channels) know what to expect, what the deadlines are, and what their options are.

A forced end-of-life occurs when, for some unforseen reason, the product cannot be manufactured, sold, or supported any more. The steps are largely the same, but the timeframes are all compressed due to the urgent need to communicate the end-of-life plans within and outside the company.

Getting this right can take time and energy. Understanding the needs of the customers and taking appropriate steps to prepare them for the end-of-life, including contingencies for those customer who have continuing need of the product, is critical to keeping those customers for future product offerings. In the extreme case, customers have sued companies over end-of-life products based on an "implied contract" to continue to have access to the product. The liability issues are enormous and must be considered carefully.