The Product Planning Process

The Product Planning Process

The product planning process is one of the most controversial within any company. Everyone wants a hand in new product definition and almost everyone will have contributions that will make a new product successful. With all these interested parties, you are going to need a system to help you through the product planning process and a way to decide which ideas have the most merit. This system also needs to incorporate customer feedback, assure that important new product ideas are approved, and that development of them initiated immediately. What follows is a product planning system that works well for most companies.

The above diagram outlines the phases in the product planning cycle. In any given company, these steps may be condensed or combined. For example, some companies may use a single document to cover both the Market Requirements Document and the Functional Specification.

The steps are important because they allow you to gather input from all possible resources, evaluate the potential of each idea and gather input from all involved parties about which ideas will work and their ease of implementation.

Input

There should be no shortage of new product ideas. If you are doing regular customer councils and customer surveys, you should have a long list. (Please see Chapter 2 for more information on gathering regular input from customers and your sales channels.) You will also have ideas from sales, engineering, technical support, and management. The biggest job is narrowing down the list. A regular poll of sales, tech support, engineering, and customers for product ideas may help you prioritize. Be sure everyone in your company knows to feed product ideas to you. Often times the tech support organization has a unique insight to customer requirements because they are in contact with customers who need help daily, but no one ever bothers to ask them. When you need to narrow the list further, run it by your customer council. You can ask them to vote on the product ideas they think are most valuable.

You should also understand your current products, what is selling, what isn't, and why. Finance should be able to provide you with a breakdown of sales by product. A couple of phone calls to key sales people should provide you with an earful of information on why certain products are selling well and why others are not. Product managers are also called upon to do customer presentations to major accounts. These presentations should be open communication sessions. It is an excellent opportunity to learn first-hand what the customer needs and how they are using your product. (For more information please see Chapter 2, "Customer Presentations")

Competitive analysis is also an important part of product planning. Your customers, sales channels, and prospects evaluating your product will tell you where you fall short competitively. Additionally you may want to take an existing strength that you have over your competitors and lengthen your lead with improvements to that strength. Remember that a competitor won't release a feature that is just on par with your product, they will be trying to exceed your strength. Also understand where your competitors are going and what products they have in the works. You won't get this information directly from them, but you may hear rumors or see press on their strategic directions. Additionally listen to your prospects when they are asking you about your product features and directions. Often times they are parroting back information that your competitor's have given them. The World Wide Web is also an excellent place to gather competitive information. Often times competitors will publish their strategic directions and, for software companies, actually have beta versions of their new software releases available.

Market analysis is also important. Trends in the industry need to be factored into your product plans. Professional market analysts can help you with this if you want a third-party perspective. Your engineering group will also provide some good ideas in this area; they are generally on top of many of the new technologies.

Don't forget the possibility of discontinuing a current product. Discontinuing a product is a tough decision, but many companies have failed because they have spent too much of their resource trying to maintain a product with old, difficult technology. (Please see the product discontinuation section for more information on when to discontinue a product.)

Narrow down the list to a handful of ideas that you want to investigate further. Remember that the most important criteria for your company is return on investment. The top ideas that you select must either have broad market appeal (within your current market) or enable you tap a new market.

Product Ideas Refined

After narrowing down the list of potential new products or features enhancements for an existing product, you will want to refine some of the more promising ideas. Before a product idea is funded, some basic information needs to be gathered about who is going to buy the product, how much they will buy, and how much it will cost to develop it. This is the information that will eventually be expanded upon in the MRD (Market Requirements Document) but should be gathered and presented in summarized form to seek product approval. Here is the type of information you will need:

• Product Description - You need enough information so that the product can be easily described in one or two sentences to customers or other people within the company. Also position the product. Who buys the product? Why is the product of value to the buyer? Why is it better than the competition? One over-used, but effective measurement of your description is the "elevator test". Can you sell the product idea to potential customer in the short time that you would have them as a captive audience on an elevator.
• Market Justification - Why should the company build this product? Who needs it? How much will they buy? Including market numbers and real sales projections will help you determine the size and the viability of the market. These will initially be very rough estimates until you have time to determine competing products' marketshare.
• Resource Projection - Work with the engineering organization to get an initial very rough estimate on what it will take to build the product in terms of people-years. You will probably meet some resistance with this. No engineering manager wants to sign up to a schedule for a product that is not well defined. You will need to assure the engineering manager that no product will be defined until management can be assured of the return on investment and you can't figure out ROI without having an estimation of the investment. Be sure to use these schedule numbers with the caveat that they are rough estimates and real schedules will be defined after the product is specified.

