If OKRs measure success in terms of customer behavior, it’s relatively easy to identify the humans who are your customers. These are the buyers and users of the products and services you build. What if, however, the products you make are used by internal teams. Who are you customers in that situation? And, equally as important, how do we measure their success?
Internal teams are people too
Perhaps it goes without saying but the people inside your company who use the products you build are the humans whose behavior you’re trying to change for the better. For example, if you build APIs or platforms, the other developers who use those systems are your customers. If you build a CRM system, the sales staff are your customers. If you manage the company design system, the designers are your customers. You see where this is headed? Deciding how to measure the success of your work starts with identifying the internal personas who use your products.
Measuring internal teams’ success can get tricky
Once we’ve identified who our users are we then need to figure out what to measure to determine success for the work we’re doing for them. Let’s use our three examples from above to see what makes for a good key result for each. If you’re on the team building APIs and platforms the software developers using your work should be doing better, more efficient work, right? This would mean that it takes them less time to deploy new features to production. It may also reduce the amount of time it takes them to recover from a bug or crash. Both of these are measures of human behavior. Both of these answer the question who, does what, by how much?
If the CRM system you’re building helps sales people sell more, how might their behavior change? Given that there are many variables that lead to revenue and greater sales, how can you isolate the improvements your CRM system is helping achieve? In this case the CRM should help sales folks get more meetings and get more proofs of concept, for example. And if those things are happening we’d likely see greater usage of the system itself. You should expect to see more time spent in the system, greater amounts of data entry, better data accuracy and other indications the system is delivering value.
By the way, it’s worth noting that particularly in sales situations there will be a push to simply hang success on a revenue number. That may be true for the sales team itself, but for the team building products that support the sales team the real measures of success are the leading indicators of revenue. These are the behaviors the team goes through that may lead to sales and revenue and, again, usage metrics of the systems your team produces.
Finally, for the design system team, what does success look like? If you’ve created a useful design system that makes designers more productive, consistent, and efficient, how will you know? In this situation you can look at the time it takes designers to turn around concepts. You can also look at the distribution of time between designing standard customer workflows (e.g., add to cart, check out, retrieve password, etc) and more complicated user journeys. In theory, turning around a standard journey should be quick allowing designers to spend more time on more challenging design tasks. Ultimately, again, we would look for usage of the system, contribution to the design system and the amount (or lack of) questions about how and when to use it.
OKRs work just as well for internal products
Internal products are exactly like externally facing products. They are built for use by humans. In this case the humans are your colleagues. They have needs, goals and are trying to do their jobs successfully. The work you do for them should directly impact how they do their jobs. There may be knock on effects, and there likely are, but those are outside of your influence. Your goal is to ensure they do their jobs well, efficiently and can help their team be more successful regardless of what they do in the organization.
