Product management covers a wide array of activities from market analysis to on-going sales support. In a small company, product managers often act as a product release expediter, ensuring that all the scheduled work has been done and that nothing has fallen through the cracks. As a company gets larger, product management takes on additional strategic duties previously performed by the senior executives such as market analysis, writing business requirements, and defining positioning. When a company expands to multiple products and product families, firms must integrate a broad set of skills among multiple product management professionals. How does a company address the challenges of multiple products and product managers?

Product management is all about scalability. As products and companies grow, so do the time demands; one person cannot do everything. So one product manager becomes two or three, each attempting to do whatever is necessary for product success. The more people we add, the more we find two people doing some things and no one doing others. Communications problems are the result of unclear spheres of responsibility. Let’s explore some techniques for ensuring clear communications when there are multiple products and multiple product managers.

Requirements reviews

Many companies are now running requirement review meetings, achieving the same benefits as developers? design review meetings. Requirement reviews can be implemented instantly without impact on the current company organization. Bringing together product managers from across the company puts an incredibly diverse set of skills in one room. Are the requirements well-written? Have they clearly articulated the problem (and not a proposed feature)? Can they be verified? Are there cross-product opportunities? Requirements reviews provide a forum for integrating products and features by leveraging the skills of all product managers.

The product roadmap is a critical planning tool that communicates the deliverables of the suite and of the products. By reviewing product requirements with the group, this forum intercepts many of the miscommunications that occur within a product team and across product lines. [Read more about Product Roadmaps.]

Product management triad

For large products or product lines, the span of activities quickly become more than one person can realistically perform. Requests for product management attention exceeds the time available for one person. But when there is more demand than supply, product managers usually spend their time in their personal comfort zone. A sales-oriented product manager will support the sales channel with better presentations and sales tools, while a development-oriented product manager will spend time with the product features.

In this scenario, companies frequently assign multiple product managers to a single product. An ideal organization is one that separates the roles of product management and product marketing. Often called inbound and outbound marketing, product management focuses on market requirements and working closely with development, while product marketing defines a go-to-market strategy and works closely with Marcom and Sales. These two categories of activities usually involve vastly different skills, so it’s logical to split the job in two. Many companies go further to define a third, business-oriented, strategic role staffed by a senior person. Called the product management triad, this triumvirate works as a team to meet the product needs in the areas of business, technology, and marketing. Read more about the The Product Management Triad.

The Triad works best within a single department. There is an incredible temptation to move the technical product manager into Development and the product marketing manager into Marketing. But this usually fails. The TPM becomes a gofer for Development; the PMM becomes the company ?demo boy.’ By reporting to a senior manager responsible for strategy, these three are bonded together with a common goal. A strategic view of the product family is critical in large companies. The product management triad encourages strategic thinking in concert with product planning and launch.

Multiple product managers in a product suite

Large product families have many products and features that require product management attention, particularly in identifying the links and cross-product opportunities. To manage a large product line, product managers are assigned to each major product in the family with an additional product manager ensuring consistency between the various products.

Imagine an enterprise implementation with a server-based architecture, various client components, and implementation services. Coordinating these components into a coherent release plan is incredibly challenging. For example, an enterprise network fault management system has server-side monitoring and response mechanism running on a third-party database. There are various clients including an error-correlation display, various map views of the network, and an operator console showing outstanding faults pending correction. Installation and implementation services are a critical aspect of the offering. Each of these must be defined, built, and launched. Releasing these as a single coordinated offering can be a nightmare.

In a simplified example, consider how multiple product managers might approach Microsoft Office, a suite most of us are familiar with. Assign a product manager for the Office family architecture including APIs, common look-and-feel, shared features such as dictionaries and themes, and various cross-product opportunities. Then add a product manager each for Word, Excel, PowerPoint, Access, Outlook, Sharepoint, and any other products in the suite. Each individual product manager focuses only on the needs of his product while the suite product manager reviews the requirements for each of the products. PowerPoint needs to have tables; so does FrontPage–the suite product manager realizes that she already has tables in Excel. So she requires a grid-tool API from the Excel team and mandates that any team requiring tables in their product shall invoke the Excel API. This ensures consistency across products, is better for clients, and is better for the Development teams, allowing them to focus their energies on new functionality. There is no need to reinvent a feature that already exists.

