Prerequisite 4 - Cross-Functional Team Structure
Structure your teams to own and deliver their own PoR
A successful Plan of Record (PoR) prioritization process depends on having the right team structure—specifically, cross-functional product teams that are empowered to own, drive, and deliver on their portion of the corporate goals.
This is the opposite of organizing purely by function. In a functionally siloed R&D organization, developers sit in one group, product managers in another, DevOps in a third, infrastructure and infosec elsewhere—and the only connection to business goals runs through a single R&D executive.
The result? Teams operate in isolation, can’t see all the work, and can’t estimate capacity accurately. Prioritization becomes a guessing game, and the PoR is either undercut or ignored.
Why Functional Silos Break Down at Scale
In small startups, a functional structure can sometimes work—especially if the technical founder can personally manage all prioritization decisions. But as the business grows, this model quickly breaks down.
The R&D leader becomes overwhelmed, unable to see all the work or allocate capacity accurately. Developers are frequently moved between projects, losing context and motivation. Daniel Pink’s core drivers of autonomy, mastery, and purpose start to erode, and your best people burn out.
Cross-Functional Teams Are the Foundation of Scale
In a cross-functional structure, each team includes:
A product manager (the driver and owner of the product lifecycle)
UX designer(s)
Software developers with the right skills (e.g., front-end, back-end, full-stack)
Dedicated or shared support from DevOps, infrastructure, infosec, and other specialized roles
This structure enables your teams to:
Translate corporate goals into actionable objectives
Take ownership of product features and services
Prioritize their own work in alignment with broader goals
Estimate capacity realistically across all disciplines
Communicate and iterate faster
With cross-functional teams, the PoR process can scale—because prioritization happens closer to where the work is done.
What About Shared Functions?
Most organizations have shared R&D resources—teams like DevOps, infrastructure, infosec, data science, or research—that serve multiple product teams.
That’s not a problem. But it is something you need to plan for. These shared functions must either be embedded in cross-functional teams, or their dependencies must be explicitly tracked in the PoR.
If multiple teams are competing for the same resource pool—say, a data science team of three—you need visibility into how those resources are allocated, and what that means for delivery timelines. Otherwise, prioritization breaks down at the seams.
Start Where You Are — and Be Ready to Adapt
You may already have a partially cross-functional structure. Many companies have adopted the team models described in Marty Cagan’s Inspired, with a reasonable ratio of product managers, designers, and engineers.
That’s a great start—and it’s usually enough to launch a working PoR process. But if your PoR is going to capture all the work across R&D, including shared functions and internal dependencies, you may need to evolve your team structures further.
As always, treat the PoR process as a living system. Start where you are. Then adapt.
Up Next: If you’ve decided that a PoR prioritization process will help your business prioritize resources to achieve your goals, and you’ve started to build the necessary culture for success, it’s time to start building your PoR process. In the next section, we’ll get practical about how to get started.