Production 101 - #11 Roadmaps in Live Service
When the roadmap never ends, the work of keeping it honest never ends either
A live service roadmap is always in progress: near-term precision is possible, far-term precision is fiction.
The live ops roadmap has fixed calendar dates that create hard obligations absent from all other roadmap types.
Player-facing roadmaps should contain only things you would be comfortable having quoted back to you.
Slipping and reprioritising are different things; communicating them as though they are the same creates a blame culture around bad news.
Production 101 is a series for people entering or early in game production. This post continues from #10 — Producers’ Impact on Product Roadmaps. | Next: #12 — Agile for Game Producers | Series index
A boxed game has a roadmap that covers one arc: development, certification, launch. Then it’s done. The roadmap gets filed, the team either pivots to DLC or moves to the next project, and nobody has to revise Q3 at the same time as they’re shipping Q2.
Live service removes that clean ending. You are planning what comes next while operating what’s already live, and both of those things are happening at the same time. The roadmap is always in progress. The near end is being revised because the team is working on it; the far end is being revised because the business has changed since you last looked at it. There is no version of a live service roadmap that is finished. There are only versions that are current and versions that have fallen behind reality.
That rhythm takes some getting used to, particularly if you’ve spent your career in pre-release development. The deadline was the anchor. Everything on the roadmap pointed toward it, and when you shipped, the document had served its purpose. In live service, the absence of that anchor changes how you hold the far end of the roadmap. The further out a planned feature sits, the less you should trust the precision of its placement. The business will have changed by then in ways you can’t fully anticipate now.
The perpetual roadmap
In pre-release production, a ship date stabilises the roadmap over time. As you approach launch, the remaining work becomes concrete, the estimates tighten, and the roadmap starts to look like a real schedule. In live service, that stabilising force is absent. There is no converging point that forces the far end to sharpen.
What you have instead is a rolling window of precision. The next six to eight weeks are specific: features are scoped, the team is working on them, and the estimates are as reliable as they’re going to be. The following quarter is thematic: you know the shape of what’s coming but not the granular detail. Anything beyond that is directional. You know what kind of content the game needs and roughly when, but the specifics are genuinely undecided.
The live service producer learns to hold the near end tightly and the far end loosely. Tightly at the near end means specific commitments, real estimates, and clear accountability for delivery. Loosely at the far end means not treating a quarter-level label as equivalent to a finished scope. When someone on the team asks “are we building this?” and points to something eight months out on the roadmap, the honest answer is usually: probably, but we haven’t designed it yet. That honesty is better than false confidence.
The live service roadmap is an argument for a sequence of decisions, not a record of decisions already made. The near end is nearly decided. The far end is an intention.
The practical implication is that roadmap updates are a normal, recurring part of the job rather than an admission of failure. A roadmap that never changes is a roadmap nobody is maintaining. The question is how you update it in a way that keeps stakeholders oriented without making them feel like the team is making it up as it goes. That distinction between expected revision and unexpected slip matters, and I’ll come back to it in the section on updating the roadmap without losing credibility.
The live ops roadmap specifically
What distinguishes the live ops roadmap from all the others is that it often has genuinely fixed dates, and fixed dates change the production stakes considerably.
A seasonal event can’t slip because the season happens whether the team is ready or not. The Halloween event is in October. A feature slipping from Q2 to Q3 on the tactical roadmap is a planning problem. The team is frustrated, the PM adjusts the slide, and life goes on. The Halloween event not shipping in October is a live failure with immediate player-facing consequences. You either ship it broken, cancel it publicly, or ship a reduced version and explain why. There is no quiet option.
This creates a specific problem around confidence levels. Items on a live ops roadmap vary widely in certainty, but from the outside they all look identical on a slide. Some content has already been built and is in QA. Some is planned and development has started. Some is aspirational, included because someone on the team wanted to see if it might fit the window. The third category is a wish. When marketing treats it like the first category, you have a live problem.
The producer’s job on the live ops roadmap is to make those confidence levels explicit and keep them current. Confidence changes as development progresses, so this requires active maintenance throughout the cycle. Downstream teams like marketing and community need to know about those changes in time to adjust their plans. A community team that has been building social content around an event that turns out to be aspirational has wasted time and will feel misled when the information reaches them.
The producer is the person who catches this before it becomes a promise. That means being in the room when the live ops calendar is being drafted, not being consulted after it’s been locked.
I’ve worked on live service titles where the live ops roadmap was driven almost entirely by community and marketing, with production consulted after the calendar was finalised. The result was a content plan that looked coherent on a slide and fell apart the moment you set it against actual capacity. The fix was getting production into the planning process before the dates were committed, not after. Once the marketing team has built a campaign around a date, that date has an owner outside the development team, and unpicking it is a much harder conversation than preventing it.
Player-facing roadmaps
Players are a third audience that the internal roadmap was never designed to serve. The strategic roadmap is for executives. The tactical roadmap is for the development team. The live ops roadmap coordinates the people who operate the game. None of them, in their internal form, are appropriate to share with players, but studios publish player-facing roadmaps anyway, usually because the community is asking what’s coming.
The problem is that players read roadmaps differently from internal stakeholders. An executive reading a rough quarter-level commitment understands implicitly that this is directional planning. A player reading the same information reads a promise. Communities have long memories and track commitments carefully. A forum post from eight months ago, a Discord screenshot, a tweet quoting a roadmap slide: these resurface when something changes.
I’ve worked on games where we published quarterly content previews with what we thought was appropriate hedging: plans may change, this is subject to revision, nothing is confirmed. The hedging was invisible to most of the community. When something slipped, the response was consistent: “You promised this.” After enough of those conversations, the lesson was clear. The internal roadmap can be ambitious. The external one should contain only things you would be comfortable having quoted back to you in the worst possible context, six months from now, by someone who is already disappointed.
That means the player-facing roadmap should be shorter and more conservative than the internal version, and deliberately vaguer about timing. “Coming this season” is a safer commitment than “releasing in October.” A broad content theme is safer than a specific feature name if the design hasn’t been finalised. The goal is to give players a genuine signal about direction without locking in specifics that might change.
What belongs on a live service roadmap
The things that belong on a live service roadmap are the things that have been agreed, estimated, and at least partially scoped. Features, events, content cadence, the seasonal calendar, and the dependency structure between features that need to ship before other features can start.
The things that don’t belong are estimates presented as certainties, work that hasn’t been scoped, and features that are still at the concept stage but have been given a quarter assignment to make them look planned. A roadmap that treats conceptual work and nearly-finished work as equivalent is presenting a false picture, and someone will eventually make a decision based on it.
The test is simple: if this roadmap were leaked to a journalist tomorrow, what would embarrass you? Anything that would embarrass you probably shouldn’t appear as a confirmed commitment.
The honest version of a live service roadmap distinguishes confidence levels explicitly. Some teams label items: in development, planned, under consideration. Others use a colour scheme. The specific system matters less than having one. What matters is that when a downstream team looks at the roadmap, they can tell the difference between a commitment and an intention. When that distinction is absent, everyone makes conservative assumptions, marketing builds campaigns around aspirational items, and the first slip creates disproportionate damage to trust. Making confidence levels visible is an accurate representation of how live service development actually works.
Updating it without losing credibility
A changing roadmap is the expected condition of live service. The question is how you communicate changes without making stakeholders feel that the team doesn’t know what it’s doing.
The distinction worth drawing clearly is between slipping and reprioritising. These are different events, and they carry different weight.
Slipping means something took longer than expected. The work was planned, the estimate was wrong, and the item is moving to a later window. This happens. Teams should communicate it early, explain why it happened, and give a revised target. Slipping the same item twice is a different conversation, one about whether the estimate was realistic or whether something more structural is wrong.
Reprioritising means the business changed its mind. A commercial opportunity emerged. Player data came back showing something different from what was expected. A competitor moved in a direction that changed what the game needed to do. In these cases, the original item has been deprioritised in favour of something the business judged more important. That conversation is usually easier to have, because it reflects a decision rather than a failure to deliver.
Conflating the two is where teams get into trouble. When “the PM changed the priorities” gets communicated as “we’re slipping,” the team learns that slipping is always attributed to someone, so nobody admits to it early. The producer who knows the estimate is wrong stays quiet for an extra two weeks hoping the team can recover. The PM who changed the priorities doesn’t correct the characterisation because it deflects blame away from the product decision. The eventual conversation is twice as bad as it needed to be.
Slipping and reprioritising look similar on a slide. They feel completely different to the team. The producer’s job is to communicate which is which, and why.
The producer’s ongoing role
In live service, the roadmap conversation never stops. New data arrives, the business responds to it, priorities shift, and the roadmap has to reflect that. The producer’s role is to make sure those changes are translated into delivery reality accurately.
That means showing up to every roadmap revision with an honest account of what the team can build in the next window given what’s already live and what’s already in flight. It means tracking the difference between the capacity that existed when the previous roadmap was committed and the capacity available now. Any item resting on an estimate made before the design was finished needs a flag, particularly if that estimate is what’s holding up someone else’s plan.
The producer who defers in those conversations to avoid an uncomfortable exchange does the PM no favours. The PM needs accurate delivery input to make good product calls. A PM who has been told that everything is on track when it isn’t will make commitments based on that false picture, and the damage appears downstream when the team can’t deliver what was promised. The short-term comfort of not raising the problem costs more than the discomfort of raising it early.
The product manager’s role in this dynamic is worth understanding in its own right, because the producer-PM relationship is where most of the productive tension in live service roadmapping lives. The producer brings delivery reality. The PM brings product judgement. Neither is sufficient alone.
The work itself doesn’t change between years one and five of a live game: you’re still updating the same roadmap, having the same capacity conversations, catching the same optimistic estimates before they become public commitments. What changes is that you build a track record for accuracy, and that track record is the thing that earns you the credibility to be heard early rather than consulted late. The producer who has never told an executive things were fine when they weren’t is the one who gets believed when they say something is actually fine. That trust compounds over time. It’s the only part of live service that gets easier.