Frequently, companies attempt to create architectural services and also implement those services in the client in the same release. This is terribly difficult and beyond what most companies can realistically achieve. A more reliable technique is to employ frequent, staggered releases. Architecture features in release 1 are implemented in client components in release 1.1. In other words, complete the basement before you build a house on top of it.

In the Office example, the Excel team completes the grid API in one release; the other products use that API in their next release. This way, the API doesn’t become a critical-path for a product that relies upon it. Of course, in the ideal, theoretical world, the API would be available as planned and could be incorporated into the current project, but this rarely happens in real life.

A product roadmap for the family of products provides a simple view of all these intricacies. Release schedules for architectural services are shown in the roadmap and can be incorporated into the distinct products that need those services. The roadmap explains the need for staggered releases, each release of one product building on the prior one of another.

Industry-focused product management

How can one product be marketed to multiple industries? After all, the features needed for automotive manufacturing may be different than those needed by financial services. In this scenario, industry product managers gather industry-specific requirements for all products in a suite and deliver them to the suite product manager.

An industry product manager must know the requirements of the industry. Domain knowledge in the industry allows the product manager to convert feature requests to the root problem. Domain knowledge is also necessary to define a go-to-market strategy. Typically, the industry manager performs both inbound and outbound functions although larger companies split these roles into the same basic product management triad described earlier. The industry manager is responsible for identifying industry problems in a Market Requirements Document (MRD). The industry manager also modifies the product positioning to make it resonate with the industry and defines a go-to-market strategy based on the positioning.

Where some companies have defined industry-specific versions of their products, others prefer to deliver industry-specific releases to their markets. An industry-specific release delivers a necessary feature set designed for an industry. Release 2.1 delivers the features needed by automotive manufacturing; release 2.2 delivers the features needed by financial services. Again, a product roadmap is the tool to use showing delivery of features by industry.

International product management

Aren’t product requirements and market messaging the same for every country? No! Just as some verticals need a feature that others don’t, different countries have different requirements and different go-to-market strategies. A company serious about selling worldwide has product management and marketing resources in each major geographic market. To do it right, each country needs professional marketers–not the office admin, a good sales person, or the local general manager. For companies with an international strategy (and shouldn’t that be all companies?), local product managers gather requirements and deliver them in the form of a Market Requirements Document (MRD) just as the industry product managers do. The challenge of bringing all these together in a coherent release falls to the product suite manager.

How many product managers?

The Pragmatic Institute Framework serves as a vehicle for defining product management. Review these activities by product, by industry, and by geographic market. Does your company need product management attention in all of these areas? If so, who will be responsible? And how many hours per week should be allocated?

The typical product manager has worldwide responsibility for three products. This can’t possibly be a successful allocation.

Does it sound like we need more product management? Here’s how to find out.

For each product management activity, estimate the hours per week that the product manager should spend by product, by industry, by geographic market. Add it up. Divide by the number of hours in a typical week. Voila! That’s the number of product managers you need. The typical U.S.-based product manager works 67 hours per week. For planning purposes, 40 hours/week is a more realistic estimation amount, leaving 27 hours per week for all the unplanned activities.

After staffing to the needs of the product, industry, and country, a product roadmap ensures that all product teams are in sync. The product roadmap is a critical planning tool that communicates the deliverables of the suite and of the products.

Large products have large needs. Multiple product managers ensure that all products, industries, and markets get the corporate attention that they deserve, that Development understands the product requirements, and that Marketing has coherent positioning. Multiple product managers need communication tools, such as requirement reviews and product roadmaps, to ensure that all teams are in sync, so that we can deliver integrated products that people want to buy.