Products Approved

Once you have gathered the above information for you product proposals, you need to get the project approved. I recommend using a product planning meeting for this because it allows you to present all the appropriate information to everyone at once. It is also a great forum for discussion of the merits of the product. (See "Running an Effective Product Planning Meeting" below for more information.)

In some companies, you may need a full market requirements document before the project is approved. This is not the most effective method of product planning for the following reasons:

• At this point, the product manager's time is best used looking at the broad picture and narrowing down the most promising product ideas. To do the research work required for a full MRD wastes time before the project is approved.
• Projects are better refined by all parties involved. There should be an open discussion of the project's viability before a detailed MRD is generated.

The company should have an "Approved Projects List" (some companies call this a Plan of Record or POR) that is either published regularly or located centrally where everyone can access it. If your company doesn't have one, then create one. This is a list of all projects that are approved and currently being developed in the company or division. Having one central list will provide a point of focus and clarify the priorities for all involved. Ideally the list should be updated regularly and posted in a central location. When a project is added to the list, it should be funded with development resources.

Market Requirements Refined

Once the product is approved you can refine the market requirements, adding more detail on the desired features of the product and how the customers will use the product. (See the "Market Requirements Document" section of this chapter for more information.) There will be two types of MRDs, one for new products and a second for new releases of a current product. The new product MRD will require

Development Initiated

