Your first 60 days in a cross-cutting product role

Picture joining a payments platform as a staff PM for merchant onboarding, which crosses five teams. Sales signs the merchant. Risk operations runs the KYB review (the checks on the business and the people who own it). Provisioning sets up the accounts and API keys. Billing loads the pricing sales agreed. Integration support helps the merchant's developers go live. Each team has its own roadmap, its own goals and its own manager, and none of them reports to you. New merchants take weeks longer to go live than sales promised them, and the CPO hired you to do something about it. In 60 days you need to find out what you're actually allowed to do, see the journey the way merchants see it, and get the teams that own the pieces to fix something customers notice.

The order follows the diagram. Get the mandate clear before anything else: who sponsors you, what your scope is, what you decide and what you only recommend (phase 1). Then map the journey with its owners and their metrics, because customers usually get stuck at a handoff where the team upstream isn't measured on what it hands over (phase 2). Pick one handoff that customers feel, where two or three teams each change something small, and leave the other nine for later (phase 3). Get the owning teams to fix it under their own names, show a leading indicator moving, and set up a regular review and an escalation path so the next fix doesn't depend on you chasing people (phase 4).

The diagram has two exits. If there's no real sponsor, meaning nobody with authority over the teams who'll spend time on this, reset the scope to what you can actually move, and do it early. And if a fix stalls, look at the teams' goals before anything else. A fix stalls when the teams' own goals pull the other way, and more persuasion rarely gets it moving again.

What the role is. You're a senior product person with no product and no team of your own, and your job is to connect several product areas to improve an outcome that crosses them, usually some part of the customer's experience from end to end. Titles vary: staff or principal PM, group PM without reports, product architect, journey owner, head of customer experience inside a product org, platform PM for a shared capability like identity or billing, or chief of staff to a CPO. GitLab's published PM ladder (as of April 9, 2026) is the clearest description I found: its staff PM covers journeys across three to five teams and leads journey mapping across them, and its principal PM covers problems across five or more. Nothing in it gives either level a say over another team's roadmap.

That makes it a different job from the two nearest ones. A PM who owns a product has a backlog and a team that builds it (a playbook for that role is coming later). A product leader manages people and can move headcount; that's Your first 60 days leading product. You have neither, so everything you get done ships from someone else's backlog under someone else's name. You also differ from a program manager or TPM, who owns how and when an agreed initiative gets delivered. You own which problem gets worked on, what outcome it should move, and the evidence for both.

Why the role exists. Companies design this role away where they can. Amazon's answer to cross-team work was the single-threaded leader, one leader with no other duties running a team built around the outcome. Airbnb went another way in 2023 and pulled the roadmap into one functional organization. Roles like yours exist where the problem can't be separated out like that: shared capabilities like identity, billing or notifications, and journeys like onboarding, migration or disputes that cross several product teams by nature. Your role is a workaround for a problem the org chart can't split, and if your sponsor later reorganizes around it instead, I wouldn't take that as a verdict on you.

Nobody has studied this role directly that I could find, so what follows borrows from research on change sponsors, influence tactics, team goals and customer journeys, plus a few companies' own accounts. If you only remember a few things:

1. Mandate: get an active sponsor and a written mandate before anything else. The sponsor needs authority over the teams whose work has to change; a name on an org chart isn't enough. Once it's written, keep it in the drawer, because quoting authority at teams is one of the least effective ways to influence them (The mandate and the sponsor).
2. Handoffs: look for the problem where one team hands work to the next. That's where journeys usually fail, because the team upstream isn't measured on what it hands over (phase 2).
3. Goals: get the outcome into the planning cycle the teams already answer to, with a metric each team controls. A shared goal added on top of team goals that pull the other way tends to make things worse (Shared goals and incentives).
4. Early win: aim for one handoff fix that the owning teams ship, shown by a number that moves in weeks. Don't sign up to move NPS or churn on your own; they won't move in 60 days, and several teams drive them (Measuring progress).

Under all four sits a cost people don't mention much: coordination work costs the person doing it, in time and at promotion (Protecting your time and your promotion case).

What's different about a role with no team of its own:

