How to achieve cross-team alignment in complex organizations with roadmaps that actually work
You know the drill. Monday morning, and your inbox already has three requests: "Can you send me a PowerPoint with the five things your team is doing right now?" By Wednesday, someone's working off an outdated version. By Friday, you're in yet another alignment meeting trying to reconcile what everyone thought was agreed upon last week.
Malte Scholz, Head of Product and co-founder at airfocus by Lucid, has seen this pattern play out hundreds of times across enterprise customers. His diagnosis is blunt:
It’s impossible to keep everyone properly aligned. And that's why so many people spend half their time catching up on the latest dance, what has changed, and which artifacts we now need to update for the 15th time, so the other person knows what's going on. And it's just inefficient.
Product managers spend up to 50% of their time on alignment activities. Information is scattered across slides, spreadsheets, and tools that don't speak to each other. If the constant chase for "the current version” sounds familiar, you're not alone – and there's a better way.
can support your team.
Book a demo
Why this gets harder as you grow
The challenge can’t be overcome by investing in better tools. It's structural. And it scales exponentially with organizational complexity.
Think about a big telco that's operating across Europe with hundreds of products, hundreds of business units. They all have their own strategic roadmaps per business unit. But then, each business unit has 10, 20, 30, 40, 50 teams, each with its own roadmap. So the bigger all of this gets, the harder cross-team planning becomes, and the more important it becomes in order to create the business and customer outcomes you desire.
Each of these layers – company strategy, business unit strategy, team roadmaps – is multiplied by the number of teams. The coordination cost grows exponentially, but so does the value of getting it right.
Why product is behind other functions
Here's an uncomfortable comparison: Other business functions solved this problem years ago.
Other functions, like sales, don't work like this anymore. They have an interconnected CRM where you can generate a report with a click of a button because everything is maintained.
Sales has Salesforce and HubSpot – real-time, interconnected, reportable. Finance has ERP systems providing a single source of truth. Engineering has Jira and sophisticated delivery tracking.
Product? Still relying on what Malte describes as "messy, outdated, full of duplicates" spreadsheets and slides. The gap is real: Product lacks purpose-built, interconnected infrastructure that other functions take for granted.
Framework 1: The four strategic decisions
Before diving into execution, successful organizations make four foundational choices. Based on Malte's recommendations, we've distilled four strategic decisions that shape everything else:
Decision 1: Single source of record
Get everyone accessing the same product artifacts. This means a shared understanding of strategy, initiatives, and connected epics – all interconnected so changes propagate automatically. Put an end to those "Which version is current?" conversations. Malte has discussed the importance of a single source of record before, and it still stands unmatched.
Decision 2: Lean goal-setting
Implement OKRs – or similar goal-setting frameworks – in a pragmatic way that isn't a burden. Two key results instead of five. Keep reporting effort low while ensuring those two are actually good levers for the objectives. Value quality over quantity. This reduces the reporting burden and increases actual usage.
Decision 3: Meeting audit
Cut alignment meetings ruthlessly, then see what you actually need. Identify the meetings that would cause collapse if removed, and get rid of everything else. This forces better async documentation and frees up time for actual work.
Decision 4: Training and mindset
Train product people on end-to-end ownership, not just feature delivery. Product managers should think beyond "What to tell developers tomorrow." They need responsibility for customer insights, strategy alignment, and measuring success – looking upward into the organization, not just downward to their team.
Framework 2: The layered execution model
Once the foundation is set, there's the execution. But first, a useful mental model:
Just as one needs to eat and sleep, product teams need a plan for what to tell the developers tomorrow. This is the non-negotiable stuff that product managers have to do. Everything else comes on top.
The non-negotiables happen at the team level. Everything strategic builds on top of that foundation. Here's how the layers work, including suggestions on meeting cadence:
Phase 1: Strategy alignment
Focus on the product strategy document. The primary audience is executives: CEO, CMO, CFO. The cadence is quarterly or yearly, as this should be relatively static. Review it on a visual board, put a pin on it: "This is the updated strategy doc. This is the base for the coming discussions."
Phase 2: Goal-setting
Set and align OKRs to strategy. VPs and directors own this, typically on a quarterly cadence. The key action: Ensuring the OKRs you set are aligned with the strategy and the initiatives you're planning.
Phase 3: Initiative alignment
Ensure the initiative roadmap reflects the OKRs and strategy. Product directors and VPs own this, with continuous attention and quarterly reviews. The initiative level – this is your cross-team roadmap – must be 100% in line with the product strategy.
Phase 4: Team-level linking
Product managers link opportunities and epics to initiatives. This happens continuously – daily or weekly. The key action: Asking product managers to regularly update the child-parent relationships to the initiatives.
The critical insight: back loops
This isn't a one-way, top-down cascade. Changes flow in both directions. A new customer insight at the team level may change initiative priorities. A strategy shift at the top cascades down towards the team.
Consider this example: You have an "Expand to Australia" initiative planned for Q2. But, bottom-up, a ton of customer commitments are needed to hit revenue goals. The result? Move the Australia initiative to Q3. This is healthy. Your system should allow for this kind of responsive adjustment.
The living system principle
Here's the mindset shift that puts everything together:
A lot of this needs to happen in real time, async, without the need for all these meetings. This requires some discipline to check into these different formats at the opportunity, initiative, OKR, or strategy level.
Cross-team roadmapping is not a quarterly exercise. It's continuous. At the team level, there's constant activity – daily and weekly changes. At the initiative level, updates are less frequent but still living. And even the strategy level, while most stable, should accept ongoing input.
Ask yourself: What stops you from adding comments or feedback to your strategy document within the quarter? Nothing, except the mental model that strategy is "set" until the next planning cycle.
Hierarchy setup: Simplicity beats perfection
When it comes to structure, the most common mistake is overengineering. Malte's recommendation is clear:
For clear overengineering at the start, my recommendation is to start extremely lean. You can start with the simplest version – an initiative with just a status field on top of the opportunities – and you can do that very fast.
The recommended structure
For your product hierarchy, keep it at two levels per business unit:
Initiatives: cross-team, outcome-oriented
Opportunities/epics: team-level, problem-oriented
Deliveries and user stories sit below this, but don't manage at that level.
Your OKR hierarchy runs in parallel:
Company OKRs
Business unit or product OKRs
Team OKRs (optional)
The connection: Initiatives link to OKRs – connected, not nested.
Key tip: Maximum two levels per business unit. Challenge any proposal for more levels. For large organizations with 10+ business units, use Portfolio views to get a bird's-eye view across all business units.
One language note: "Opportunity" language is more flexible than "epic," which sounds more committed. This matters when communicating with stakeholders who might interpret "epic" as a locked-in promise.
Stakeholder mapping
Here’s a useful principle: The higher you go in the org chart, the more senior and external the stakeholders are.
Product strategy: The primary audience is the CEO, CMO, CFO, and the board. External visibility is high, and executives have strong opinions.
OKRs: VPs and Directors own this. Medium external visibility for cross-functional alignment.
Initiatives: Product directors and VPs. Medium visibility as it spans teams.
Opportunities/Epics: Product managers. Low external visibility – this is team-level work.
A timing warning: The last thing you want is to tell product managers or heads of product that they have two days to make sure opportunities are aligned with initiatives. You want a clear process with ample windows for people to plan. Have someone, ideally a product ops person, own the process and timeline.
Routines and rituals
The goal is to win back time through async, real-time updates and a single source of truth. Here are the routines that make it work:
Steering committee (monthly)
Product group updates to leadership using a "good, bad, uncertain" format and clear asks. The key is distinguishing between "This is an FYI" versus "I need guidance on this." This format covers not only product updates but also the go-to-market sales pipeline and CS issues.
Strategy review (quarterly)
Validate that the strategy doc is still accurate. Use a visual board or whiteboard session to review together.
Initiative check-in (continuous)
Ensure initiatives align with OKRs. Async updates with people-driven follow-ups.
Dependency review (weekly or bi-weekly)
Surface cross-team blockers using a dashboard. In the future, AI-assisted detection will make this even more powerful.
The key insight: People beat automations
Automated notifications get clicked away. But disappointing someone who kindly asks you to update the roadmap? That's not something most people want to do. Combine async tools with human accountability.
can support your team.
Book a demo
Common mistakes to avoid
Overengineering: Five or more hierarchy levels before the basics work. The better approach is to start with initiative and status fields only.
The lonely warrior problem: One person builds the system without team buy-in. If these ways of working aren't properly communicated and discussed with the team, and there's a lonely warrior doing this on their own, it doesn't work. Communicate and co-create with the team.
No goal-setting process: Non-measurable initiatives won’t move your team forward. Make initiatives outcome-oriented, for example, "expand to the Australian market to increase revenue by 5%."
Timeline chaos: Say no to last-minute scrambles for quarterly alignment. Build a clear process with weeks of windows.
Empty Initiatives: Avoid initiatives without a description or an outcome statement. Spend five minutes, with AI if helpful, writing a problem-solution statement. Without context, others can't understand or engage with your work.
Timeline expectations
What's realistic for transformation? The most important disclaimer: It depends. Given your company's current state, scale, and team, timelines may vary. A few general predictions:
Meaningful impact on roadmapping process: Six months. This includes process changes, meeting reduction, and establishing a single source of truth.
Product managers talking to customers monthly: One quarter. If you can't figure out a way for your product managers to speak to a customer at least once per month within three months, you can do better.
Training and mindset shift: Longer. Data mindset and end-to-end thinking take time to develop.
Frame the change itself as a transformation roadmap. Put these steps on your own Now-Next-Later roadmap. Treat the change as a product initiative, because it is one.
The future: AI in cross-team roadmapping
In the long run, AI will change how roadmapping works. Dependency detection, which used to require endless meetings, can be automated. airfocus is building dashboard widgets that detect conflicts based on timeline and status changes. Time freed up from manual coordination flows back to strategic work.
What used to take a dedicated person tracking dependencies across 25 teams can increasingly be handled by AI, surfacing the conflicts that matter and letting humans focus on resolving them. Now is the perfect time to check on your AI-readiness.
The payoff
When the system works, it feels different. As Malte describes it, there's relief. You can see that you have a system, sometimes simple, sometimes advanced, that works almost on autopilot. You click on an opportunity, find all the insights, and every day there's another one. You get a real-time pulse check on the product and the organization.
Decisions become faster and better. Time is gained for strategic work. The "catching up" tax is eliminated.
But getting there requires a partner for the journey:
Find a modern product ops person or promote one of your product people full-time or half-time to join you on the journey of building a modern product organization with a single source of record that allows all these teams to be fully aligned with each other and the company initiatives, the strategy, and the OKRs.
Where to start
Start super lean. Initiative level with a status field. That's it.
Get a product ops partner; someone who can own the process while you focus on the content.
Cut meetings and invest in async documentation. Build the single source of truth before you optimize it.
Build your own transformation roadmap. Six months to meaningful impact. One quarter for quick wins. The system doesn't have to be perfect to start working. It just has to be connected.
Ivan Peric
how airfocus can support your team.
Book a demo
Read also
Explore how airfocus can support your team
Explore how airfocus can support your team