Customers and partners who want to influence the direction of Microsoft products or exploit the company's marketing machine must understand two jobs at the company: program manager and product manager. Program managers are responsible for the features and early direction of a product while product managers handle its marketing through launch and beyond. Understanding the differences between the two roles and their goals can help customers and partners work more effectively with Microsoft.

Program Management Explained

Product development at Microsoft is decentralized, and every product group is free to use whatever development processes best suit its needs. However, one of the few constants across the company is that every product group contains at least the three following roles: development, quality assurance (sometimes referred to as QA, or testing), and program management.

Most customers and partners have an intuitive understanding of development and QA ("write the code" and "test the code," respectively) and use those disciplines within their own development teams, but few fully understand program management.

The presence of the word manager leads some outsiders to believe that program managers have management responsibilities for developers. This is wrong: program management is its own career path, and is a peer to development and QA. For customers and partners, program managers are the most visible members of the product team because they are the connection between customers, marketing, development, and testing. "Program managers are the ones bridging the customer requirements with the people who implement them," according to Bob Muglia, senior vice president of the Enterprise Storage Division and a 14-year Microsoft veteran who led the program management team for the initial release of Windows NT. "They are the place where everything comes together."

Microsoft uses a number of variations on the title "program manager"—including "lead program manager," to reflect a program manager who has other program managers as direct reports, and "group program manager," to indicate a program manager who has responsibility for a major product and team of program managers.

Four Roles of Program Managers

No matter their specific job title, program managers across Microsoft fill at least one of four (and sometimes all four) fundamental roles:

Creating and maintaining specifications. The most common role of program managers is to create, gather feedback on, and maintain detailed product specifications. These specifications must describe every feature of the product, the scenarios under which each feature will be used, how each feature should work from the user’s perspective, and the dependencies each feature has on other teams, either within the product group or with an external team.

Program managers must then review these specifications with the developers and testers responsible for creating and testing the feature, with the group program manager responsible for the product as a whole and, if the feature is particularly important, with the product manager responsible for marketing the product.

Later in the product cycle, program managers must also decide, with help of development and QA, how to cut or simplify features and update the specifications appropriately. Part of this process is "triaging" bugs—deciding which bugs are important or severe enough to fix, and which fixes can be safely postponed until later releases.

Owning the schedule. The second role for program managers is maintaining the schedule by which the product is developed, tested, and shipped. Program managers responsible for the schedule must work closely with the development manager to plan and schedule product milestones, and work with QA to track and understand the overall bug count for the product.

Given the interdependencies between Microsoft products, tracking the schedule for one product often requires understanding the schedule of related products as well. For example, because all of the developer tool products (Visual Basic, C++, and C#) ship as an integrated suite, the schedules for each of the products must be coordinated.

Knowing the customers. To a certain extent, all program managers must know and understand the customers for their product. However, some program managers are the primary customer advocate within a product team. These program managers (sometimes referred to as "product planners" within the Office team) try to understand the key difficulties customers have and problems that must be solved in the next release, even though they may not specify the exact solutions. They also work closely with early adopters, and might be involved in demonstrating the product to potential customers.

Managing internal relationships. As Microsoft has grown and its products have become more interwoven, product teams have developed complex interdependencies. Many products, for example, rely on specific new features in Windows. On the other hand, since Microsoft product development is fundamentally decentralized, product groups often have conflicting plans, and in some cases, multiple product teams might be developing different solutions to the same problem. For instance, both Exchange and SQL Server were working toward creating a universal storage technology for Microsoft products, and both the NetDocs and the Office team were at one time developing competing software to enable Web-based document sharing and collaboration. Program managers must manage these dependencies and cross-division rivalries in order to avoid large-scale duplication of effort that can lead to customer confusion or even projects being cancelled (as happened with Exchange universal storage and NetDocs).

Smaller product groups might contain only three or four program managers, requiring individual program managers to fill multiple roles. On larger teams (such as Visual C++, which at one point had 25 program managers), individual program managers tend to specialize and fill a single role for the entire product cycle. There are no hard-and-fast rules for the size of program management teams, but many groups aim for a ratio of 3:2:1 between development, QA, and program management. At most, a single program manager can handle four developers.

Program Management versus Product Management

The largest source of confusion for customers and partners stems from the similarity of the titles "program manager" and "product manager."

Product management is a marketing position, not a development-related position. As such, product managers are responsible for typical outbound marketing activities, such as planning packaging and stock keeping units (SKUs), identifying customers for case studies, creating marketing materials for use by the sales force, and working with public relations teams to handle press contacts.

The two positions sometimes overlap. In product groups that have a large number of less-technical customers, such as Office or Windows, product managers also give product briefings to critical customers; in groups where the discussion is likely to be more technical in nature, such as developer tools and the .NET servers, program managers fill this role.

The most important distinction between the two titles is their ability to affect the feature set of a product. Although product managers can influence the feature set of a product, they do so only indirectly, through the review process for critical specifications and one-on-one interaction with the group program manager. But ultimately the program managers determine the design and feature set of the product.

Working Effectively with Product Groups

In order to work effectively with product development groups at Microsoft, partners and customers must first identify who they should be working with—program managers, product managers, or some combination of both.

In some cases, such as planning co-marketing, being the subject of a case study, or getting a third-party product mentioned on stage during a Microsoft product launch event, third parties should work with product managers. Local field sales offices can often connect partners with the appropriate product manager.

On the other hand, customers or partners who require in-depth explanations of a product’s design, or who want to influence the features of future releases, are usually better served by working with program managers. Unfortunately, it can be difficult to communicate directly with a program manager. In some cases, Product Support Services (PSS) is able to escalate issues to a program manager. In addition, program managers often give technical presentations at events such as TechEd or Microsoft Professional Developer Conferences (PDCs), giving customers and partners the opportunity to develop relationships with them.

Partners who want to have their product bundled with Microsoft’s products (in a similar manner to the way in which Crystal Reports is bundled with many Microsoft applications) will typically need to work with both product management and program management. When seeking these relationships, however, they must understand that program managers must ruthlessly manage dependencies. Each dependency a product has upon another group, either within Microsoft or with an external partner, represents an element of the schedule that is beyond the product group’s control and could cause a product date to slip.

In addition, product groups often have a relatively short window of time in which to add new features to a product. It may seem unreasonable that a team does not have time to make changes as far as 12 months before shipping, but the fact is that new features (or changes to existing features) require code to be written or altered, test suites to be created or re-run, and documentation to be altered. To complete these tasks and manage dependencies, feature sets are usually decided very early in the product cycle. The most common change made later in the product cycle is the removal of a feature that failed to pass muster during testing.

As a result, a program manager's initial response to any request is likely to be a firm "no," and partners and customers must be prepared to understand why if they want to work effectively with program managers and get a more satisfactory result.

Resources

While Microsoft does not publish complete job descriptions on its Web site, it is possible to get an understanding of the differences between program management and product management by looking at the job postings at www.microsoft.com/jobs.

Microsoft Consulting offers the Microsoft Solutions Framework, a design and development process that is loosely based upon Microsoft’s internal development practices, although the use of program management in the Solutions Frameworks is considerably different from that used internally at Microsoft. Information on the Solution Framework can be found at www.microsoft.com/business/services/AppTeamModel.asp.