Production 101 - #10 Producers’ Impact on Product Roadmaps

What a roadmap actually is, who reads it, and where the producer fits in

• The producer’s core contribution to roadmap planning is delivery honesty. Their job is to pressure-test what’s been committed to, not decide what should be built.

• Most studios maintain several roadmap types at once: strategic, tactical, live ops, technology, and marketing. Each serves a different audience.

• The cone of uncertainty means near-term work should carry specific dates, while anything beyond the next quarter should show themes and directions, not features.

• The Now-Next-Later format separates priority from date, which can help teams earning back trust or operating in genuinely uncertain early development.

Production 101 is a series for people entering or early in game production.

---

I’ve watched this happen on more than one live service game. A confident-looking roadmap gets shared with an executive. The executive mentions it to an external partner. The partner pencils it into their own planning. Suddenly, a rough quarter-level estimate has become a contractual obligation that nobody in the development team knew they were signing up for. Six months later, when something slips, the conversation is about broken promises rather than the actual situation. Nobody wins that version of the conversation.

The reason this pattern repeats itself is that most people in a room treat a roadmap as a schedule. The dates look real. The features look confirmed. The slide is polished and colour-coded. It must be a commitment.

It isn’t.

What a roadmap actually is

A roadmap is a sequence of intentions. Its job is to communicate direction, not lock it in. The most useful thing a roadmap shows is the reasoning behind prioritisation: why does this feature come before that one, why is a seasonal event in Q3 rather than Q4, why is one content stream getting resources that could go elsewhere. The roadmap should answer those questions, at least implicitly. A list of dates and features with no argument behind them is a calendar, not a roadmap.

“A roadmap is an argument for a sequence of decisions. A calendar is just a list of dates. The moment you confuse the two, you’ve lost the thing that made the document useful.”

The value of that reasoning is that it can be examined, challenged, and updated when circumstances change. Reasoning survives a business pivot. A fixed list of dates doesn’t.

This also matters for the people reading it. A product manager who built the roadmap knows what’s been thoroughly scoped and what’s still a rough intention. A developer reading the document has no way of telling one from the other unless the document makes that distinction explicit. A roadmap that treats confirmed work and wishful thinking as equivalent is already lying before anything slips.

Who reads it, and what they need

The same document serves several different audiences, and each of them needs something different from it.

Executives want confidence. They don’t need granular detail. They need to believe that someone in the organisation knows where the game is going, that the content pipeline is coherent, and that the team isn’t just reacting to whatever went wrong last week. A roadmap that gives them that confidence is doing its job, even if it shows only broad direction.

The development team needs clarity on what’s actually been scoped versus what’s still conceptual. A roadmap that lists vague features the team has never discussed creates false certainty about work that hasn’t been thought through. Producers and engineers trying to plan their next iteration need an honest picture, not an optimistic one.

Players are a third audience, and they shouldn’t be reading the same document as the other two. When studios publish player-facing roadmaps, they’re making promises. Players have long memories, and communities track commitments carefully. The player-facing roadmap belongs in a separate document with its own constraints, including much tighter standards for what counts as confirmed. Post #11 — Roadmaps in Live Service covers player-facing roadmaps and the specific problems they create.

The cone of uncertainty

There’s a concept from software engineering called the cone of uncertainty. The idea is straightforward: the further out you look, the wider the range of possible outcomes. Early in a project, estimates might be off by a factor of four in either direction. As design and scope solidify, the cone narrows. By the time work is in development, estimates sit within a much tighter range.

The same principle applies to roadmaps, and most roadmaps I’ve seen violate it. They show quarter-level precision for work twelve months out, putting specific features in specific months for a period when the team hasn’t scoped those features, the business environment may have shifted, and any number of unforeseeable things could have happened. That precision is fiction.

The honest version of a roadmap makes this explicit. Near-term work, the next six to eight weeks, appears with specific features and target dates because it’s been scoped and the team is working on it. The following quarter shows themes and intentions rather than specifics. Anything beyond that sits at an even higher level: directions, not commitments.

This vagueness is a feature, not an admission of weakness. I’ve had to explain that to executives more than once. When I show a roadmap where the far end is deliberately high-level, the reaction is sometimes that the team doesn’t know what it’s doing. The opposite is true. A team that shows quarter-level precision twelve months out either hasn’t thought carefully about how much is unknown, or has decided to hide that uncertainty from the people they’re reporting to.

“A roadmap that becomes vaguer as it extends further out is a sign of discipline, not drift.”

---

Not one roadmap but several

Roadmap planning is made harder by the fact that several different documents operate at once, each serving a different audience. Studios that treat “the roadmap” as a single artefact end up with something too detailed for executives and too vague for developers.

Strategic roadmap. For executives and senior leadership, this covers broad direction on a twelve to twenty-four month horizon with no precise dates. Its job is to show that the team has a coherent view of where the game is going. The PM owns this one. The producer’s involvement is limited to making sure the ambition doesn’t significantly outpace what the team is capable of delivering in that window.

