KUMARketing.com

The EOL dilemma

noreply@blogger.com (Vijay Kumar) — Fri, 05 Jun 2009 02:46:00 +0000

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)

Some basic definitions

noreply@blogger.com (Vijay Kumar) — Sun, 31 May 2009 18:35:00 +0000

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

Theory of Constraints

noreply@blogger.com (Vijay Kumar) — Mon, 28 Jul 2008 18:29:00 +0000

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

noreply@blogger.com (Vijay Kumar) — Mon, 29 Oct 2007 20:02:00 +0000

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.

Executive Summary

noreply@blogger.com (Vijay Kumar) — Wed, 24 Oct 2007 04:59:00 +0000

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>

CRD

noreply@blogger.com (Vijay Kumar) — Tue, 23 Oct 2007 03:35:00 +0000

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.

Failed products

noreply@blogger.com (Vijay Kumar) — Mon, 22 Oct 2007 23:54:00 +0000

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.

Feature	Value
Similar Product
Hardware issues
Design issues
Software issues
(and so on...)

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.

Product Line Planning

noreply@blogger.com (Vijay Kumar) — Mon, 22 Oct 2007 03:03:00 +0000

Product Line Planning encompasses legacy products and current products. It even extends to products that are in the development stage.
Companies like Microsoft and Intel already have newer products in the pipeline even as they are launching products. They hold the market and the financial strength to fund such ventures. In fact as bell weather companies it becomes something akin to a responsibility for them to continue to plan for the future. Most companies, however, are dependent on customer interest to fund new projects. For these companies product line planning caters to the following three categories.

Cost reduction
Mature products are often revamped to improve profit margin. Certain components that go into the product might be replaced by alternate vendors. It is also common practice to re-spin the product into a 'lite' one. 'Lite' products often have lower cost, lower selling price and also higher margin. The trade-off might be by way of features. Certain unused features or redundant ones might be removed leading to cost reduction. The same customer can buy this product for a different application or it could be bought by a customer operating at the second-tier level. Almost all the electronic products in the consumer space adopt this strategy by providing different products at different costs with different feature sets. This is similar to cars having standard, deluxe and luxury editions.

Patent protection
A second reason to retain certain mature products in the product line will be to protect existing patents. It is a product manager's prerogative to understand the intellectual property or IP behind every one of the products in the portfolio. Selling rights on a certain product to reduce maintenance costs will be beneficial as long as the IP that goes with it does not affect other products under development. Losing IP will have adverse effects in the long run as the owner of IP always holds the right to sell. It is quite possible in such cases to license the products instead of a full fledged sale. The licensee will pay the IP owner royalty while bearing the maintenance challenges that go with the product.

Developing new products
Innovation, Research and Development are key to move any company forward. Developing new products is the most important ingredient in product line planning and needs to be discussed in detail.

Product Portfolio

noreply@blogger.com (Vijay Kumar) — Thu, 11 Oct 2007 06:36:00 +0000

While the product road map paves a way for the future, it is useful to understand the product portfolio as a first step. In a cross functional role, it would help if the product manager has a clear focus on a product line. Quite often product managers are invited to perform roles of varying capacity in different situations. Despite that, the product manager should strive to identify himself with a particular product portfolio. This focus helps in the career development as a general manager of the particular product line.

