Leveraging OKRs to Drive Platform Prioritization

How to stop prioritizing on vibes and start connecting your backlog to what leadership already said matters

Tell me if this sounds familiar. You (a data platform leader) are in back to back meetings where three new requests are surfaced all needed ASAP and you and the team already have a full sprint and bursting backlog:

• Finance has quarterly board reporting coming up (required, non-negotiable). The analyst who owned this reporting just left the company and when they opened up the notebook they discovered it’s not just some metric calls, it’s poorly documented spaghetti python that seems to be doing a lot of data pipelining too—and it won’t run. Can you fix it?
  Operationally critical, not strategically prioritized - siloed tech debt back to haunt us all

• Sales desperately needs better reporting to guide quarter close. They have a prototype for one market, but it was built manually, scrappy, and no pipeline exists to scale it. They have found it invaluable to have a data model that helps them see which deals are in the pipeline, what the blockers are, and to help them focus on closing just the right amount of deals to hit their targets without stealing from next quarter’s cash flow. They want a model that scales that helps them “land the plane” right on target every quarter. It’s the CRO’s top priority - like drop anything else they are asking for an focus on this.
  Critical to leadership, strategic, but late arriving and urgent

• Marketing realizes they want a CDP. They have an agency saying they can build it for them fast (for $$$ of course) and procurement told the they have to talk to the internal data team about why we can’t just build it without an agency. It seems wise to avoid undue cost and to ensure alignment with overall architecture, but a CDP build will require significant dedicated resources. And they don’t want to put any of their other project timelines at risk.
  Cost avoidance, ties to long term marketing strategy enablement, but significant investment of labor that you have no capacity for. They are saying it is critical for the brand relaunch, but it’s a massive build with no clear capacity source.

So what do you do? Do you pivot right now, push other items in flight into the backlog and hop right on that financial reporting? You don’t have any other big work for sales right now you can swap out to create that capacity - it would have to come from competing work from other leaders. And the marketing thing feels like a huge beast to tackle.

Years ago I was at a total loss for how to apply a prioritization framework to scenarios like this. I worried the team was getting burned out, the business thought we were always “too backlogged/slow” and everyone thought their things were urgent. I’d try to juggle timelines and see if we could squeeze everyone in, but the that only works for short gains - long term you have to have a way to say no to what is less important and accelerate what is.

The business needs clarity on what we can deliver (and when-ish)

The engineers need stability, limited context switching, and to not constantly be asked to overextend themselves.

You need to manage the underlying tension of helpful agility vs destabilizing whiplash. And deliver that clarity & stability via an organized prioritized backlog.

But what is “important” and how do you figure that out?

Everything about prioritization got easier when I started aligning work to the company strategic framework (OKRs, AOPs, any sort of explicit hierarchical framework). Even if it is vague in some areas or incomplete, it completely changes the game when you can talk to the team about your roadmap & priorities in terms of company strategy.

If your company doesn’t have such a clearly articulated strategy, I have another article about that:

How to Build Your Data Platform Strategy When Your Company's Strategy Isn't Clear

But this article shows how to operationalize whatever hierarchy you have into actual prioritization decisions - down to tactical processes, system configuration and talking points when engaging with partners and leadership.

---

OKRs as Forcing Function (Not Just Strategy Theater)

Thinking back to those 3 requests at the top of the article - finance, sales, and marketing — HOW exactly do we decide what to work on?

The answer definitely isn’t who yells the loudest or follows up most often. It’s in understanding what OKRs are actually for and using them to make prioritization much easier and more defensible.

The whole point of investing time in good strategy work (like Objectives and Key Results) is to help the company align on direction and ensure day to day work (and resources) is consistently concentrated against the problems and investments leaders have prioritized. It means teams know what to say yes and what to say no to. Essentially, OKRs are strategy in action.

Ideally, OKRs are used company-wide and exist in cascading layers which reflect the company structures and decision-making hierarchy. The original research from Intel and Google that popularized OKRs emphasized this cascading alignment—when everyone’s goals ladder up to the same company objectives, you get faster execution and clearer prioritization.

In practice, I’ve seen this work incredibly well when leadership actually operationalizes it. The companies where OKRs made my job easier as a platform PM? They had quarterly OKR reviews where executives explicitly stack-ranked initiatives. They had visible dashboards showing how departmental work connected to C-suite priorities. And when new requests came in mid-quarter, leadership would point back to the OKRs and say “here’s where this fits—or doesn’t fit—in our current focus.” That clarity is gold.