Tactical roadmap. For the cross-functional development team, this covers features, phases, and delivery windows across three to twelve months. This is where producer input on delivery feasibility is most active. Every item in it is either backed by a realistic estimate or it isn’t, and the producer’s job is to know which.

Live ops roadmap. For community, marketing, and live ops, this covers content cadence, events, and monetisation initiatives. Unlike the others, this one often carries genuinely fixed dates: a seasonal event can’t slip because the season happens whether the team is ready or not. The live ops roadmap carries specific production risks covered in Post #11 — Roadmaps in Live Service.

Technology roadmap. For engineering and technical leadership, this covers infrastructure investments, platform transitions, and technical debt reduction. It’s often invisible to the rest of the organisation until something breaks. The producer needs to understand what’s in it because technology decisions have delivery consequences that will eventually land on the tactical roadmap.

Marketing and publishing roadmap. This aligns releases and content drops with campaigns. A date confirmed in the marketing roadmap quickly becomes a contractual or reputational obligation. Once it’s in an ad buy, it’s fixed. The producer needs to know what commitments have been made here, because the publishing team will build plans around dates that need to be accurate.

The producer doesn’t own most of these. The producer needs to understand all of them, because a commitment made in one document becomes a delivery obligation whether or not everyone involved understood it that way at the time.

Now-Next-Later

When a studio is still building its roadmap process, or when the planning horizon is genuinely uncertain, the Now-Next-Later format is worth understanding. It categorises work by relative priority rather than calendar date. “Now” is what the team is actively working on. “Next” is what’s been committed to for the upcoming window. “Later” is everything else, in no particular order.

The practical advantage is that it decouples priority from date. When a date-based roadmap slips, something that was in Q2 is now in Q3, and every downstream plan needs to be revised. When a Now-Next-Later roadmap changes, work moves between categories. That’s a reprioritisation. The two carry different weight in how stakeholders respond to them.

The trade-off is precision. Stakeholders who need to plan against specific dates, including marketing, publishing, and platform holders, find Now-Next-Later frustrating because it doesn’t tell them when anything will ship. It works best for teams that have earned enough trust to have that conversation openly, or for early-stage development when dates genuinely aren’t knowable.

It’s also a useful temporary tool for a team coming out of a period of chronic slippage. If every date you’ve given has been wrong, switching to Now-Next-Later while you recalibrate your estimates is less damaging to credibility than issuing another set of dates that might also prove wrong. The format signals something honest: we know what we’re working on, we know what’s coming next, and we’re not going to pretend to precision we don’t have yet.

---

The producer as auditor

The producer doesn’t own the roadmap. This surprises people who expect the producer to be drawing the boxes on the slide. In most studios, the product manager owns the product roadmap: the document that says what gets built, in what order, and why. The producer’s job is to make sure that document stays honest about what’s actually deliverable.

The PM sets product direction. The producer has no position on whether the game should build a battle pass or a seasonal event. That’s a product strategy decision. The producer does have a position on whether either of those things can ship in the window they’ve been assigned, given current team capacity, outstanding technical debt, and the certification schedule. That’s a different contribution and a specific one.

“The producer’s job is to make sure that document stays honest about what’s actually deliverable.”

A producer who tries to author the roadmap has taken on accountability they can’t discharge. The roadmap reflects judgements about player behaviour, business goals, and competitive positioning. The producer doesn’t own those judgements. But the reverse problem is just as damaging. A PM who writes the roadmap without producer input creates commitments the team will spend the next six months trying to honour. When things slip, the producer gets blamed for failing to deliver a schedule they had no hand in building.

The productive version of this relationship is one where the PM brings a proposed roadmap to the producer and asks: can we do this? The producer’s answer is rarely a simple yes or no. It’s usually: yes, if we drop this other thing; or yes, but this estimate has a dependency you haven’t accounted for; or no, here’s why the team thinks we can’t. The negotiation that follows is where the roadmap gets grounded. That position is one of influence without authority: the producer can object to a commitment, flag a dependency, or refuse to validate an estimate they believe is wrong, but the product direction sits with the PM and the final call on the roadmap does too.

My experience of the producer role in roadmap discussions is that it feels less like author and more like auditor. I’m not writing the argument for what should be built. I’m checking whether the argument holds together under delivery conditions: whether the team has the capacity, whether the estimates are realistic, whether the confidence levels on individual items match what I know about their actual state of development. When I do that job well, the roadmap that comes out is one both the PM and the production team can stand behind. When I don’t do it, the dates are aspirational, the commitments are fragile, and the first slip turns into a politics problem.

The failure mode I’ve seen most often is the producer deferring to avoid the argument. The PM proposes a window, the producer has reservations but doesn’t voice them clearly, and the roadmap gets locked with dates that everyone quietly knows are wrong. That’s not a comfortable position for anyone. The PM who doesn’t get honest production input isn’t in a better position. They’re just missing the information they need to make a good call.

If you’re not clear on what the product manager’s role looks like on the other side of that table, Production 101 #7 covers it in detail. The live service operational layer of roadmap work, including how to update a roadmap without losing credibility and how to handle the specific pressures of the perpetual live service document, is covered in Post #11 — Roadmaps in Live Service.