• You ship nothing yourself. The credit goes to the team that ships, so plan how you'll show your contribution before the fix lands.
• You're expensive. Organization-design writing going back to Jay Galbraith puts integrator roles near the costly end of the options, well past direct contact between teams. Use the role where cheaper options have failed, and leave a cheaper mechanism behind.
• Overlap: program managers, product operations, a chief of staff and a customer-experience team may all think they make the teams work together. Agree the split in the opening two weeks.
• Vetoes: on a regulated platform a sponsor bank, a card network, a carrier or your own compliance team can block a change to the journey, and none of them works to your 60-day clock.

The mandate and the sponsor

The mandate matters, but it doesn't beat skill. I found nothing that compares the two directly for roles like this, and the evidence comes from nearby places: change projects, matrix organizations, product-development teams. It points one way, though. Role ambiguity was among the work stressors most strongly tied to lower performance in a meta-analysis of 169 samples (Gilboa and colleagues, 2008). Change-management surveys by Prosci and PMI keep ranking an active sponsor as the top factor in project success, though these are practitioners' own reports. Forrester's 2025 research found fewer than a third of firms create shared accountability for how a journey performs. And Richard Hackman's rough rule from research on teams was that most of a team's performance is set by its conditions before it ever meets, with coaching along the way a smaller share.

Skill still decides a lot. Product-development research separates a lightweight project manager, who works through representatives of each function, from a heavyweight one with seniority and a direct say over the work (Clark and Wheelwright, 1992). Most cross-cutting product roles are lightweight by design, and it's worth asking your sponsor which kind they think they hired. Even with a strong mandate, people commit because of expertise, evidence and being consulted, and Amazon's own account of why it moved to single-threaded leaders names the leader's skills alongside their authority.

The sponsor test

Before relying on a sponsor, I'd check these quietly (built on Prosci's guidance on effective sponsors, plus my own judgment):

• Authority: do they have authority over every team whose work has to change, or a peer who does and will back them?
• Level: are they senior enough for the scope? A journey across product, operations and support usually needs someone above all three, or a coalition of their heads.
• Goals: will they put the shared outcome into the owning teams' goals, or at least attend the review where those goals get set?
• Visibility: will they announce the role and its scope themselves, in a forum the teams attend?
• Time: will they give you a fixed slot, 30 minutes every two weeks or so, and a named route for escalations?
• Staying power: are they likely to be in this job in 12 months?

Red flags: the sponsor's own peers weren't consulted about your role; they describe the job as "get everyone aligned" with no outcome attached; they can't name a decision they'd want escalated to them. A sponsor who fails most of these is a sponsor in name only, which is the "No real sponsor" exit on the diagram. Reset the scope to what this sponsor can actually move, or ask them to bring in the peer who controls the rest, before day 30.

What to write down

The mandate is a one-page agreement with your sponsor, which is a different thing from your job description. Mine would cover:

• Outcome: the cross-team customer outcome, one metric, its baseline, a target and a date.
• Scope: which journey or capability, which teams, which customer segments, and what's explicitly out.
• What I decide: the shared map, the definition of the outcome metric, the agenda of the cross-team review.
• What I recommend: priorities across the teams for this outcome, and trade-offs taken to the sponsor.
• What I influence: the owning teams' roadmaps and designs, through their own PMs.
• What I don't do: delivery tracking a TPM already owns, managing people, and status reporting for its own sake.
• Escalation: the forum, who decides on disagreement and how fast, and a line saying escalation is expected.
• Sponsor commitments: the announcement, the monthly review, the metric in the teams' goals, the escalation slot.
• Review date and end state: when the mandate gets reviewed (day 60 and day 180, say) and what done looks like.

You could wait for a win before asking for anything in writing. The research on team conditions points the other way, so I'd compromise: a paragraph in week 2, tested with each owning lead in weeks 3 and 4, revised after the diagnosis, signed and announced by about day 60.

Keep it in the drawer

Once it's written, don't quote it. In Yukl and Tracey's 1992 field study, where subordinates, peers and bosses rated the influence tactics used on them, rational persuasion, consultation and inspirational appeals worked best. Pressure, coalitions and legitimating (appealing to authority or rules, as in "the CPO wants this") worked worst. Quote the mandate and I'd expect agreement in the meeting and little afterwards; it exists so your sponsor backs you when it counts. In the meeting, lead with the customer evidence the owning team doesn't have (contact reasons, stuck accounts, incident impact across the journey). That evidence, and help with their own roadmap fights, are the most useful things you have to trade.

