When you sign up for email notifications, we ask for your name and email address.
We collect aggregated information on visits made to our pages. This information helps us improve the content and functioning of our site.
HOW IT GETS USED:
We NEVER make any of the personal information we collect available to any other person, company or organization.
If you do not wish to receive further mailings, please contact us at the address below, or follow the "unsubscribe" directions included in each mailing.
TO UNSUBSCRIBESend us a note from our Contact Page with the email address you want to unsubscribe.
Product Arts - Product Management Articles
Bridging Concept to Solution
A recent search on Monster.com for similar job title openings nationwide yielded about 800 Product Managers, 150 Product Marketing Managers, 1,000 Project Managers and 1,000 Program Managers. What’s a Program Manager?
The role of Program Manager in many industries acts in the capacity of super-project-manager - coordinating multiple interrelated projects towards a common goal and often from a business manager perspective. In high tech, the Program Manager role has evolved along very different lines, especially in software development. This article explores this product development role, how it differs from other Product Manager roles, the value it brings to the development process and where things can also go wrong.
The History of Development Program Management
The role of Development Program Manager is credited to Microsoft and where it still has a central role today in creating products. The story goes that the PM (as it’s called at Microsoft) originated when creating Excel for the Apple Macintosh and which had a new graphical UI. The team realized that the developers were paying attention to getting the code to work, in addition to the underlying algorithms and formulas, but nobody was really paying attention to the user experience. These included the usability of the product in addition to the usage scenarios for how people would interact with the product.
A new role was created, called Program Management, with the explicit goal of partnering with development and working through the entire product development cycle as the advocate for end users and customers. Over time, this role also expanded to leading the overall architecture of the product, creating the product spec, and driving the development deliverables and schedule. In different development groups today, the PM’s focus can vary significantly across these different activities, depending on the groups’ needs. A stint as a PM is also considered nearly mandatory as career step towards GM.
Now some of you may be thinking “Isn’t being the advocate for end users and customers the job of the Product Manager”? Or if you’re doing Agile, “isn’t that the role of the Product Owner”? Well, usually yes but not generally at Microsoft. Microsoft does have a Product Manager title, but in most other companies this would be equivalent to a Product Marketing role. While this person helps to identify the high level product opportunities and business case, they generally are primarily focused on the go-to-market activities once the product exits Development. Another less common role at Microsoft is the Product Planner, and whose focus is in understanding the segments and users and defining the product requirements, much like the traditional Product Manager role elsewhere. So as can be seen, there is a different mapping of titles to activities than may be found in other places.
The role of Program Manager is now fairly common in high tech (as can be seen by the number of job openings). Regardless of the titles, in every organization there is a need for somebody to clearly define the product or service (and its evolution) and drive it through the organization and out to the market.
The Case for Program (and/or Product) Management
Let’s take a step back for a minute and talk about the types of activities that go into technology product development, independent of titles. A high level list of activities could be:
In a small or early stage company, these are all accomplished with a scrappy staff wearing many hats, and usually including participation from hands-on founders and executives. There are only a few communication channels to maintain and since the base of customers is small, the operational and business systems are minimally developed. Resources are tight and time-to-market (or more accurately time-to-revenue) is a key driver. The need for formal processes and documentation is very low and is perceived as adding overhead (AKA cost and time). More often than not, you won’t see titles like Product Manager or Program Manager in this environment, because founders or functional leads are performing the needed activities. If the roles do exist, it’s because either a) the founders don’t possess the skill sets to define, build and launch a product or b) the founders have evolved from a larger org that had the roles and feel they are necessary. In both cases there is a need for deeper pockets to be able to fund the extra staff.
As a company experiences success and grows, the organizational structure needs to adapt and grow as well. Adding more people adds more internal communication channels that need to be coordinated. Adding more customers requires formalizing operational and business functions and beefing up their systems so they can scale. This results in more formal processes and longer planning to make changes. The founders and execs need to spend more time running a business with less time available for day-to-day activities. The result is they cannot keep up contact with the growing customer base or in providing coordination of staff. In addition, product development decisions become more complex in balancing the need for new functionality with maintaining existing systems, and within the constraints of existing architectures, systems and processes.
Enter Program and/or Product Management. The purpose of these roles is to help the organization in a few different ways:
There are countless ways to achieve these results and where the confusion comes from in creating titles and defining roles and responsibilities.
Slicing & Dicing, Mixing & Matching
In the table below, we look at the potential product development activities and involvement of different titles in those activities. These roles include Product Marketing Manager, Product Manager, Program Manager, and Technical Product Manager. Their involvement in the activities has been assigned three different levels: Primary, Partially and Possibly. Colors have also been assigned with darker colors indicating increasing involvement in the activity. (Note: this is a generalization and your organization or experience may vary).
The Program Manager is role is unique from the others in two areas:
In organizations without the Program Manager role, these would typically be handled by the Development Manager or Lead. Offloading these activities from the Development team does help to focus their efforts on building the solution instead of on project management.
As with everything in the product development process, there are trade-offs to be made regarding who’s doing what. The biggest downside of the Program Manager role is the dual focus as being the customer advocate AND in being heavily involved in day-to-day development activities and issues. In the Agile software world, this effectively requires the Program Manager to play both roles as Product Owner and Scrum Master, and which are defined as being mutually exclusive roles.
This can create a dilemma for the Program Manager, specifically around feature definition and prioritization. In many situations, the Program Manager is highly internally focused and has little direct interaction with the market or customers. To offset this, the Program Manager needs a strong relationship with a Product Manager (or Product Marketing Manager) who does have the market exposure. This can be a very powerful duo if the individuals are both strong in their specialty and they have a cooperative working relationship.
However, in many organizations there can be an adversarial relationship between Development (where the Program Manager lives) and Marketing (where the Product Manager lives) and a power struggle ensues. The end result is Program Managers make priority calls in order to meet their obligations to “ship something”, but the resulting feature set does not deliver what was asked for or needed. The business results are therefore lackluster.
The Program Manager role can provide strong value to an organization by having an individual driving the definition of the product solution in response to documented customer needs, and in offloading the Development team from project management activities. If coupled with a strong market-facing individual, such as the Product Manager, and with a collaborative relationship, the pair can effectively drive new product capabilities through the organization and into the market. Both roles become product experts, with one side more expert in the market and customer and the other more expert in the product implementation and delivery.
Articles by Popularity
Copyright © 2007-2013 Products Arts. All Rights Reserved.