One Team, One Roadmap: Aligning Stakeholders in a Big Company

How to kill the shadow roadmaps and build the kind of alignment a 50,000-person company actually needs.

If you've ever sat in a planning meeting at a large company and quietly realized that the design team, the engineering team, and the PM team are all working from different roadmap documents — congratulations, you've seen the single most common alignment failure in product management. It happens everywhere. It's normal. It's also corrosive.

A Lenny's Newsletter reader once wrote in with exactly this problem:

One of the more frustrating challenges I've encountered in my role as Head of Design has been the many disparate sources of truth. As one example, the design team has a prioritized roadmap doc created in partnership with product managers AND the eng team has a different roadmap doc (using a totally different tool). That's broken, true?

Lenny's answer, lightly abbreviated: yes, that's broken — and it matters more than it seems, because a roadmap is not just a list of features. It's the contract between the functions that build the product together.

Why one roadmap is a big deal

Lenny enumerates five jobs a roadmap is supposed to do:

• Prioritization — a forcing function to rank all the team's ideas
• Alignment — everyone sees what the priorities are
• Transparency — everyone sees who is working on what
• Accountability — visible dates and deadlines
• Dependencies — which tracks depend on which

If you split the roadmap across multiple docs — one for product, one for engineering, one for design, one for the exec deck — you don't get 1/5 of each benefit per doc. You get roughly zero. Because the moment two docs disagree, nobody knows which one is real, and everyone starts maintaining their own private "what I think is actually happening" side-notes. That's the actual source of truth. And it lives in Slack DMs.

Lenny's metaphor is worth stealing: "I like to think of PM as the conductors of an orchestra — they both lead a cross-functional team to create something beautiful. A roadmap is like the musical score. It tells everyone on the team who's responsible what, when they need to start and finish, and how all of the parts come together to create something great. In an orchestra where the violins have one plan and the tubas has another, it does not end well."

That's your job as a PM: one score, played by all sections.

Linear's radical version: one roadmap, whole product

Linear, profiled in How Linear Builds Product, takes this idea to an extreme most companies can't copy but can learn from. With around 50 people, they have a single product team, a single roadmap for the whole product, and exactly one person with a PM title.

Linear's CEO explains: "We only have a single product team, which means that we can keep the planning process quite centralized, and there is only one roadmap for the whole product. This makes it very clear to everyone what we are working on. Additionally, everyone feels responsible for the whole product and how it all works together."

You, reading this at a major insurer, are laughing. "There are 400 people in my division alone." Fair. But the insight scales down even if the org doesn't. At your level — your team, your squad, your product area — the question is: is there a single roadmap document that the PM, the engineering lead, the design lead, and the QA lead all refer to? If the answer is no, you have a Linear problem in miniature, and it's solvable.

What "one roadmap" does and doesn't mean

A common objection: "But our sub-teams need their own detailed plans. Research can't plan focus groups on the main roadmap. Engineering can't put every bug on it."

Correct. That's not what one-roadmap means. Lenny is explicit:

It's totally fine for individual functions (e.g. the research team) to keep their own internal roadmap to keep track of their internal sub-tasks (e.g. schedule a focus group), but it's vital that your cross-functional teams always come back to a single source-of-truth roadmap with each team members' projects and timelines.

The model is: one master roadmap at the team level, with sub-roadmaps hanging off it for function-specific detail. The master gets the cross-functional commitments. The subs get the tactical work. The relationship between them is explicit.

This is important for a new PM to get right, because the pressure in a big org is always to fragment. Every function wants their own tool. Engineering wants Jira. Design wants Figma. Research wants Dovetail. Marketing wants Asana. All of that is fine — as long as each one points back to the master roadmap as the source of truth for priority and timing.

The alignment work is mostly influence, not tools

Once you've got one document, the harder problem begins: getting everyone to actually believe it. Jessica Fain, who's been a product leader at Box, Slack, Brightwheel, and Webflow, put it bluntly in her conversation with Lenny:

As product builders, there's almost not a skill that's more important. Influence and building momentum behind great ideas is the way that great products actually get built. And if you don't have that influence, if you don't have the buy-in and the backing of your key stakeholders, of your executives, you can't build great products.

For a new PM, this reframes the alignment problem. You're not trying to build the right roadmap. You're trying to build a roadmap that enough of the right people will fight for when it matters. That's a different skill — and it's the one the tools don't help with.

Fain has a specific trap to avoid: the "I'll just do amazing work and everyone will recognize it" phase. "I was in a period of like, I don't need to work on this skill. I'm just going to do amazing work. It's going to show itself. Everyone's going to recognize it. And everyone runs into this wall of like, oh man, all these other people are getting promoted."

Translated to roadmap work: your roadmap being "right" is necessary but not sufficient. People also need to have seen it, weighed in on it, and felt consulted. If you skip the second half, you'll be right and alone.

A Monday-morning playbook

1. Audit the shadow roadmaps. Pick a random week and ask every function on your team to show you the doc they use to plan. If there are more than one, you have a problem — and you now have a concrete artifact to fix.
2. Declare one document the master. Pick one. Put a banner at the top: "Source of truth for [team name] roadmap. Last updated [date]. Comments welcome, changes via [process]." The banner alone does real work.
3. Write each item around a problem or outcome, not a feature name. "Reduce quote abandonment" travels better across functions than "Quote Flow V2." Engineering, design, and research can all see themselves in an outcome.
4. Over-communicate the roadmap. Share it at every forum where stakeholders gather — standups, biweekly reviews, the monthly exec update. The best PMs I've seen say the same roadmap out loud four different ways, to four different audiences, every month. Redundant, but bulletproof.
5. Invest in influence with your top three stakeholders. Identify the three people who most need to be bought in — usually an engineering director, a design lead, and a senior business stakeholder — and invest in those relationships explicitly. Send them drafts first. Incorporate their edits visibly. You're not buying agreement; you're buying engagement, which is the thing that holds under pressure.

The close

One team, one roadmap is not a format rule. It's a cultural commitment. It means you'd rather have one imperfect shared document than five perfect function-specific ones. It means you accept the messiness of reconciliation in exchange for the clarity of shared direction.

For a new PM in a big, matrixed org, this is the highest-leverage thing you can do in your first 90 days. Not prioritization frameworks. Not strategy decks. Just: find the shadow roadmaps, and replace them with a single score that everyone can play from.

← Back to Roadmapping