What is product management - or - If you call me a project manager, you are dead to me
Defining "product manager" is like agreeing on the definition of barbecue. In this post, let's shoot for a Maserati but deliver a sticky skateboard (product manager joke) to describe the role of a PM.
Ah, "Product Management." Probably one of the least understood roles in software, and even more so outside of the charcoal toothpaste drool bubble of Silicon Valley.
This would all be a lot simpler if we as an industry could just agree on one definition, but, like my childhood inability to agree with my siblings on choosing which Back to the Future movie to watch (the first one is always the correct answer), that's why we can't have nice things.
The definition of "Product Management" varies widely across organizations and pockets of rabid ivory tower Agile purists who have argued for years about Product Owner vs. Product Manager.
Depending on the organization or the whims of its senior leaders, product management can include marketing functions for some, operations management jobs for others, business development, and customer support roles.
Product management is a slab of slathered meat
In my experience, while you can spout off the platitudes of what product management can be, the definition of the product manager role varies like regional persuasions for barbecue.
If you're in Kansas City, we're talking sweet, thick, and smoky. In the Eastern Carolinas? Vinegar and pepper flakes. Central Texas? Sauce, if at all, is typically served on the side.
I'm more of a Kansas City-style manager of product teams, but I could easily go Eastern Carolina during the quarterly business review. I'm likely not Central Texas though, because I like a good sauce, and I don't like the footwear.
Am I drawing a clear, direct line between each regional barbecue style and specific product management flavors? Not really.
But that's because product management is more like the barbecue you'll get in a massively diverse state like California. It varies widely depending on the neighborhood, and the recipe probably didn't originate there (with some notable exceptions, like Cardiff Crack).
Like barbecue, a product management style can be like splendid culinary wizardry or an overcooked hotdog from a gristly 7-Eleven roller grill.
Product Management explained to normal humans with lives and cats
When I'm asked by regular, non-tech industry people what I mean when I say I'm a product manager, I describe it this way:
"You know how when you use AppleTV and hate it when the stupid auto-play on Amazon Prime videos seems to turn itself back on after you finally figure out how to turn it off?
Or when the Costco app can't find "Bratwurst" even though you are standing in the aisle looking at it?
Or when Meta hides the Facebook customer service info really, really deeply in their convoluted menus to dissuade you from asking support for help for your grandma's hacked Facebook account?
There is a person to blame.
That person is me."
Or, sometimes I say:
"My job is to figure out what frustrates customers, convince a team of engineers to build a solution, and then give that to customers to see if they like it."
Cute, huh?
Like the 1-click purchase button? Product likely had something to do with that.
Or an app that makes savory and deliciously insulting jokes about the weather? Whether in title or at heart, a product person definitely had something to do with that.
Or the "buy me a coffee" experience - one you need to drop everything and try out right now with a credit card with a very, very high limit to believe how wonderful it is (see what I did there?)? A PM for sure is involved. Or is about to benefit, if you catch my drift.
What people think I do as a PM vs. what I actually do
Product management, as described above, is often drawn as a pure, neatly defined Venn-ish diagram of effervescent, friendly, and not-grumpy-at-all stakeholders in an idyllic, hand-holding meritocratic circle who want nothing more than to make everybody feel welcome, loved, and heard, with product managers in the comfy bean bag chair center.
There may be singing involved.
Something like this:
In reality, on the day-to-day, product management is much less bean bag chair hugs and much more crunchy on the outside and a chewy center - kind of like this:
There's a lot of agreeing-to-disagree, smile-crying in your cornflakes, and unabashed people-pleasing to try to get something, anything, done.
This is also made much worse by some pretty famous PMs who do all of these things simultaneously, seemingly flawlessly, and then talk about it on stage - setting an impossible bar for normal humans with lives.
So, what exactly do product managers do? And what don't they do?
Let's try again, but this time with feeling.
What product management isn't
Before I tell you what product management is, let’s get this out of the way:
Product Management is not Project Management (well, I mean, it is and it isn't, but most PMs I know don't have a Six Sigma tattoo on their palm - not that there's anything wrong with that)
Product Management is not Program Management (nope, but also, yeah, kind of sometimes it is)
Product Management is not People Management (unless you are a manager of product management, and then all bets are off)
Product Management is not Product Operations (well, except at most companies and especially with the misapplication of DevOps culture, it kind of is)
A Product Manager is not the same as an Agile Product Owner (though the jobs are often done by the same person, so isn't it then?).
We perform many of those duties, but none of those on this list are our primary objective (or the means by which we are measured).
Sidebar: Project vs. product - one of these things is not like the other
The theory of project vs. product roles and responsibilities has a straightforward distinction. It goes something like this, from Coursera:
Product managers and project managers often work together, but they have distinct roles. While a product manager sets the vision, goals, and business trajectory of a product, a project manager leads the many projects to make those goals a reality. [...]"
This description is reasonably OK, but fair warning: That article goes on to suggest that project managers are more doers, and product are more non-doing strategizers.
This is false. If only.
Good project managers are exceptionally strategic, and are critical partners to delivering successfully. They may not be responsible for creating the initial vision and strategy of the entire product (that's product land), but it takes an incredible amount of strategy to create a milestone and delivery plan and drive projects to completion.
Product managers do all their product manager-y things (more on this in a minute), but the good ones are also exceptional doers. The corporate overwrought phrase is a “bias toward action,” which I have definitely said to my teams and therapists.
Whether it's customer engagement, leadership communication, or prioritization - all of these things involve a significant amount of doing and making sure things get done.
I will concede, however, that the distinction gets blurry. In practice, nearly every product manager will eventually play the role of a project manager as you try to get things done. You will be measured by your ability to deliver on time and on budget, in addition to the other critical product responsibilities, which blends the roles (particularly if the company has let go all of the project managers, which is a thing).
That said, please don't call me a project manager. I'm not qualified to wear that badge and I don’t know the secret handshake. I won’t be offended, but I may make demure faces and avoid eye contact. Like I’m doing right now.
To quote some of the most influential philosophers of our time, Donny & Marie, product managers and project managers are "a little bit country, a little bit Rock 'N Roll."
I'll leave it to you to figure out which of us is which.
OK, so that's not an answer. Let's go dig for treasure in the Cave of Corporate Statements®!
Clearly, the best way to find an answer is to ask the industry authorities, right? Let's give that a go.
Atlassian, one of the most ubiquitous software tooling platforms used by most tech PMs, defines it as follows:
"Product management is an organizational function that guides every step of a product's lifecycle — from development to positioning and pricing — by focusing on the product and its customers first and foremost. To build the best possible product, product managers advocate for customers within the organization and make sure the voice of the market is heard and heeded."
That definition is satisfactory but very corporate-y and would make little sense to most people outside the tech world. But it's OK—considering they sell Agile products for software development—I'll allow it.
The folks at Product Plan have a pretty good one:
"The two primary responsibilities of PMs are to set the long-term vision and strategy for the company's products and then communicate this strategy to all relevant participants and stakeholders."
That is accurate.
But the Devil is in the details.
So pull up a chair, grab a mason jar of cheap Jack Daniels and some sweet tea (heavy on the Jack), and let's dig into what is actually involved.
Oh, and here's a wet wipe for that barbecue sauce.
"The Details": The neighborhood where the Devil lives that I just mentioned
While those clean divisions of vision- this and customer- that sound nice, the work of a product manager is typically much messier in practice.
For most PMs, developing every new product or feature looks more like this - and every step is done in a very pressured hurry, not to mention the order is not always in a straight line:
Quickly understand and evaluate the problem, target personas and markets, competitors, technologies, and your company goals and positioning. This is where we should spend the most time but often get the least opportunity to do so.
Assuming the problem has merit, assemble a straw man strategic plan + roadmap that aligns with the company's key objectives, then plot that against a roughly estimated proposed timeline (meaning, is this for this year, or next year, or maybe never?). Or if you're in something like eCommerce driven by seasonal constraints, a committed timeline if your business is seasonal, or it operates based on time-driven sales promises to customers (not advised, but reality for many)). Timelines and roadmaps are often conflated, but they are very different things with different audiences. More on that later.
Ideate solutions, pick one, and then assemble a UX+development plan with input/estimates from the teams involved (design sprints if you're lucky), gaining consensus on defining the problem, requirements, and technical solutions. This is often in the form of Epics and Stories in an Agile tool like Jira.
Prioritize the work and negotiate communications cadence and delivery from teams on which you depend.
Adjust timelines to match feasibility, thrill a few stakeholders, and simultaneously be the bearer of bad news to other stakeholders who want different things, that plans changed, and they are SOL for now.
Communicate the plan, like, a lot:
Internally, via quarterly planning, roadshows/roadmap presentations, check-ins across teams and organizations, leadership briefs, alignment sessions, slide decks, brown bags, secret face-punch clubs (just seeing if you’re paying attention), etc.
Externally, to customers via announcements, presentations, and on key customer calls (depending on how your org does things)
Emphasize, often in vain, that "this is not a commitment, but a projection!" Then, understand that you'll be held to your projection as if it is a commitment because 'the business' does not deal in projections.
Coordinate development: Kick off, cheerlead, and steward, clearing the path of obstacles for the team(s) and ensuring everybody stays on course. You are also the chief inspiration officer, internal sales lead, team subject matter expert validating that the outputs match the desired outcomes, and the person responsible for adapting plans as needed/more info becomes available. This is where things get dicey on the overlap of product manager and product owner expectations, but I'll save that for another time.
Throw yourself on the extraneous meetings grenade to save your team the context-switching tax, take out the trash, and bring snacks.
Drive all of the teams involved forward to completion, which means a lot of meetings to ensure your work remains prioritized. Sometimes, on bigger efforts, you get a partner to do this in the form of a program manager, but usually, you do this yourself.
Be the face of the product for recurring senior leadership updates, where you either get support, new directions, or eviscerated. One never knows before you run that gauntlet, though you should be priming those leadership conversations in advance as a preflight check for the big meeting (pro tip).
Ensure monitoring, accessibility, legal, docs, security, and IT are all sorted as potentially deadly ducks lined up in the adjoining bowling gutters.
Get the go-to-market machine rolling, which may involve bringing in outbound product management teammates, doc teammates, developer relations (if you're a developer platform), customer support + success, sales, etc.
Build customer anticipation through demos, talks, and calls with key customers.
Drive the solution's testing and get the bugs into the backlog. Although a PM is not generally the official QA person, PMs almost always test alongside their teams. Hands-on is the only way to go.
Make hard decisions about what the team must fix vs. what will become tech debt.
Last mile: If the change is big enough, tweak and present the final version to key stakeholders and/or present it to your organization at regular planning ceremonies to show off what your team did. If all is not well, get creative, pivot, and keep it moving. Cross T's, dot I's.
User acceptance testing (UAT) and training sales/support on how to use the new thing.
If you have made it this far, it's time to launch it. Stay calm. You can sleep later. Turn your key, Captain. Get religion.
It's live—now monitor the usage, address bugs, put out fires, and ensure it's operating as intended. Try not to panic when things go sideways, as they can easily do with new things.
Talk to more customers to get feedback, research new problems, and repeat.
And even that is just a simplified view. That list doesn't include additional expectations like:
Constantly improving your domain knowledge ("Hey, so what do you know about AI datafication for quantum genomics accelerators leveraging AI-optimized edge tech? Because that's where our innovation team says candy bars are going.").
Continual relationship development and trust-building with individuals, teams, and organizations.
Contributing to the Product organization's goals via meetings, side projects, and team exercises.
Being a mentor to other PMs to help raise all ships.
Staying on top of industry trends and new tech.
Attending and creating team-building semi-drunk bowling events to build trust and share foot fungus with your engineering teams.
Enough detail. Just give me a short list. Fine. Two lists.
Way oversimplified and in pillowy, delusions of grandeur terms, product management in software typically involves this lifecycle:
Discovery + product market fit + strategy (good work if you can get it - and frankly, most PMs at larger companies, and especially technical PMs, don't get to do this part much)
Define, Plan, and Communicate: Gather requirements, partner to produce solutions, settle on strategic alignment, and constantly communicate. This includes design sprints with UX, engineering solutions with dev teams and architects, building and presenting roadmaps, and creating and sharing delivery plans.
Build and Launch: Partner with engineering to build it, cross-team coordination, evangelism, and stewarding through delivery (where things get tricky with Agile), and engage customers.
Observe and refine: Use qualitative and quantitative data to determine how the product is received and what to build next.
Repeat: Do it all again with the next shiny thing (ooh, shiny)
Easy enough, right?
Beyond the participant and driver of the product lifecycle, you are:
The person whose job is to understand your customer better than anybody else and whose sole goal is to make things they will use and like.
The trusted partner and politically savvy communicator to every business stakeholder, engineer, IT person, marketing and sales team member, outbound product person, and all concerned individuals between. And yes, I used the "P" word because it's the truth—every large organization is on a spectrum of political-ness. Hopefully, it's on the very low side vs. the ultra-political, but it's reality, and as a PM, you're in the middle of it more often than not, and it only gets worse as you advance.
The driver of delivery as an Agile PO is a significant segment of your responsibilities.
The champion of the product and chief customer advocate. You are the customer’s wise and energetic proxy, shouting in virtuous opposition to the howling banshee wind of corporate initiatives, infrastructure upgrades, security compliance tickets, and vendor migrations bearing down on your team.
And, lest we leave out another truth, the PM is the attendee, wrangler, and peddler of meetings. You conduct and attend a shit-ton of meetings. Your daytime hours are often consumed with talking about doing work in endless meetings rather than actually doing the work (which you do in the evenings and on weekends). There are ways to fix this, but this is the most common for most PMs.
There are a million other parts to this (people managing, for example, helping to hire engineers if you get budget, or pitching in front of finance if you're struggling to show positive revenue impact), but these are the basics.
If it feels like a lot, that's because it is.
Wrapping up - or - If you want a serious answer, you should probably ask these folks
While I'm clearly having a little fun with this, there are some excellent straight answers from people much smarter than me.
The following links are probably the most definitive and poignant articles (wow, do I use 'poignant' in real life? I do now, apparently). They come from Marty Cagan and company at the Silicon Valley Product Group, who, in my book, really set the standard for much of what we do and should do and realistically get wrangled into doing sometimes unwittingly. So, if you are curious about what real product management, especially in software, looks like, go read these.
That's it.
Talk to you next week.
Jeremy
Question: what is the charcoal toothpaste drool bubble of Silicon Valley? This is my first time hearing that phrase. 😅