KUMARketing.com

The dilemma arises for custom products for OEMs. It is difficult to envision an EOL dilemma for a projectized  organization where the end result is a product. However, if the project stakeholder circle widens to include customers and end users, then defining End Of Life for a product becomes an issue.

Software only products can continue to make modular releases that have backward compatibility with older versions.

The task of defining EOL is more pronounced for hardware products. How long are you expected to support a legacy product?

(to be continued)

A portfolio refers to a collection of projects or programs and other work that are grouped together to facilitate effective management of that work to meet strategic business objectives.

A program is defined as a group of related projects managed in a coordinated way to obtain benefits and control not available from controlling them individually.

Source: PMBOK guide

Does  Dr. Eliyahu M. Goldratt's Theory of Constraints apply to product development? It is debatable at best. The Theory of Constraints in its original form proposes to be an iterative process. This is best suited for policies and processes. It is difficult to juxtapose the same ideas on to a regular hardware product development process. The following dictates are available as part of the theory:

The key steps in implementing an effective process of ongoing improvement according to TOC are:

0. (Step Zero) Articulate the goal of the organization. Frequently, this is something like, "Make money now and in the future."

1. Identify the constraint (the thing that prevents the organization from obtaining more of the goal)

2. Decide how to exploit the constraint (make sure the constraint is doing things that the constraint uniquely does, and not doing things that it should not do)

3. Subordinate all other processes to above decision (align all other processes to the decision made above)

4. Elevate the constraint (if required, permanently increase capacity of the constraint; "buy more")

5. If, as a result of these steps, the constraint has moved, return to Step 1. Don't let inertia become the constraint.

 

Source: Wikipedia

This however can be used in building the case for a new product. This product should aim to solve a constraint that prevents the company or department from penetrating a new market. So, the key steps for a product launch within the framework of the Theory of Constraints could be:

0. "Penetrate a low cost market"

1. High cost of development

2. Outsource the factors that are adding to the cost.

3. Subordinate processes include

a. Identify Business Partner who can do part of the work

b. Identify components that help preserve IP

c. Add more project management resources

d. Establish deployment plan

4. Elevating the constraint would mean getting more resources attached to the product.

5. Evaluate

Product messaging is a document that involves feature and benefit description of what the product does and contains data related to the value the buyer would get by buying. It is to be used as a marketing tool and would most likely be available through a data sheet.

At an SVPMA workshop, the difference between product messaging and sales messaging was illustrated by Michael Cannon of the Silver Bullet Group.

While Product messaging is product-centric, sales messaging is more of a sales tool in that it is more persuasive by answering questions for a customer like "Why Buy?" and "Why Buy from you?".

The persuasive nature of sales messaging can actually benefit a good product marketing document as well. By preparing three to five reasons why the buyer should choose your product over the competitions, you are consciously evaluating your own products (new and old) and also thinking of extensions to existing products.

A product manager prepares an executive summary at the launch of a new product. An executive summary is part of a business case that will motivate the management to invest in developing a new product. The product manager will act as the salesman for the new product. The management is the customer. The executive summary is the sales pitch. It is important for the executive summary to be concise but covers the points of interest for all the stakeholders. A product company would generally invite the following personnel to review the executive summary of a new product:

Engineering Manager/CTO: The executive summary will require a short speculation on the technology the product will be based on. It should help decide if the product is entirely new or is a variation of an existing product. This in turn will help make decisions on resource allocation.

Sales Manager: It is usually a good idea to invite the sales manager to be a co-author of the executive summary. The sales manager can help post some numbers on the expected sales volume and profit margin of the product.

Operations Manager/COO: An operations manager will use the executive summary to detect any red flags in the operational front. Will the product require a risk buy? The Operations manager will probably have some follow-up questions on the components that go into the product.

Finance Manager/CFO: The Finance Manager will be looking at the sales numbers to make sure it falls within the cost model advocated for new products.

The decision on a green signal usually resides with the personnel mentioned above. The executive summary invites some dialog to better understand the business case.

Executive Summary

<A brief introduction on the product hierarchy relative to the company>

<A decent speculation of the (potential) customer(s)>

<A small synopsis of the technical details associated with the product>

<Recommendation on sales potential>

<Research on possible competition>

The Customer Requirements Document and the Product Requirements Document (PRD) are often used interchangeably. In my opinion, all CRDs are PRDs but the reverse is not true. There could be internal projects which do not have a customer attached to it but the need for a requirements document is inevitable. Yet, the acronym CRD is loosely used even for internal projects. The argument in favor of this is that there is always a customer - in this case the customer is internal to the company. Puritans tend to ignore this as a habitual hazard more than anything else.

A CRD is a detailed document featuring inputs from business personnel and technical personnel from customer side and vendor side. Needless to say, the actual format of such a document varies from company to company. The following components are usually found in CRDs.

• Product summary and application
• Steering committee contact information
• History of changes to CRD
• Requirement sub-categories
• Milestones
• Deliverables

The personnel involved in framing the CRD, the steering committee, are business analysts, sales managers, engineers and product managers. Product managers double up as business analysts and in fact don many a hat in the requirements gathering phase. An engineering manager or project manager will be able to gauge the resource allocation and advise on the milestones and deliverables schedule.

At the outset it will be fair enough to state that not all projects result in successful product launches. Having said that, developing new products is something a company should continuously strive for. Each failed product minimizes the time lost in the next project and so on. This is part of the learning curve that every company and every product manager has to go through. The idea is to take the lessons learnt from past projects and apply them at the launch of new ones. Here is a simple table to fill while drawing the product requirements document.

This might appear to be a negative approach to start a project but more often than not it will prove to be a case of saving development time.

In some cases, the product is not a failure by itself but it could be a case where the customer interest dwindled or changed. In these cases, it will be a matter of realigning the old product to the new requirement. It helps if the same development team can be carried over to the new project as well. Irrespective, it is imperative that the product's steering committee documents all the relevant information gathered. A failed product's documentation is as important as a new product specification.

In this case, while the original product itself can be removed from the product portfolio, the documentation can be retained.