Why OKRs Over Other Prioritization Methods

Before I was in a platform product role I saw OKRs as useful indicators of why certain initiatives were more important than others to our leaders, and a useful reference for occasional resource allocation decisions. But as data platform leader (a shared finite resource the entire company depends upon), they have become essential to my entire approach to prioritization.

What are my other options? I could try to prioritize by:

• Timeline urgency: (try to meet everyone’s needs, shuffling the gantt charts until I can squeeze everything in?

  • ❌ You can’t fit everything in. Ever. I’ve never seen a data team have enough capacity to do this and in the age of AI accelerate, demand for platform capabilities and features is growing at an even more accelerated pace.

• ROI: I could try to calculate the business impact of the various things I’m being asked to do.

  • ❌ Honestly, just the idea of trying to do this for dozens of requests per quarter makes my eye twitch. That's a full-time job in itself, and even then, you're making assumptions about value that leadership should be making through strategic prioritization, not you reverse-engineering.

• Leadership group think: get the data platform leadership group together and stack rank through hive mind.

  • ❌ This works short-term—you're essentially leveraging your leaders' networks and strategic context to intuit urgency. But it's inefficient, not scalable, and burns busy leaders' time on decisions the OKR framework should handle.

• Who is yelling the loudest: this sounds like I’m joking, but some teams operate this way. They are very reactive.

  • ❌ If you are in this mode your entire backlog will fill up with work from loud partners and the quieter partners working on strategically critical work won’t get heard. You’ll miss real opportunities to drive business value. Be responsive to the loud partners, set boundaries about when you’ll get back to them, and make sure you inventory all the critical needs before you consider their request in the mix.

In my experience, it’s much easier and more defensible to use OKRs as a framework. OKRs aren’t just some bullet points on an All Hands deck the c-suite presents annually, they are your prioritization rubric. Your job is to translate, clarify where things are ambiguous, and pressure test against real life constraints (headcount, budget, technical limitations). You are the interpreter of strategy, not the arbiter of prioritization decisions.

Of course, OKRs aren't always perfectly clear. When they're vague or incomplete, that ambiguity becomes visible the moment you try to use them for prioritization—and that's actually valuable, because now you can surface the gaps and force the clarifying conversations that need to happen.

Using OKR Strategy and Stack Ranking to Force Trade Offs

Just like operationalizing OKRs helps us see where the strategy needs more clarity, when strategy hits execution we also often find it reveals constraints. Just like code surfaces edge cases, operationalizing strategy surfaces:

• Unclear stack-ranking when priorities compete for shared resources (like the data team, IT services, or legal)

• Feasibility issues (capacity, dependencies, readiness of current infrastructure)

• Unrealistic timelines - things often take longer than people think, even if we could drop everything and work on it right now. Add in the juggling of run the business work with all this strategy work and often there’s a gap between timeline expectations and reality

Our job is to surface those constraints and force trade-off decisions. Not to overcommit and under-deliver, not to say no without transparency, but to bring leaders the context they need to make decisions.

Great leaders respect a clear articulation of real constraints. They don’t resist hard choices—but they may push back if you give them an opaque “no”s.

Instead, prepare to come back with context that enables their job:

• “Marketing and Sales both map to C-suite OKRs, our team can do A or B in Q2, not both”

• “You can see, based on the stack ranking of the OKRs that these 3 initiatives are definitely going to be possible, but these 2 are stretch goals, we are going to try but we are worried that X (headcount constraints, dependency, unclear technical feasibility) may push it beyond the timeline you’ve requested.”

• “I know some of these items below the line are high value to some business units, but given the current ranking and our current headcount we just can’t get to them all. We either need to deprioritize some other things to make space or we’re going to need expanded headcount to support the work.”

When you prepare and share your roadmap and commitment in this way it is actionable. Leadership has options: re-prioritize, add resourcing, adjust timelines, descope, or escalate. They made a wish list of results they want to drive—you grounded it in current reality. You aren’t making judgment calls; you are just giving them the information so they can make the calls.

They made a wish list of results (OKRs) they want to drive—you grounded it in current reality. You aren’t making judgment calls; you are just giving them the information so they can make the calls.

The other key - be prepared to answer the follow up question “What do you need to get this done?”

• Is it 2 contractors for 90 days?

• Is it an FTE because this is a recurring pattern that the business ambition exceeds capacity - if it’s FTE have you identified which specialty in your platform team is the bottleneck?

• Is it professional services to accelerate a prototype?

You’ve got their attention, don’t waste it by hemming and hawing about your ask. Give them the ask and let them decide. It’s not personal, it’s about what needs to happen to fulfill these requests.

Now the people who manage the budget have a strategy vs budget tradeoff decision to make — balanced with the many such decisions they are making every day.

And you’ve protected your team’s sanity by not saying yes to things that are really outside what is possible. Less heroics, less burnout, more steady stream of high value work.

---

Tying Platform Improvement to Strategic Work & OKRs

Of course strategic work for the business and keeping the lights on type work aren’t the only two categories of work we are trying to prioritize. We also have long range platform building. I like to say “We have to ship with the platform we have today and build the platform we need for tomorrow.”

So how in the world do you make capacity for this when the business already wants 200% of your capacity?

The best way, in my experience, tying platform improvements to the projects that will require them. I think of this as trojan horse platform improvements. For example, say you are building a CDP for marketing’s brand campaign. The CDP is going to be heavy on transformation and your current architecture leaves a lot of observability blind spots and makes things hard to debug. You’ve been wanting to move ETL to dbt and switch orchestration to Dagster, so you pick which pieces of that infrastructure set up represent an MVP and use the CDP phase 1 to pilot it. That way you can deliver on strategic priorities AND advance platform maturity simultaneously.

---

Let’s Get Tactical: How to Actually Operationalize This

Conceptually this sounds great, but I'm sure you're already thinking: HOW do you do this without it becoming a super manual process—custom decks for every tradeoff conversation, jumping between tools, spending hours wrangling tickets and roadmaps?

The answer: you need a SYSTEM. I can’t tell you what your system should be - it is too variable, but I can give you a framework to build your system.

Part 1: Build the Infrastructure That Holds OKR-to-Work Connections

The goal here is that you create a link that connects your top hierarchy items (Jira Initiatives/Epics, Azure DevOps Epics/Features, etc) to the business key results. Whoever owns the OKR process—PMO, strategy team, product org—likely has a tool where they track cascading Objectives and Key Results. This could be a dedicated OKR tool (Workboard, Lattice, Viva Goals), a program planning tool (OnePlan, Asana), or even a spreadsheet. (Yes, I know the data folks are shuddering, but I've seen spreadsheets work pretty well!)

Regardless you probably don’t own that tooling decision. You just need to react to it. So the question is:

• Can you integrate programmatically (via pre-built connectors or open APIs)

• Will you have to maintain a manual mapping?

• Who owns keeping this mapping up to date?

If you have product managers it’s probably their job since they’ve done discovery with the business stakeholders, understand the context, and are creating the high level roadmap. If you can create the links in a way that integration keeps details synced that is ideal.

What this might look like in practice:

• All Jira: JIRA initiatives and epics that roll up to OKR parent objects (housed in a central OKR project at the top of the hierarchy)

• Integration between OKR tool (WorkBoard, Lattice, Viva Goals) and work tracking (Jira, Linear, etc)

• Custom fields/tags referencing OKRs

Why infrastructure matters:

Why does this infrastructure matter? You want to show your roadmap in the context of OKRs without manually rebuilding it every time. When leadership re-prioritizes an OKR, that change should cascade down to your backlog automatically. Inherit hierarchy where possible rather than recreating it manually.

Once the system is set up—minimizing manual updates, automating where possible, and continuously syncing priorities—you're much better positioned for success.

If you can't get integration and you're stuck with manual mapping—okay, that's not ideal, but it's still better than no mapping at all. At minimum, maintain a view (even if it's a spreadsheet or roadmap slide) that shows which work maps to which OKRs, and update it quarterly (or whenever you need to tell the story to guide trade-offs/convey roadmap). Visible beats invisible, even if it's not automated.

Reality check:

As I mentioned at the top, the tooling is often decided by other teams (IT, PMO, strategy), your job is to advocate for structure that makes connection visible. That may mean requesting integration work, requesting certain configurations in their tool so that it works better with your process, or even maintaining manual mappings a few times a year. Get scrappy, experiment, and find something that works - once you have this structure it is invaluable.

---

Part 2: Mapping Incoming Work to OKRs

The reality is that work doesn't come in at convenient cadences—it comes in continuously, even if there are some cyclical surges (budget planning season, product launch cycles, end of quarter). When people bring the work they usually want to know whether you can help and if so when. It’s critical to be encouraging (“I’m here to help, tell me about what you’re working on.”) but also set direct and clear expectations about what happens next.

My go-to response: “Let me look at the roadmap and see how this aligns with everything else, and I’ll get back to you on timeline”

• NOT saying yes

• NOT saying no

• NOT vague “I’ll talk to the team” and ghosting them

• Clear next step: check alignment with strategic priorities and existing commitments

Another learning is that you can’t necessarily expect the requestor to have the context on the strategic alignment and pressing them to figure it out may be counterproductive.

During the conversation, focus on gathering the signals that will help you determine prioritization later:

• “Is there anything I need to know about urgency and timelines?”

• “How does this relate to broader programs and goals the company is working on right now?”

• Example: “Oh, this is part of Project Stargate” → “Ah, okay—Project Stargate is top three CEO priority. I’m sure we can get this done. I’ll get back to you.”

Don’t ask requesters to map their own work to a specific OKR:

Initially I tried this, but what I found is often people weren’t sure if their work aligned to a strategic priority. They felt confused by the question and looked up the priority list trying to justify alignment—not in a manipulative way, just trying to contextualize the work for me.

Better approach: If there’s an obvious connection, it’ll come up in the overall discovery conversation. If there isn’t, take the signals you found and bring them to the PMO or business unit leadership team. Ask them to help stack-rank the work in the OKR context.

A Note on Late & Urgent Requests

Sometimes I get late-arriving urgent requests that demand an immediate pivot. I try to reduce this by teaching the org over time how much advance notice our team needs to deliver well.

That has been successful in reducing the amount of late minute requests, but they can never be eliminated: the business pivots, humans are imperfect at planning ahead, and last minute requests arrive. If the requestor is insistent that their work must be done NOW, I compare it to current roadmap priorities and their OKR alignment. Then I get clear on what would have to be deprioritized to make it happen.

Then I put it back on the stakeholder: get their leader and the leader of the deprioritized item to agree that this is important enough to justify breaking an existing commitment.

Once again, we are not the arbiters of prioritization, we are just responding to leadership’s strategy signal. Though we want to limit pivots when work has already begun (because that’s inefficient), it’s more important that the most critical work gets done.

The benefit of this approach is we get to show up as agile and responsive to the business. But we aren’t pushing our team to “squeeze in more work”—we are still holding firm on our capacity constraints and presenting the trade-offs.

It gives us cover for the delay on the deprioritized item, and it puts the burden of advocacy on the late requesting team.

In summary, discovery with stakeholders is continuous, mapping to strategy is ongoing, and we don’t commit to anything until we’ve got it slotted into our overall strategic framework and have talked to our team about capacity.

---

Part 3: What Happens to Unmapped Work?

If you've been reading this critically, you're probably thinking: 'But what about work that can't be mapped to OKRs?' You're right—not everything will map, and some of it still needs to get done.

I think of this as there’s our OKR strategic bucket of work (the bulk of our work) and then two additional buckets, each with their own rules:

Keeping the Lights On (KTLO)

The trick is defining KTLO very narrowly: literally keeping things running that the business already depends on, or handling business-critical needs that arise unexpectedly.

Examples of actual KTLO:

• Lawyers need a data export for an active legal case? You’re doing that.

• Tableau Server needs a critical security patch? You’re squeezing that in.

• DevX mandates migrating packages to Artifactory this quarter? You’re meeting that deadline.

• Existing pipelines break due to upstream schema changes? You’re fixing them.

• Performance optimization prevents system degradation? You’re handling it.

And that's before we even talk about ongoing maintenance of existing data products: pipelines breaking due to upstream changes, small performance optimizations, cost-saving refactors, and routine monitoring.

Get clear as a platform team on two things:

1. What counts as KTLO?

2. How much capacity we’re setting aside for KTLO (20%? 30%?)

Then it becomes a separate bucket. If you've allocated 30% for KTLO, your strategic OKR work gets the remaining 70%—and that's your constraint.

Note: I avoid the term “Run the Business” it’s too ambiguous - we are not doing workflow improvements, we are not taking on new pipelines we are not building everything every team perceives they need to run the business. We are just keeping the lights on.

Not strategic & Not Essential Work

Here's the hard truth: not everything is strategically important. Some work is useful to certain users, some is an interesting side bet, some is small refinements to the experience—but it's not OKR-aligned.

The answer for most of this work: it sinks to the bottom of the backlog. Be clear with stakeholders that your capacity is consumed by strategic priorities. They'll need to find a workaround or make a case for why this should become strategic work.

That’s prioritization working as it should. Strategy isn’t only about what we say yes to; it is also about what we say no to.

Part 4: Making OKR Based Prioritization Visible and Sustainable

You’ve built the prioritization system, you’ve got an approach for mapping ongoing incoming work, you’ve handled exceptions. Now, how do you make this visible to others and keep it running without manual overhead?

Structure Your Roadmap to Show OKR Connections

Ideally your tooling has views that show this, if not you’ll need to get creative on how to present it this way (maybe export the tickets and use AI to generate the hierarchical contextual views you need based on the structured data). As long as the links exist you can find a way to make those OKR connections visible to others inspecting your roadmap.

In one company we did this in Jira using the advanced roadmap view, which literally showed our team’s projects in context of the strategic objectives.

Make sure it’s clear in what you’ve presented what is “above the line” and in the near term commitment set vs '“below the line” - stretch goals or out of scope. You’ll want visual separation. Literal lines or color coding or separate sections that make this clear. KTLO will also be visually separate.

Your roadmap needs to be flexible enough to shift the granularity to the audience. Leaders just want to see the OKRs & your highest level ticket with a clear signal about commitment (or lack thereof).

Other teams might want to see more detailed tickets - who owns the execution, is the story started, when is it slated to begin, etc. Think of each persona who may want to view the roadmap & ensure there’s a way for them to easily bookmark that view:

• Leadership view: Strategic initiatives, what’s green-lit vs. stretch vs. out, clear OKR connections, timeline commitments

• Stakeholder view: When their requests are scheduled, what OKR they map to, what would need to change for different prioritization. How their work aligns with other requestors and the ability to filter out that noise and only see their own needs.

• Team view: Day-to-day work with context about which strategic objective it supports, detailed timelines, dependencies

When changes happen over time, make sure updates (to the OKRs or to the commitments) cascade through all views. If that happens continuously and automatically, perfect. If it’s manual, make sure the expectation is clear that this is a snapshot at date X.

Communicate Priorities Consistently

It’s a lot of work to build this roadmap - especially the first few times as you are tweaking the system. But once it it exists, you have an artifact that supports your efforts to drive clarity with leadership, stakeholders, and your team.

You may want to have a stakeholder roadmap review presentation with Q&A.
You may want to send out a quick Loom video and a link to the roadmap telling the story.

You may have a quarterly newsletter where you talk about wins from last quarter and upcoming priorities and can link to the roadmap as well as pull screenshots from it.

The rituals and touchpoint will be specific to your org. Align to ny existing quarterly roadmap planning sessions, regular check-ins with stakeholders, sprint planning with the team, etc.

The key principle: refer to the roadmap often, show how work aligns with strategy, consistently convey the message that platform work is driven by strategic decisions made by the business unit leaders. That transparency and pro-active communication pays dividends. I guarantee your stakeholders have no idea the breadth and volume of work your team delivers. Data work is often invisible, but it shouldn’t be that way.

---

Why This Matters

Prioritization is one of the hardest parts of working on a platform team. There is an overwhelming amount of demand and it all can feel very pressing. Remember the example at the beginning of finance, sales, and marketing with their urgent requests? With this framework it’s less overwhelming - you have a system! You evaluate them against OKR hierarchy, you surface trade-offs to leadership, and you deliver them an answer that’s defensible and transparent.

Once you work this way, you won’t want to go back. Strategic prioritization is so much better than reactive firefighting. People may still be disappointed when their work doesn’t rank as high as they’d like, but at least they’ll understand why and feel like you would listen if their business unit leader asked you to reprioritize to better match their understanding of the strategy.

When you work like this you protect your team’s sanity. You don’t overload them with too much work. Less whiplash, fewer heroics, more sustainable pace and happy teams.

And over time when leaders have to make tough decisions, the value your team is delivering is clear. If they need more from the team (as data & AI demands in the business grow) they’ll have much stronger signal about where the capacity constraints keep hitting and whether additional resourcing is needed to meet the organization’s ambition.

OKRs really aren’t just strategy theater, they are your prioritization rubric. Done well they are a game changer for focusing investment toward what matters most. When you operationalize them into your systems, they make your job manageable and your roadmap defensible. You are delivering what leadership decided matters and having real impact on business outcomes. That shift - that’s what makes platform prioritization actually work.

---