Cross-Functional Prioritization is a Diplomatic Effort
It's not just about the data
When you have limited resources (everyone has limited resources), you want to focus on the work that will deliver the most impact.
But how do you decide what that means when it’s a cross-functional effort? What data do you use? Whose opinion takes precedence? How do you achieve stakeholder alignment when there are strong feelings in opposite directions?
Unless you’re working in a vacuum where your tradeoffs don’t impact other humans, prioritization is a diplomatic endeavor.
The Human Side of Prioritization
My background is in tech startups. In my experience, prioritization becomes especially challenging in the growth stage. The company is scaling faster than the systems that prop it up, which means it’s difficult to share information and easy to trigger misunderstandings.
A classic example is tension between customer-facing teams (e.g., sales, customer success, support, trust & safety) and product development. This is an inherent issue, but it’s exacerbated in companies that are growing quickly. When you talk to customers, you hear their frustration firsthand, and it can be really challenging to understand why a common pain point languishes in the backlog for… years. When you’re responsible for a product roadmap and scope delivery timelines, you’re painfully aware that the ratio of requests to resources is overwhelming.
So how do you bridge the gap, keep the peace, and make sure everyone’s steering in the same direction? Communication, of course, but the “how” is important.
In one former workplace, I saw a Product Manager take on responsibility for what was essentially the customer request backlog. It looked like a daunting and thankless assignment, but her approach—and the results—confounded expectations.
She used a purpose-built prioritization matrix, but more importantly, she recruited customer-facing domain experts to own segments of the data. Each owner defined the methodology for their metrics and participated in tradeoff discussions. This solved two problems: it prevented her from assigning value based on her own assumptions, and it gave a broad swath of the company representation. The folks participating in these discussions were able to go back to their own teams and explain the rationale for each decision with a lot more context than you’d get from a top-down all-hands discussion.
This approach solved real problems for customers and diffused long-standing tension across teams. The benefits also compounded over time: decreased tension → increased trust → better communication → more context for future decisions.
Living the Debate
At another workplace, I had the opportunity to use this approach myself. I was placed in an org with eight different sub-teams loosely organized around a specific problem space. As in many startup environments, the work grew organically along with the company before being formalized into a cohesive org. The newly minted group had separate planning rituals and widely divergent opinions on what was important.
I was asked to lead a prioritization project to address this problem. The goal was to establish an org-wide, agreed-upon method of defining priorities that would guide decisions around everything from multi-quarter roadmaps to ad hoc fire drills.
There was broad agreement that this was important, as well as an excellent, data-driven draft framework. However, the framework had been authored by a small group from one domain area and there was ongoing debate within that group around methodology and inputs.
I recognized that the project would live or die based on buy-in and ongoing commitment. The right data was important, yes, but getting people to believe in the data was more consequential. I used what I’d learned from my former colleague to build a strategy centered around the following:
Ownership: I recruited representatives from each function, asked each of them to define the methodology for one set of data inputs, and facilitated group discussions to pressure-test the proposals. We aligned on a model, presented it to the exec team as a group, and got buy-in from all of the key players.
Marketing: getting an entire org to follow a new process is not easy. To encourage adoption, I made sure the project was well understood and visible. I posted regular status updates in communication channels, included shout-outs to the cross-functional project team, and signed us up to present at all hands with an exec sponsor.
The project was ultimately successful—the framework was widely adopted, and I handed it off to the data science team to automate, iterate, and maintain. We got an MVP up and running quickly, but because it exposed a lot of cross-team friction it took about eight months and two iterations to get to a steady state. The data was consistent; how to use it was a matter of intense debate.
The project made me respect my former coworker even more, because I saw that creating a spreadsheet and recruiting domain experts is the easy part. Hearing, understanding, and integrating your teammates’ perspectives is much more delicate.
The Lesson
You can have a 100% bulletproof reason for a particular tradeoff, but your team won’t support you if you can’t reach them on a human level. Taking the time to connect, listen to counterpoints, and genuinely consider them will help you build the relationships you need to deliver results. You’re also likely to find a better solution—more nuance means a deeper understanding of the problem.
Conversely, there are very real consequences for discouraging debate. At best, you’ll see lower productivity, resentment, and gossip. At worst, you won’t hear about major risks with catastrophic and far-reaching impact.