What does a software program manager do anyway?

Asking what a program manager (PM) does in the software industry is a bit of a trick question because so many different and only tangentially related positions are called PM. So I can't provide a universal answer but I can explain what the PM groups I have worked with over the years have done/do. The short answer is that we are the conduit between the core Development team (e.g. Development/Test/PM) and the rest of the known universe. Our job is to bring data from the outside world in, bring the core Development team's ideas out to the world, negotiate a "contract" between the two as to who is to do what/when and then be held personally responsible for making sure everyone honors the "contract".

All hailing frequencies are open

A Development team (e.g. Dev/Test/PM) has to interact with numerous other groups of people, both internal and external to the company. To enable Dev and Test to focus on writing and Testing code it falls to the PM team to act as the conduit between the outside world and the Development team. We are the hunter gathers who go out into the wilds to find what is to be found and bring it back to the team. We are also the group's envoys, bringing the group's message to the outside world. The end result of these interactions is a contract of sorts where the outside world makes promises to the Development team and the Development team makes promises to the outside world. As PMs we help to negotiate this theoretical contract, it's our job to make sure that there is an agreement and that everyone is clear as to what the agreement is.

Creating these notional contracts is a difficult job because nobody reports to the PMs. A PM's only 'power' is their ability to influence the parties involved through the strength of their arguments. Once the "contract" is set it's the PM team's job to make sure the terms of the contract are honored. In other words that those who owe the Development team deliverables do deliver as promised and that the Development team ships/maintains the product as promised. This means carefully monitoring everybody, tracking compliance, identifying issues early and then working to resolve those issues or at least limiting the damage to all involved.

The groups a PM team will work with vary wildly depending on the exact nature of the product but below is a sample of groups I've dealt with over my career:

• Dev & Test – First and foremost the PM team answers to the core Development team. The PMs have to build a deep relationship with the rest of the core Development team such that the rest of the team will trust the data that the PMs bring back and trust the PMs to act appropriately on the core Development team's behalf. The PMs, working infinitely closely with Dev and Test, drive the process of getting agreement on exactly what the core Development team will deliver. PMs can never forget that they are only effective to the extent that they help to craft an agreement that Dev and Test feel complete ownership over. Once agreement is reached the PM's then work with Dev and Test on writing specifications, driving bugs and whatever else is needed to successfully deliver the product.

• Customers – It is the PM team's job to gain a deep understanding of what the customers need as well as what they want and to bring that understanding to the Development team. For projects with a small well defined group of customers the PM team will interface directly with the customers on behalf of the Development team. For projects with large customer bases the PM team is responsible for collecting enough data to be able to act as stand ins for the customer base when negotiating deliverables and schedules with the core Development team.

• Development Dependencies – Most Development teams have dependencies on other Development teams. The PM team will drive negotiating a contract with the other team's PMs, monitor the other team's progress closely, identify any potential compliance issues early and figure out how to deal with them. At the end of the day it is not Dev or Test's job to make sure dependencies deliver, it's PM's job.

• Operations – If the product is a service or has a service component then shipping means having computers available, routers configured, DNS names set up, etc. It is the PM's job to make sure that the hosting environment is as needed to successfully launch/run the product. Once the service is live it's the PM's job to ensure that the SLA are defined, can be monitored and are kept. SLAs, after all, are just another form of contract.

• Business Development – PMs on the teams I have worked for typically aren't MBAs so there is usually a separate dedicated Biz Dev group. The PMs however own interfacing with that group in order to ensure that issues like pricing, terms of use and profitability are addressed. PMs are responsible for the complete success of the project so even in areas like Biz Dev it's the PM's job to ensure the right thing happens and if it isn't happening to escalate as appropriate.

• Marketing/Evangelism/PR – At a minimum PMs usually interface with these groups to gather data on what customers want. But eventfully the PMs will need to promote their product and these groups are critical in that process. The PM's job is to work with these groups to ensure these groups will be willing to promote the product when it is released. In the companies I have worked for, if these groups don't like the product they will push back, hard. So it behooves the PM to engage these groups early and make sure they believe in the product direction and schedule.

• Legal/Privacy – Especially in the services world the legal and privacy landscape can be dizzying. Every country has its own laws and traditions about how privacy is managed, how and when children are to be given access to a service, how to deal with government requests for data, etc. It is the PM's job to work with legal and privacy to identify the issues early, get agreement on their resolution and to ensure those resolutions are implemented.

• Vendors – More and more teams are hiring vendors to perform jobs that are either too specialized (such as UX design/implementation, penetration Testing, etc.) or not sufficiently difficult to merit the team's direct attention (adapters, internal tools, etc.) It has generally fallen to the PMs to hire, negotiate contracts and manage these vendors and their deliverables.

The word 'ensure' is used a lot above. This is because in many cases the PM isn't delivering the end product, they are just making sure the end product is delivered. The PM probably won't be providing tier 1 support on a service at 1:00 am but it's their job to make sure someone is. The PM's probably won't write the terms of use (TOU), but it's their job to make sure the TOUs are written.

Also note that while the PMs handle the bulk of external communication, that is, after all, their jobs, this in no way means that Dev and Test are cloistered away. It is extremely healthy for Dev and Test to have contact with customers, dependencies, etc. But it's one thing for Dev and Test to have experiences with customers/dependencies/etc. it's another thing for them to have to spent considerable time managing these relationships. It is the later task that the PM position was created to handle so Dev and Test could focus on Development and Testing.