Linda Gorchels (The Product Manager's Handbook) identifies such a product manager as a 'heavyweight product manager'. A heavyweight product manager gives his words weight and influences people over whom he has no formal authority. This can be seen as the product management's version of 'Knowledge is power'.

An unenviable task while framing the product portfolio is determining which of the products can be termed as legacy products. Legacy products are products that have more educational value than revenue potential. Legacy products often form the templates for new product designs. They would however be characterized by low sales volume, outdated technology and high cost of maintenance. A product manager should strive to identify these attributes in the product portfolio. Invariably there will be more than one match. Once they are identified, the product manager can check with sales and supply chain before formulating an EOL (End of Life) for these products. The EOL notice should then be issued to customers who last used these products. The customer would at times request technical support that extends a little beyond the EOL time period.

'Weeding' out the legacy products gives puts the product portfolio in clear perspective. This leads to product line planning.

Product Road Map

noreply@blogger.com (Vijay Kumar) — Mon, 10 Sep 2007 23:10:00 +0000

A well-defined product road map is a sure sign that the product manager has a coherent understanding of the technology and the market. In most cases, the product road map is a document internal to the company. However, a long standing business relationship with a certain business partner or customer will invite queries for sharing the product road map. The importance of accuracy to the product road map escalates in such situations. Needless to say, sharing the Product Road Map with an external party would require the protective cover of an NDA.

What to expect from a Product Road Map?

Engineering point of view

A road map canvassing one to two years helps the engineering manager identify resource requirements. Newer technology will need a study phase that has to be organized. Budget has to be allocated for toolkits, certifications, recruiting etc. Feedback from engineering would involve what components can be built in-house, what needs to be outsourced and what cannot be done. The project manager can use the final road map to schedule activities and help create a project plan.

Sales point of view

The sales team will use the road map to start adding revenue forecasts to the model. In addition, they can start pitching the growth pattern to the customers. In some cases, it also helps identify new customers.

I plan to develop a pseudo road map or add to this topic from time to time.

Planned reading:

The Product Managers Handbook, 3E by Linda Gorchels

Product Management newsletter from http://www.280group.com

NDA

noreply@blogger.com (Vijay Kumar) — Fri, 31 Aug 2007 23:45:00 +0000

The NDA or Non Disclosure Agreement would be the first document handled between two parties interested in sharing ideas and working together.

In the computer peripheral industry, an existing customer-vendor relationship is almost a pre-requisite for a new project. The development teams on either side feed on past experiences to kick start new projects. This establishes a comfortable confidence level and helps reducing development time. Irrespective all new projects are governed by Non Disclosure Agreements signed by executives (or project drivers) from either side. A Product Manager would be expected to fill in the details that go into the NDA and this would be authorized by a decision maker if not the product manager himself/herself.

A sample NDA can be obtained for a fee at Nightcats mutlimedia and a simple but free one is available at inventnet.com. Most companies employ their legal counsel to draw one for them. In well established customer-vendor relationships they can even reuse an existing NDA.

More info on NDA:

Five Important Elements in a Nondisclosure Agreement (From Mary Bellis)
There are five important elements in a nondisclosure agreement:

definition of confidential information
exclusions from confidential information
obligations of receiving party
time periods
miscellaneous provisions

About.com - http://inventors.about.com/od/nondisclosure/Non_Disclosure_Agreements.htm

Vietarticles.com - http://www.vietarticles.com/articles/40/1/When-to-Use-a-Non-Disclosure-Agreement/Page1.html

In the software services sector, it is possible that an existing customer-vendor relationship is seen as favorable rather than mandatory. Almost all major projects have multiple vendors in this sector. In some cases, it is just a matter of customizing a generic solution which eliminates the need for inter-personal skills.

Product Marketing

noreply@blogger.com (Vijay Kumar) — Mon, 27 Aug 2007 17:41:00 +0000

The function - Product Marketing - varies in scope from company to company. Irrespective, it is pertinent that the product marketing personnel have some technical know-how on the product they are going to market. This is because their opposite number on the customer side can be anyone from an Engineering Manager to Senior Engineers. Talking in their language is key for effective communication.

This is an era of outsourcing. Yet, product marketing is one of those functions that still lives outside the outsourcing dictates. It is difficult to maintain customer relationships when the product marketing group and the customer are in different countries and speak different languages. So, you find a lot of companies assigning product marketing duties to the sales personnel. While it saves operational overheads, it is a burden on the sales person as he now has to equip himself with more than his fair share of technical expertise. Some companies lessen the burden on the sales manager by transferring product marketing responsibilities to the sales engineer.

"In Silicon Valley, in particular, product marketing professionals have considerable domain experience in a particular market or technology or both. Some Silicon Valley firms have titles such as Product Marketing Engineer, who tend to be promoted to managers in due course."

Answers.com Recommendations:

Franteractive

S. Wheelright and K. Clark in Revolutionizing Product Development (1992),

My recommendation (additional):

Blue Ocean Strategy -W. Chan Kim and Renée Mauborgne

Product Manager

noreply@blogger.com (Vijay Kumar) — Mon, 13 Aug 2007 17:06:00 +0000

Reference: http://www.answers.com/topic/product-manager

What does a Product Manager do?

A combination of internal and external activities to the organization.

Product Planner - This is an internal activity. Identify a road map for the products. Chalk up deliverables on a quarterly or annual basis. Get consensus from various figureheads on these items. The plan must be based on the team's strengths as much as the market requirements. The plan must align with management objectives. Although daunting at first, persistence and focus will help paint a solid road map.

Product Marketer - This is an external activity and directly tied with revenue. Requires a steady communication channel with the client base. Needs help from the sales account holder. Requires customer relationship as a prerequisite and hence experience with the customer at some level. Need to understand the customer's road map as much as possible and identify how much of it aligns with the company's own.

Apart from this, the product manager needs to take on additional responsibilities of a sales engineer and a MarCom manager. In bigger organizations, these could be focussed specialist jobs. In smaller organizations, these usually fall under the Product Manager's domain.

Sales Engineer - Most often referred to as Field Application Engineer, the sales engineer helps the sales manager with the requisite technical knowhow while dealing with a customer. Often called during potential project discussion and also to address field issues. In other words, a marketing person with technical thrust who helps the sales manager maintain customer relationships.

MarCom Manager - The flamboyant side to the product marketing portfolio, MarCom, is the networking arm of Product Management. All activities including but not limited to trade show activities, advertisement, presentation, branding, forum representation, white paper management etc. are handled by MarCom managers.

"Even within the high-tech industry where product management is better defined, the product manager's job description varies widely among companies. This is due to tradition and intuitive interpretations by different individuals."