If you own a shared capability

Platform PMs for something every product uses, like identity, billing or notifications, have a different problem: teams can route around a platform they don't like, so a mandate helps less. Evan Bottcher's 2018 essay on platforms says a platform can't rely on a mandate and has to be more attractive than building your own; at Netflix, teams could leave the "paved road" but carried the cost of doing so. Camille Fournier argued in 2020 that internal platforms shouldn't just declare migrations mandatory, and that captive customers hide how unhappy they are. Look for workarounds in week 2: a team that built its own version is telling you something it won't say in a meeting. And define success with the consuming teams early, since for platform teams it's the hardest part (Gergely Orosz says as much about Uber's 2014 program and platform split).

Shared goals and incentives

A fix stalls when the teams' own goals pull the other way. That's the "Stalled" exit on the diagram, and the research here is better than for most of this playbook.

Group goals help. A 2011 meta-analysis by Kleingeld, van Mierlo and Arends found group goals improve group performance, more so when specific and hard. Where people depend on each other, individual goals that maximize each person's own output hurt the group, and goals framed as a contribution to the group helped, though that part rests on only a handful of studies.

Mixed designs can be the worst option. Wageman studied about 150 teams of Xerox service technicians in 1995. Teams did best when their tasks and rewards were purely group or purely individual, and the hybrid designs did worst, with poor interaction and low satisfaction. Those teams had pay attached, and product teams mostly have goals rather than pay, so I'd treat the transfer as a reasonable guess. It's still a good reason to avoid bolting a shared journey goal onto teams whose real goals pull elsewhere. Either the shared outcome becomes part of the team's own goal, or it stays out until the next planning cycle. Marty Cagan made a similar point in 2020: OKRs go wrong when functional managers set objectives for their own people, so one team ends up chasing several goals.

Shared OKRs are good for visibility and weak as a stand-in for authority. Studies from 2022 to 2025, including one at a Norwegian fintech and one at Microsoft, found they helped teams see each other's work but were hard to set, fit to daily work and track. Spotify tried OKRs and moved on to ranked company bets (Examples).

What I'd do, then:

• Sponsor owns the objective. You have no team to commit, so one shared objective can't sensibly be yours.
• Team key results: each owning team writes its own as its contribution, using a metric that team controls. Asking every team to adopt the end-to-end metric itself mostly produces arguments about who moved it.
• Reviews: the shared metric appears in each team's own review as well as in any cross-team document.
• Committed or aspirational: Google's OKR practice separates the two, and mislabelling either way causes trouble: committed work gets dropped to chase stretch goals, or the stretch goals get ignored.
• Conflicts go to planning: settle them through the sponsor. A newcomer can rarely change other teams' goals mid-cycle, so by day 60 the realistic result is agreement on what goes into the next cycle.
• Log failures as shared. Southwest's "team delay" code is the model I'd copy (Examples).

Goals have side effects, too, and narrow ones invite gaming. Amazon's first input metric for selection was a count of product detail pages, and teams added pages for products nobody wanted until the metric was redefined around pages that were actually in stock (Bryar and Carr tell the story in Working Backwards, 2021). And only about a quarter of the companies Ittner and Larcker looked at in 2003 consistently built a model linking their nonfinancial measures to results. Check that each team's key result moves the outcome before anyone is judged on it.

Goals also aren't the whole answer. Gittell's research on Southwest found coordination improved when supervisors coached and gave feedback and performance measurement lost emphasis; shared goals, shared knowledge and mutual respect did most of the work. I'd treat getting the outcome into the planning cycle as necessary, and the relationships as the rest of the job.

Measuring progress

Enterprise onboarding can run for months, so NPS, churn and net revenue retention would show nothing by day 60 even if the fix worked perfectly. The win has to show up in a leading indicator that moves in weeks.

Leading and lagging. Amazon separates controllable input metrics, which teams can move directly, from output metrics like orders and revenue, and spends its weekly business review on the inputs. I'd copy that: pick inputs the owning teams control, check that they move the outcome, and pair each one with a guard metric so it can't be gamed quietly.

Contacts per something is the most practical cross-team metric I found. It's cheap to measure, it moves in weeks, and each contact reason maps to the team that causes it, which is how Amazon used contacts per order (Examples). Pair it with the repeat-contact rate, because pushing customers to self-service can lower contacts without fixing anything.

About NPS. In Keiningham and colleagues' 2007 study of 21 firms, NPS was no better than other loyalty measures at predicting growth, and Bain's own NPS team treats B2B response rates below about 60% as a warning sign. I'd track it per account as a lagging signal and never make it the shared target for a 60-day effort.

The contribution story. You'll never own the shipped change, so don't claim a percentage of the result. Program evaluators have a method for this, Mayne's contribution analysis (2001): write the chain you expect, gather evidence that each link held, look for rival explanations, and assemble a credible account. For the onboarding fix it would go like this:

1. Before the fix ships, write the baseline and the chain: if risk ops starts the review at signing, fewer merchants wait on documents, time to first live transaction falls and early contacts fall.
2. Compare cohorts signed before and after, and hold back a region or segment if volumes allow.
3. Name rival explanations, such as a seasonal dip, one big merchant or a pricing change, and check each.
4. Credit the owning teams by name. Your contribution is the evidence, the convening and the follow-up.
5. Keep a log of decisions and outcomes, so the story exists when someone asks for it.

What not to claim. Movement in NPS, churn or retention within 60 days, or a share of a revenue change. If your sponsor wants a number on a slide, offer the leading indicator and the chain.

Protecting your time and your promotion case

Coordination drift has a price, and the person doing the coordinating pays most of it: in time, because collaborative work keeps growing and lands on whoever everyone goes to, and at promotion, because glue work often doesn't count (the evidence is in Examples).

What I'd do about it:

• Agree what counts in week 2. Ask your manager what impact looks like for this role and how it'll show at review time, before the invisible work starts.
• Keep the artifacts. The map, the decision log, the review notes and the contribution story are your evidence when it's time to make the case.
• Self-sufficient teams: Tal Raviv's advice for senior individual-contributor PMs is to help teams get data and decide on their own, through public channels and teaching, instead of routing everything through you.
• Watch for becoming the hub. If decisions wait on you and your replies slip, you've become a bottleneck.
• Avoid snacking and preening. Those are Will Larson's names for easy, low-impact work and visible, low-impact work, and in a role like this both can pass for progress for months.

What usually goes wrong

The failure that shows up most across the cases I found is a title handed out without the decision rights or the sponsor time to go with it. Incentive mismatch is close behind: every team does well by its own goals while the handoff between them gets worse. Neither looks dramatic. What you see is a role that stays busy for a year and changes nothing customers notice, so I'd check for both by day 30, while there's still time to reset the scope or take the goal conflict to the sponsor.

Words that mean something else here

Examples

These are single-company accounts, mostly told by insiders or after the fact, so I'd read them as illustrations rather than proof.

Southwest Airlines: a delay code for the team

Most airlines assign each flight delay to one department, which, in Gittell's research, led to blame-shifting and people avoiding helping each other. Southwest added a "team delay" code for problems that sat between groups. Coordination improved, and Gittell's account gives supervisors who coached as much weight as the code. If the journey's failures are always logged against one team, add a shared category before you ask anyone to collaborate (phase 3, Shared goals and incentives).

Amazon: contacts per order

Bill Price inherited contacts per order as Amazon's customer-service metric around 1999. The contact reasons were simplified and each one assigned to the department that caused it, including marketing, IT and finance, which then had to remove the cause. By Price's own account the rate fell about 70% in roughly three years. Coding contacts by cause and owner is the cheapest way I know to show each team what it hands over (phase 1, phase 2).

Spotify: from autonomy to ranked bets

Spotify's squads-and-tribes model gave teams a lot of autonomy, and a former Spotify PM later wrote that it lacked shared priorities and success measures. In 2016 Spotify described Spotify Rhythm, after trying OKRs and then another model: a ranked list of company bets, each with a sponsor and success metrics, reprioritized on a regular cycle. Even the best-known autonomy model ended up with that list. A slot on the list your leadership already ranks is where a cross-cutting problem should aim to sit (phase 4).

UK government: the service owner title

In May 2024 the UK's Central Digital and Data Office described giving each of the top 75 government services a single owner, because services cut across policy, digital and operations. The owners were meant to hold budget, staffing and performance, and a commenter warned the title might be handed out without those responsibilities. In July 2026 Defra wrote that it had turned a planned six-month trial into building the basic conditions before anything else, because its structures lacked basics like a senior owner with a multidisciplinary team, and the capacity to support one. Ask in week 1 which of budget, staffing, priorities and performance you actually hold (phase 1).

Airbnb: designing the coordinator away

In 2023 Brian Chesky described moving Airbnb from divisions to a functional organization with one company roadmap. In the interviews, part of the PM role was merged with product marketing and program-management work went to program managers, and Chesky later clarified that product management had changed rather than disappeared. A CEO can solve cross-team problems by centralizing the roadmap, so find out early which answer your sponsor believes in, and draw the same line with program management in your mandate (phase 1, phase 3).

Glue work: who pays for coordination

Tanya Reilly's "Being Glue" describes coordination that decides whether projects succeed and often doesn't count at promotion. Babcock and colleagues found in 2017 that women are asked more often to take on tasks with little promotion value, and agree more often. Cross, Rebele and Grant found time on collaborative work had grown by half or more over two decades. Agree with your manager in week 2 what counts as impact in this role, and keep the artifacts (phase 1, Protecting your time and your promotion case).

Sources

Read on or before October 9, 2026 unless dated; "search result" means seen only as a snippet or summary.

Academic research

• Influence, roles and team conditions: Yukl and Tracey 1992 via Cornell eCommons (search result); Gilboa, Shirom, Fried and Cooper 2008; Hackman, Yale Insights, 2011; Clark and Wheelwright 1992
• Organization and architecture: Conway 1968; Colfer and Baldwin 2016
• Goals and coordination: Kleingeld, van Mierlo and Arends 2011; Wageman 1995 via an abstract; Ordóñez, Schweitzer, Galinsky and Bazerman 2009; Ittner and Larcker 2003 via a summary; Gittell 2000
• OKRs: Stray, Moe, Vedal and Berntzen 2022; Barbala, Moe, Stray et al. 2025; Butler, Zimmermann and Bird 2023
• Journeys and measurement: Purmonen, Jaakkola and Terho 2023; Bitner, Ostrom and Morgan 2008; Keiningham et al. 2007; Mayne's contribution analysis via BetterEvaluation and the ILAC brief
• Wins and progress: Weick 1984; Amabile and Kramer; Kotter 1995
• Who pays for coordination: Cross, Rebele and Grant 2016; Babcock, Recalde, Vesterlund and Weingart 2017 via the paper and the AEA summary (search results)

Consultancy, analyst and survey figures

• Journeys: Rawson, Duncan and Jones 2013 (McKinsey authors, HBR); Forrester 2025 report summary and 2023 blog; Nielsen Norman Group on blueprinting in practice (2019) and blueprint definitions (2017)
• Sponsors and decisions: Prosci on sponsor authority (2021, updated 2026); PMI Pulse via Raconteur (search result); Rogers and Blenko, Bain (search result); Galbraith, Designing Matrix Organizations That Actually Work (search result)
• Wins and NPS: Van Buren and Safferstone 2009; Reichheld and Markey, Bain

Company ladders and practices

• GitLab Product Manager job family (April 9, 2026); Atlassian DACI; Google's OKR playbook (summary)
• Amazon: Brikman on Working Backwards (2023); Commoncog on the weekly business review and the selection metric

Practitioner writing (ideas only)

• Roles and influence: Watkins' five conversations; Larson, "Work on What Matters" (2020); Berenson on Microsoft program management (2011); Raviv on Lenny's Podcast (2024)
• Teams, goals and platforms: Cagan, "Team Objectives" (2020); Team Topologies key concepts; Bottcher on platforms (2018); Fournier on internal platforms (2020); Orosz on Uber's program and platform split (2022); Grove's paired indicators via a summary

Examples

• Southwest: Gittell 2000, above; HBS Working Knowledge case (search result)
• Amazon contacts per order: Price, CustomerThink (2005)
• Spotify: Lee, "Spotify's failed #SquadGoals" (2020); Kniberg, "Spotify Rhythm" (2016, search result)
• UK government: CDDO on single service owners (2024); Defra Digital on senior service ownership (2026)
• Airbnb: The Breve and airfocus on Chesky's 2023 comments (search results)
• Glue work: Reilly, "Being Glue"; Babcock et al. and Cross, Rebele and Grant, above

The site's own research

• Your first 60 days leading product