Once the MRD is complete, the developers can start to work on a functional specification and prototypes. Some companies combine the MRD and Functional Specification into one document to help them decrease time to market. To do this, you must work very closely with engineering to make sure that the functional design of the product will indeed meet customer requirements. (Please see Chapter 4 - The Product Development Cycle for more information on working the Product through the development cycle

Running a Successful Product Planning Meeting

Why have a product planning meeting? Everyone hates meetings and adding one more won't be popular. You need a meeting because time-to-market is the key to success in the high-tech industry. Anything that delays your time-to-market hurts your company. If you can gather everyone in a room and get them to agree that a new product must be funded and development started immediately, you have decreased your time-to-market.

The meeting gives you a forum to formally add and remove products and projects to the approved projects list and to make sure that everyone involved is clear on the priorities. It also gives them visibility to why the priorities are what they are.

I initially started product planning meetings when I was working in a CEO-driven company. This particular CEO would wander over engineering and together with a couple key engineers they would come up with a great idea and suddenly we had a new product that was funded. The problem was that the product was not necessarily something our customers wanted and the products our customers wanted most, didn't have the resources assigned to them. I put the product planning meeting in place so that all ideas were researched, discussed, and approved or rejected at this meeting with everyone's input.

This process may seem like a lot of work, and frankly it is. By comparison, you wouldn't just start writing code on a software product without doing the structure and design work first. When you compare the effort of product planning to spending hundreds of man-hours of development resource for a product that sales can't sell and customers won't buy, the planning work is nominal.

How often you run product planning meetings depends upon the size of your engineering group and the dynamics of your market. Once every six weeks to once every quarter, should be often enough to reset priorities. Although the market may change overnight, product development can't and shouldn't be asked to. Changes to development plans, schedules and priorities need to be carefully measured.

Attendees

The objective of the meeting is to obtain product approval, so you need to invite everyone who has a say in such things including the President, CEO, VP of Marketing, VP of Engineering, VP of Finance, and VP of Manufacturing. You also want to invite anyone who will provide lively but productive discussions. (It is also your job to keep these discussions under control and not let the meeting get side-tracked.) Invite as much of engineering as you can get away with. You don't want the meeting to become unwieldy, but at the same time you don't want someone coming back later saying that the product should not have been approved or rejected without their input.

Meeting Format

Everyone should be notified well in advance of the meeting about which potential products or features are to be discussed. This will allow concerned parties to give you their input well in advance of the meeting. The idea is not to "spring" new product ideas in the meeting, but give people time to think about the new ideas and how it will affect their aspect of the business. Here is a sample agenda.

• Overview of the market and significant changes in the market since the last product planning meeting or within the last quarter. This is done so that the audience has complete exposure to all the changes and trends in the market. It will allow them to be better prepared to make product decisions.
• Review of company direction. A very quick review of the company's long term goals will help everyone keep the strategy in mind when making product decisions.
• Review of the current approved products and schedules, preferably by the VP of Engineering. This lets the audience understand the current workload and how time is already allocated. If current projects are slipping it makes no sense to add new projects without removing some.
• Discussion of new project proposals or changes. Each product should be given 45 minutes to an hour for presentation and discussion, so you should only try to do four to six products in a single meeting. You will probably need to run the meeting through lunch and ideally have it off-site where there are no interruptions.

It is important to drive the meeting to conclusion. This should be your primary purpose in the meeting. The meeting should end with a review of all projects and which were approved, rejected, or need further investigation. Also included should be a list of proposed projects for the next meeting.

Product planning meeting minutes should be published immediately following the meeting. Meeting minutes are painful and it is always easy to put them off, however for this meeting the decisions are so critical to every aspect of the business that I would recommend getting the minutes out the night of the meeting.

For projects that are approved, work should commence on a Market Requirements Document

The Preparation

The outline below shows you what information should be included on the product planning slides for each product.

You need to prepare all the slides in advance of the meeting. You will want to schedule some time with engineering to review the slides before they are finalized. This is necessary for the following reasons:

• Engineering needs to provide resource estimates.
• Engineers may have great ideas on a particular implementation of a product or even a good target market for the product.
• Engineers may have strong opinions on a given project. It is best to understand those before trying to get the project approved.

For the meeting you will want to have the room set up in a round table format to encourage discussion. Have copies of the slides and back-up documentation for everyone involved. New products are controversial and anything you can do to make the meeting run smoother is important to the overall objective of the company working on projects with the best return on investment.

Outline of Presentation

I recommend using only one or two slides per product. You can hand out any back-up material. A simple standard format will allow anyone to look back at the slides and recommendations without becoming lost.

Sample Presentation

Project Name- Come up with a name for the project that is easy to identify, but don't spend a lot of time on it, this isn't the final product name.

Product Description - Give a brief bulleted description of the product and its positioning (why it is of value to the customers and why it is better than anything else on the market).

Recommedation - Most people would want the recommendation last, but I have worked with plenty of unruly groups who would get sidetracked long before the product manger could talk about their recommendation. So I put it as far up to the top as possible. If you are working with a more civilized group of people, you can put it at the end.

The recommendation should be one of three things: Add the project to the approved projects list and fund it, reject the project (removing it if it was on the list), or hold for further investigation. If a project is a fairly new idea and you haven't had the opportunity to run it by your customers, you may want to recommend that you spend some more time on the market justification before it is approved. The only other statement that may be made here is the recommendation to discontinue a current product. If this is a recommendation then there should also be a discussion of the replacement product.

Market Justification - Why should the company build this product? Who needs it? How much will they buy? Include market size numbers here and real sales projections. Just remember that the VP of Sales isn't going to sign up to these preliminary numbers!

Resource Projection - This should be a rough estimate from engineering on what it will take to build the product.

The Decision

Getting a decision from the meeting is crucial, even if the decision is that more information is needed. The ultimate decision generally falls into one of four categories:

• Approved - If there is sufficient information to approve a product, then it is added to the list of approved products and the next step, whether it is writing a market requirements document, or writing a functional specification, is started.
• Canceled - If there is not sufficient justification for a product, or it does not fit into the company strategy then it should be canceled and removed from the list of approved projects (if it was there to begin with).
• Hold pending further investigation - No matter how much research you do on a project, questions may come up that you don't have ready answers for. Sometimes a decision will need to be delayed pending further market research information or an investigation from development. In any case, the additional information should be gathered and the project should be discussed at the next product planning meeting.
• Hold for future - If the product fits into the company strategy, but the resources are unavailable to work on it, it may be a good idea to put it on hold until some determined future time.

The decision should take into account the following criteria:

• Does the project fit into the company's long term strategy?
• Does the target market for the project align with the company strategy?
• Will there be sufficient revenue from the product to justify the work required?
• If there is not sufficient revenue, are there other highly compelling reasons to justify the work?
• Are the resources available to do the work?
• If the resources are not available, should this project take precedence over another?

The person who ultimately makes the decision should be determined in advance of the meeting. This is generally the CEO, President, or CTO of the company. The forum should allow adequate discussion before the decision is reached.