OKRs for Platform Teams

Hey folks, 

Happy New Year! I spent most of my holidays moving house with my family. Despite feeling overwhelmed by the number of boxes to unpack when we first got into the place, we broke down the task by room, and within 10 days, we were out from under the mountain of boxes. Feels good.

All unpacked and freshly settled, I’m hitting the 2024 ground running. I’ve got two workshops with Josh Seiden coming up in Singapore and Tokyo, which we’re very excited about (more below), and we’re closing in on the final draft of our forthcoming book about OKRs, Who Does What by How Much?

Speaking of which, we hold Office Hours with folks in our launch group (join us here and at Office Hours on Jan. 17), and in a recent session, someone asked us to clarify a key question for platform teams—aka teams that support other internal teams: How do you write OKRs to change the behavior of your customers when you don’t interact with the company’s external customers at all? This newsletter answers that question.

- Jeff

Article: OKRs for Platform Teams

“Our team doesn’t interface with external customers. We’re an internal platform team. Our work supports other teams in the company. So, how should we write our OKRs?” Adam asked. 

“Whose behavior are we trying to change?”

It’s a question (or questions) Josh and I have gotten many times in our coaching and consulting sessions with teams across industries. How should cross-functional teams write their OKRs when they “don’t have” customers? And here, in our OKR book launch group, Adam was asking too. 

The first answer we have for that is: You do. You do have customers—everyone has customers. But when you’re on a platform team, they’re just not the customers you think of first. The rest of the answers follow from there.

Even platform teams have customers

Like we said, everyone has customers…so who are they? Let’s look at an example. If you’re on the reporting team of a company whose main product is an event-planning app, you’re not working with the end customers of the company—event planners—but you are working with the front-end product teams who make the app. You provide services to the product teams; they receive value and benefit (hopefully) from your work. The product teams are your customers. If you’re on the infrastructure team, you’re also not working directly with the end customers, but you are supporting the design team, for example, internally. The design team is your customer. If you’re on the design team, your work serves the front-end product teams too. They’re your customers. Starting to get the idea? Great. These customers are the people whose behavior you’re trying to change. 

But what exactly you’re trying to change takes some more reflection.

Identify what you help those internal teams do

When we write OKRs, and more specifically key results, as outcomes, we have to figure out what those outcomes should ideally be. We define outcomes as “changes in customer behavior that indicate you’ve provided them with value.” For platform teams, whose customers are other internal teams—whose behaviors are likely not tracked by current data collection systems and analytics—you have to figure out which “customer behaviors” you need to target. That boils down to three questions:

1. What do you, and the output you create, help the internal teams do? 

2. What’s getting in their way of being successful doing these things today? 

3. If you made the issue(s) better, what would the people on those internal teams be doing differently?

Let’s put some specifics behind these. 

Back to our reporting team. The reporting team at our event-planning app company provides the front-end product teams with data on how the end customers are using and engaging with the app. 

What does that data help the product teams do? Give them the ability to make more objective, informed decisions about product development and change faster

What’s getting in the product teams’ way of making good decisions today? (In other words, what are they complaining about?) At our example event planner app company, let’s say it’s a lack of accurate data. 

If you made the issue better, what would the product teams be doing differently? Making decisions faster, making more accurate decisions (based on a set of predetermined criteria for accuracy), asking fewer clarifying questions about the data, needing to make fewer requests for new or re-run data sets

The behaviors listed in response to the third question ^^, those are your key results. Those are the behaviors that would tell you you’re providing value for that team. Those are the things you target and measure as a reporting team so you can start to make a real difference for your customers.

What happens when you serve multiple different internal teams?

Some cross-functional teams support multiple teams in multiple departments. If you’re in data analytics, you might be supporting the reporting team, but you might also support the design and marketing teams. That’s at least three different customer groups. So, which customers (and customer behaviors) should you focus your attention on? How do you determine whether you should have one overarching OKR that covers them all, or three separate, specific OKRs to apply to each customer group?

The answer to that question comes down to strategy.

Traditionally, data, reporting and design teams tend to be under-resourced, which resulted years ago in the design systems movement, where design teams started building infrastructure to distribute their design capabilities as code to their organization at large. Instead of designing every bit of user interface, you started to see “systems” that encapsulated the entire design language for a system. You might recall Twitter’s Bootstrap as one of the most common ones at the time. Any team in the organization could use a design system to ensure their work aligned with usability, content and visual standards even if they didn’t have an assigned designer. The design teams could then answer questions or help with issues that came up implementing the design system, but otherwise they’d be free to focus on larger design projects. That was one strategy for dealing with the fact that they were under-resourced and had more internal customers than they could manage. And in that case, the teams would likely set one overarching OKR that focused on improvements to their design system—improvements that would serve all of their customers.

Other teams, however, might have a consulting-shop strategy, building specific things or running specific reports on a case-by-case basis as customers from different teams needed them. In those cases, setting a few OKRs that each target a specific department of teams that you support may better serve the strategy.

Better, faster, easier

At the end of the day, OKRs for any team—end-customer-facing or not—should focus on the people your team’s work and output is for, and how you can help them do what they do with your work better, faster, and easier. 

What’s new on the blog

The Tyranny of Transparency – Working with OKRs means using data in big and sometimes very new ways: to validate or invalidate your ideas, and go in other directions when the data shows you should. Essentially, that’s transparency. But it’s scary to have that much transparency and objectivity about our ideas, especially when, historically, being wrong and executing on a “wrong” idea could put your job on the line. This article talks about how to make it less scary and reduce the impact of being wrong.

Stop Saying MVP – Twelve years ago, Eric Ries challenged us all to de-risk the assumptions upon which we build products by conducting lightweight experiments, which he called the Minimum Viable Product, or MVP. After wide adoption, the term’s meaning changed. Instead of MVPs as experiments, people now believe they all have to result in a shipped product. But they don’t, and they shouldn’t. This article discusses why, and what we should say instead.