"PM" Disambiguation

_posts/2021-03-25-pm-disambiguation.md

@@ -0,0 +1,32 @@
+---
+title: pm disambiguation
+description:
+---
+
+
+### Program manager vs. Product Manager vs. Project Manager
+
+"PM" is an overloaded acronym within the software industry, with the easily confused roles it represents both overlapping and varying drastically from organization to organization. Before we jump into things, here's a brief "PM" disambiguation:
+
+#### Product Manager vs. Program Manager
+
+I've [written before](https://ben.balter.com/2016/06/06/twelve-things-a-product-manager-does/) about what a Product Manager does. In short, a Product Manager is customer focused while a Program Manager is execution focused:
+
+* **Product Managers** - Product Managers are responsible for understanding the needs of customers and distilling those needs into a prioritized list of product requirements. Depending on an organization's size or maturity a Product Manager may take on some program (or project) management responsibilities, but it's generally not their core function.
+* **Program Managers** - Program Managers are specialists of and are responsible for the cross-functional and cross-organizational planning and coordination, risk management, and process tracking that gets the product out the door. Program Managers may inform product decisions, but they do not directly shape products or features.
+
+#### Program Manager vs. Project Manager
+
+In the traditional sense, a program manager is a people manager that manages one or more project managers. More recently, you'll see program managers that manage a collection of inter-connected projects, even if the program managers themselves don't have direct reports. Program management versus project management can often be seen through the lens of strategic versus tactical, but there is no bright line between the two as more senior project managers naturally take on more simultaneous projects or more complex projects which can often be seen as (or become) full-fledged programs.
+
+#### Program Manager vs. Technical Program Manager
+
+In short, Technical Program Managers are technical. They don't write code on a day-to-day basis,[^1] but they are at home rolling up their sleeves and diving deep into technical discussions alongside engineers and other subject-matter experts. A technical degree is not strictly necessary, but TPMs are systems thinkers that have a keen understanding of the product and the platform, and may have previously been an engineer or a product manager for a highly-technical product. Again, like project management, there's no formal distinction here, but suffice to say TPMs generally self-identify as technical (even if, like technical product managers, it's not always reflected in their title).
+
+#### What a technical program manager is not
+
+To be clear, TPMs are not the one *primarily* responsible for a program's success. Depending on your organization, those individuals may be assigned titles like "PRP" (primarily responsible person) or "DRI" (directly responsible individual) and often come from Product Management or Senior Leadership roles. The TPMs work closely with and support those individuals, but play a very distinct role. A program manager is responsible for the program's successful *execution*.[^2] As such, TPMs rarely, if ever, make program decisions, and instead, bring PRPs/DRIs the context they need to make those informed decision themselves.
+
+[^1]: Successful TPMs may find themselves regularly writing non-production "manager code" to automate common administrative tasks and help scale their own efforts. There's a discussion to be had whether this should be celebrated or is indicative of a lack of appropriate tooling, but for purposes of disambiguation, technical in this senses is not necessarily synonymous with engineeer.
+
+[^2]: As an example of this distinction, TPMs should ensure that product managers have all that they need to ensure that we're bringing the right product to market, targeting the right customers, and at the right time. If ultimately the product fails to find a product-market fit due to its feature set, its priced too high, or gets the go ahead to launch with a few too many bugs, those decisions are on the program/business owner, not on the TPM.