Primary Activities for a Product Manager

What does it take to be a good product manager? On one hand, it requires someone who can focus almost exclusively on the success of the product in the marketplace . That seems simple enough. On the other hand, it requires the skill set of a "jack of all trades," someone who understands software technology and works well with the development team, is comfortable in marketing and customer presales situations, is an excellent communicator, is experienced in the commercial marketplace, understands the competitive environment, and can negotiate with internal and external stakeholders.

Perhaps we can help people in the role of product manager by mapping out some of the primary and supporting activities they'll engage in to achieve success, as well as some of the primary work products, or artifacts , they'll develop or contribute to. Figure 17-3 defines the set of primary and supporting activities, and the associated artifacts, that the product manager is involved in.

Figure 17-3. Product manager activities

Let's look first at these primary activities.

Driving the Vision

As a former U.S. president once indicated, the "vision thing" is not so easy. It's obvious that you should have a vision, but where does it come from?

For a product, the answer is that the vision is not so much an input as the output of a process that involves synthesizing user needs, constraints, wild ideas, market trends, competitive factors, and breakthrough technological opportunities into a cohesive whole. Figure 17-4 illustrates these varied sources of input for the process.

Figure 17-4. Inputs to the product vision

The product manager's role is to facilitate the elicitation and analysis of inputs and to ensure that the proper conclusions are reached. Ideally, the team reaches these conclusions together and truly shares the vision. Even then, however, when push comes to shove and scope must be managed, as is inevitably the case, the product manager must "make the call" based on his or her view of the optimal path through conflicting constraints. If the product manager stays close enough to the customer and close enough to the technology, then the team members know they can trust the product manager to make the call. After all, the product manager's job (and perhaps the team's) depends on it.

Maintaining the Product Road Map

With the vision in hand, the next job is to factor it into a product road map ”a graphical view of the various code lines, major release dates, and other milestones for software delivery. Inputs to the process include the product features and relative priorities, resource estimates provided by the engineering team, and knowledge of key external events such as marketing and promotion opportunities, sales training opportunities, and perhaps key dates in the customer's calendar.

The product manager's role is to gain agreement on what should be done and what can be done and to then use this information to synthesize an optimum path to market, based on constraints in the internal and external environment and the allocation of specific features to successive releases. Although the job itself may not be easy, representing the result in a simple graphical model is straightforward. Figure 17-5 illustrates a sample product road map for the HOLIS team's upcoming release cycle.

Figure 17-5. Sample product road map for HOLIS

Defining the Whole Product Plan

We've described the role the product manager has in developing and maintaining the vision and the product road map. Although the Vision document itself is comprehensive, it needn't be long. Indeed, controlling the length to a manageable twenty to forty pages is an important skill because so many stakeholders must be able to actually read and understand it. However, the scope of the Vision document, broad as it is, is not broad enough to define the whole product solution we referred to earlier. The whole product solution consists of the product itself plus all the ancillaries ” in other words, those creature comforts that enable people to use or apply the product successfully.

Here are some questions to help you discover what these might be.

• What specific services will your company provide to help customers succeed with your product?

• What role does your company's customer support team play in assuring customer success?

• Is only one configuration of your product available, or are there multiple possible purchase configurations?

• Are you offering a stand-alone product, or does your customer need to purchase a third-party software application to go along with it?

• Does your product require special hardware, significant bandwidth, secure access, or other computing resources?

• What features need to be provided to support the user in installation, upgrade, maintenance, or support?

• What licensing provisions will be applied for commercial sale and use?

• What price are customers willing to pay for your product, and over what period?

These and similar questions are answered within the scope of the whole product plan , which should cover the four dimensions of a successful customer solution:

1. The product itself

2. Accompanying services and support

3. The commercial terms that define the business relationship between you and your customer

4. The documentation you provide to help assure your customers' success

Figure 17-6 provides an annotated template that teams can use to help define the solutions they are proposing for customers.

Figure 17-6. Template for preparing a whole product plan

Sponsoring the Use-Case Model and Supplementary Requirements

As we described in Chapter 16, the vision for a specific product release is typically expressed in terms of a set of product features. Once you have defined that set of features, the next step in the process is to convert them into a set of use cases that describe how each specific user interacts with the system to achieve specific objectives. Taken together, the set of all users and all use cases elaborates the vision in a manner that maps to an implementation in software and ensures that the vision is achievable.

By helping the development team define the use-case model for the product, the product manager can ensure that all prospective users' needs are met in the implementation and reflected in specific use cases. In addition, the product manager can play an active role in assisting with the development, elaboration, and review of the use cases themselves . However, the caveat is that the project team will develop a lot of use cases, and, depending on the level of specificity the team needs to employ , the workload can quickly overwhelm a small product management team. In other words, the product manager will need to manage the level of his or her involvement to make sure that the product management function is looking at the entire forest rather than individual trees.

In addition, the product manager will often lead the team to an understanding of key nonfunctional requirements, many of which will be driven by external marketplace or business partnering arrangements.

Testing the Product Concept

In an effective product development process, the product concepts will be tested at every opportunity with the customer and user community. Although the necessity for this seems obvious, experience has shown that it does not always happen, and the result is often a significant mismatch between the product and the customer's expectations and needs. Table 17-1 illustrates some recommended user "check-in points" and the contribution that a product manager can provide at each point.

Completing the User Experience

In addition to the activities described above, creating a whole product solution also requires that the product manager attend to a myriad of additional artifacts and details that directly affect the user experience. Some of these, such as user documentation, online help systems, and tool tips, are obvious needs. Others, such as embedded copyright notices, startup splash screens, corporate and third-party component logo compliance, and more, may seem trivial at first, but together they create a significant impact on the user experience (and a potentially significant workload on the development team). Table 17-2 provides a checklist of some of these important artifacts and describes the product manager's role in each.

Table 17-1. Check-in Points for Testing the Product Concept

Check-in Point	Product Manager's Role
Concept development	Facilitate requirements workshops; develop storyboards, presentations, and other "soft" models to elicit customer feedback.
Vision	Primary responsibility for development of the Vision document. Circulate to all stakeholders for review. Collect and synthesize input and drive to consensus.
Use-case model development	Facilitate development and view of overall use-case model. Participate directly in development of key use cases. Mentor use-case authors and review all work. Determine key supplementary requirements.
"Alpha" testing (internal usage and early customer access programs)	Define and monitor this testing process. Define scripts and evaluation criteria to assure that all use cases are tested and all feedback is collected.
Beta testing (first formal customer evaluation process)	Work with sales team to identify and engage beta customers. Define and document commercial terms. Manage rollout and customer expectations. Collect feedback and drive back into development cycle.

Table 17-2. Artifacts That Complete the User Experience

Item/Artifact	Product Manager's Role
User documentation Manuals, online help Other support material: read me files, online help, usage guidelines, release notes, administration and setup notes Supporting software Installation procedures, auxiliary scripts, embedded tutorials, miscellaneous utilities	Participate in concept development, design, and content plan.
User presentation: corporate logo, product logo, and graphic standards	Locate or define standards, communicate to implementation team, monitor compliance.

Defining Commercial Terms

Another set of decisions that must be made before the product is ready for market is those that define the commercial terms of the relationship between you and your customer. These may well be as critical to your product's success as the product features themselves. Although some of these decisions might be outside the product manager's scope or authority, as the primary product advocate, the product manager must be clear that "the buck stops here" when it comes to driving this set of consensus-building and decision-making activities. Table 17-3 highlights these activities and the product manager's role in each.

Table 17-3. Artifacts That Define the Commercial Terms

Item/Artifact	Product Manager's Role
Licensing	Facilitate or define licensing and licensing enforcement policies. Work with development team to define and implement licensing use cases. Work with legal department to draft license provisions. Work with operations team to define and implement licensing mechanisms.
Pricing policy	Facilitate or define product pricing and discount schedule. Work with sales and operations teams to build and distribute price list data.
Customer support	Facilitate or define support policies, including access mechanisms, support levels, service-level agreements, upgrade policies, and pricing for same.

Positioning and Messaging

If the product manager is a member of (or associate to) the marketing department, he or she may also be responsible for product positioning . As the saying goes in retail, the key to success is "location, location, location." In retail, your likelihood of success is in large part based on your ability to attract foot traffic into your store. And people will likely go to your store because it is convenient for them to get there, rather than because of any lead generation or promotion mechanism you deployed to drive them to you.

The same goes for software. But since locations in our industry are virtual , rather than physical, the concept of position serves as a proxy for location. Your company's responsibility is to create a location in your customers' minds ”a position that highlights your product's strengths, minimizes its weaknesses, and ultimately causes customers to select software from your company rather than someone else's. In other words, positioning is how you differentiate your products and services from others in the marketplace.

No matter what you and your product and marketing teammates think of your product, the way potential buyers perceive it will ultimately determine whether or not they will purchase it.

As an organizing technique for positioning, Moore [1991] recommends the starting point shown in Table 17-4.

Table 17-4. Statement of Purpose for Product Positioning

For	(target customer)
Who	(statement of the need or opportunity)
The (product name )	is a (product category)
That	(statement of key benefit, that is, compelling reason to buy)
Unlike	(primary competitive alternative)
Our product	(statement of primary differentiation)
Source: Based on Moore [1991].

If you and your team can agree on this simple statement of purpose, then you will be well on your way to building a solid message platform .

Of course, establishing a position does you no good whatsoever unless you can articulate that position succinctly and memorably to the marketplace. That is the role of messaging . Messaging puts words behind your position and builds a platform you can use to describe the more detailed aspects of your basic selling proposition to customers and others. The goal of positioning and messaging is to help create a competitive advantage in the marketplace .

Your message does not consist of just any old words. Your message contains the specific words and phrases in the specific sequence that you and your extended teams will use to deliver your product message to the marketplace, no matter what vehicle you use (for example, print advertising, Web site, sales presentations, and so on). Moreover, in this day of information and communication overload, they are the only words you should allow the extended team to use to describe your company's products and services. Each member of your company must learn to use the same words, in the same way , when describing your company to outsiders, whether it be trade press, local press, industry analysts, customers, or partners . Otherwise, your customers will become quickly confused , and your message will be lost in the cacophony and constant bombardment of your competitor's more effective promotions.

As you come to agreement on your messaging, it is useful to document your messaging in a core message platform . This document summarizes your basic messages, as well as the product or solution features that support it, in a succinct and focused manner. The core message platform then serves as the basic input to all product marketing artifacts, including the Web site, data sheets, demos, and other sales materials.