Production 101 - #7 What Does a Product Manager Do?
The role that changed how live-service games actually get run
Live-service games created a gap that producers weren’t built to fill: ongoing strategy, player data, and long-term product health.
The Product Manager role came from outside the games industry and was adapted for live operations once the industry realised the scale of what it was managing.
A good Product Manager owns the “why” behind every decision - not just what ships, but why it ships and what it’s meant to do.
The producer/PM partnership is a division of labour that genuinely works when both sides understand where their responsibilities start and stop.
This is part of the Production 101 series. If you’re new here, start at the beginning.
Back when I first started working with external publishing partners on smartphone games, I didn’t know what a Product Manager was. I knew what a producer was. I was one. I thought that covered everything.
Then I met the PM from one of our partner studios. She walked into the room with a deck full of retention curves, engagement metrics, and a three-year product roadmap. My instinct was defensiveness. Who was this person, and why were they talking about my game?
It took me an embarrassingly short time to realise she knew things I didn’t. She understood why players churned at day seven. She knew which content cadence held a player base over twelve months and which one burned it out. She was thinking about the game two years past launch, and I was thinking about the next milestone.
That shift in perspective changed how I work. And it’s the best lens I know for explaining what a Product Manager actually does.
The Product Manager role didn’t originate in games. It started in manufacturing and consumer goods - Procter & Gamble are often credited with formalising it in the 1930s. The core idea was straightforward: someone needed to own a product’s lifecycle and make sure it kept meeting market needs after launch. As software companies grew, the role evolved to cover strategic planning, user research, and cross-team coordination.
Games borrowed the role when live services made it necessary. In the boxed-product era, you shipped the game and moved on. Post-launch support was largely customer service and patches. The producer’s job was to get the thing out the door in good shape.
Live-service games broke that model completely. A live game isn’t a product you ship - it’s a product you operate, indefinitely, while players are watching. You’re running events, managing economies, responding to player behaviour in real time, adjusting monetisation, planning content six months ahead, and doing all of this while keeping the existing player base happy and trying to bring in new ones. The complexity isn’t incremental. It’s an entirely different job.
“A live game isn’t a product you ship - it’s a product you operate, indefinitely, while players are watching.”
The producer’s job didn’t disappear. It narrowed. Producers became the people who delivered the work: managing teams, schedules, and development pipelines. Product Managers became the people who defined what work to do and why. That division of labour is the core of how modern live-service studios are organised.
What the Product Manager actually owns
The clearest way to understand the PM role is through the concept of “the why.” The live ops team handles daily operations - scheduling events, managing builds, pushing updates. The PM is responsible for explaining why any given event is worth running, what it should achieve, and how success gets measured.
This sounds obvious. It rarely is in practice.
Without that layer of ownership, live-service teams default to shipping what worked last time, or what’s easiest to build, or what someone senior suggested in a meeting. The PM’s job is to make sure every piece of work connects back to a player need or a business objective. That connection has to be explicit, not assumed.
Roadmaps are the main tool for this. A PM builds and maintains a content roadmap that covers upcoming updates, events, and feature work - usually looking six to twelve months ahead, with varying degrees of detail. The roadmap isn’t just a schedule. It’s an argument for a sequence of decisions. Why this feature before that one? Why an event in October rather than September? The roadmap answers those questions.
“The roadmap isn’t just a schedule. It’s an argument for a sequence of decisions.”
The PM also works closely with the analytics team. Live-service games generate enormous amounts of player data: session lengths, progression rates, purchase patterns, event participation, churn timing, and hundreds of other signals. The PM has to know which metrics actually indicate the health of the game, which ones are vanity metrics, and which changes in the numbers should trigger a response.
This is where the role gets technically demanding. You don’t need to be a data scientist, but you need to be fluent enough in the data to distinguish a real signal from noise. A spike in revenue might be healthy growth or it might be a monetisation mechanic burning out your most engaged players. The numbers alone don’t tell you which - that’s a judgement call, and the PM is the one making it.
Live operations: where strategy meets daily reality
The PM’s involvement in live operations is hands-on. They’re not just setting direction and stepping back - they’re involved in the configuration and scheduling of in-game events, managing the storefront, and often owning the CRM communications that tell players what’s happening and why they should care.
CRM in live games covers push notifications, in-game messaging, email, and sometimes social media coordination. Done well, it keeps the player community informed and engaged. Done poorly, it’s spam that trains players to ignore you. The PM is responsible for the messaging strategy: what to say, when, how often, and through which channels.
[INTERNAL-LINK: live ops cadence → Production 101 #9 on status reports and live ops tracking]
Storefronts are their own discipline. A live-service game’s store - the shop where players buy currency, bundles, cosmetics, or content - is a product within the product. The PM owns its merchandising: what’s for sale, at what price, in what combination, for how long. The economics here are more delicate than they look. Aggressive monetisation damages player trust quickly, and player trust is hard to rebuild once it’s gone.
The balance between player satisfaction and revenue is the PM’s most persistent tension. It doesn’t resolve. You manage it, constantly, with the data as your guide and your judgement as the override.
How the PM and producer relationship works
In a well-run live-service studio, the producer and PM have a clean division of responsibility. The PM owns what and why. The producer owns how and when.
In practice, this means the PM brings a feature or event to the producer as a brief: here’s what we want to do, here’s why, here’s the target outcome. The producer takes that brief and works out how to staff it, sequence it against other work, and deliver it to the required quality within the available time. The PM doesn’t manage the development team directly. The producer does.
This doesn’t mean the PM is disconnected from the development process. They need to be close enough to understand what’s feasible and what trade-offs are available. If a feature is going to take twice as long as expected, the PM needs to decide whether to cut scope, delay, or find a different approach to the underlying goal. That’s not a producer decision - it’s a product decision.
“The PM brings the brief. The producer works out how to deliver it. The clean version of this works well. The messy version is where most studios live.”
The clean version of this relationship works well. The messy version - where responsibilities overlap, where the PM is trying to direct the team and the producer is trying to set product strategy - is where most studios live, at least some of the time. Sorting out that overlap is worth the effort. A producer who understands the PM role, and a PM who understands the producer role, make the overlap much smaller.
What makes a good Product Manager
The skills that matter most in the role aren’t the obvious ones.
Data literacy matters more than data expertise. A PM who can read an analytics dashboard intelligently and ask the right questions of the data team will outperform one who is personally expert at SQL but doesn’t know what questions to ask.
Communication matters more than either. A PM who can explain the product strategy clearly to a designer, a developer, a finance director, and a marketing manager - using different language for each without changing the underlying message - is the PM every team wants. The role is relentlessly cross-functional. You’re constantly translating between people who care about very different things.
Risk awareness matters. Live-service games break. Events go wrong. Bugs hit production. Player sentiment turns. The PM needs to see these problems coming early enough to do something about them, and to respond calmly when they arrive anyway.
And player empathy matters. The PM advocates for the player community inside the studio. That doesn’t mean giving players whatever they ask for - player requests are often contradictory, and giving everyone what they want is impossible. It means understanding what players actually need to keep finding the game worth their time and money, even when they can’t articulate it themselves.
If you’ve read the earlier posts in this series, you know that game production covers a lot of ground. The PM role is one of the more specialised areas, and it’s one that many people entering the industry don’t know exists. Most people who want to work in live-service games are thinking about design, development, or production. The PM track is a genuine alternative with its own skill set and its own career path.
Whether you end up in production or product management, understanding how the other role works makes you better at your own. That’s what I learned from the PM who walked into my room with a deck full of retention curves. She wasn’t there to take over the game. She was there to make sure we understood what we were actually building.
[INTERNAL-LINK: series overview → Production 101 series index at https://gameproductionalchemist.substack.com/p/production-101]
Great article Rob covering all the different hats Product Managers have to wear.
Was chatting with Joel yesterday and I think he summed it up really well with Product representing the customer and monetisation goals and Production representing the team.
Tight communication and collaboration between PM and Producer are key to success.
Huge thank you dear Rob for continuing to share.