Finding the Right Metrics for Internal Teams

As a company scales, it’s essential that every part of the organization scales with it. For many companies, an effective internal tools team is a key part of that effort, making it possible to reduce unnecessary overhead costs by making things more efficient. As Product Designer Nick Vessella has written, “Internal tools save your company money. They make sure there’s not 2,000 pounds of dog food sitting in a random warehouse, they help insurance companies identify false claims, and they help financial companies automate painstaking manual processes.”

But what does “making things more efficient” actually mean in practice? Everyone can recognize the value of efficiency, but it’s not necessarily easy to draw a clear correlation between an improved and greater efficiency. To get there, you need to find and track metrics that can speak to the true impact of your internal tools team’s work. So let’s explore what that looks like and how you can make that happen.

Handpick Your Metrics—Don’t Just Adopt Familiar Ones

The most common product metrics—such as feature adoption or new user acquisition—are designed to be used in customer-facing contexts, which can often make them an awkward fit when trying to leverage them to assess the efficiency of your internal tooling work. As a result, it may make more sense for you to shop around for other ways to measure success.

Ultimately, the metrics you use to measure your team’s impact need to be specific to your company’s workflows and processes, so product teams that are new to internal work should resist the temptation to plug in metrics and processes from external examples.

For instance, if you’re focused on measuring consumer-side metrics to measure the success of your internal tools work, a project like creating a new dashboard to centralize customer support data may not seem worth the effort. However, that picture could well be incomplete. If, for instance, creating that new tool saves each member of your support team 10 minutes per day, the actual impact of the project could be enormous. But if that’s not a metric you’re looking at, you might well miss that impact entirely.

Find the Friction

So, how do you find metrics that capture the true result of your internal tooling efforts? One smart way to start is by taking a look at the other teams within your organization and trying to identify their “friction points.” These are a little different than pain points; I find the definition from digital marketing agency TANK useful to understand the distinction: “One business owner calls friction points “tolerations”—things that you tolerate over time. They’re the pain points that no one’s taken the time to address or removed, so they’re being tolerated.” Think of friction points like tech debt, but made of habits rather than code. (In the site reliability engineering world, this is often called “toil.”)

At Braze, we identified these friction points by carrying out 30-minute research interviews with stakeholders representing teams from across the company. These individuals are likely to be particularly aware of the friction points that crop up in their teams’ workflows, but may not have the ability to easily dedicate resources to address them, providing the internal tools team a clear opportunity to add value. However, we’ve found that the internal feedback volume is often quite high, so make sure you’re prepared to sort and prioritize these requests as they come in.

A good way to identify friction points that are worth solving is by asking open-ended questions. One question that I liked from our user research sessions was: “What’s something that your team wastes a lot of time doing?” This framing helps to surface frustrating friction points that are having a measurable impact (in terms of time) and are repetitive enough that you may be able to address them with an automated process or improve them using a tool.

Put a Bow on It

Once you’ve identified the major friction points for your company’s product and engineering teams, be sure to prioritize them against each other—and to think through the business costs associated with each one. Due diligence is important here; you should verify that the process that includes a given friction point has a quantifiable time or process cost (for instance, an increased number of support tickets) before beginning work. In general, it’s not going to make sense for your internal tools team to spend the time and effort it takes to solve a super-frustrating case that happens only once a year, and that’s okay. The point is to maximize impact and support scalability.

Don’t be surprised if business costs related to friction points are sometimes difficult to measure; there might well be a couple layers you need to peel back to unearth the actual value of what you’re working on. For example, while the obvious benefit of making it easier for customer support team members to find the data they need is the amount of time that it can save, this efficiency can also allow the support department to focus on higher-value tasks and reduce future hiring costs, providing clear financial savings, too.

What This Process Looks Like at Braze

At Braze, our internal tools team recognized that we needed a strong foundation to build our metrics on. We started out our scoping process by adding in an additional step—namely, running an assumption mapping exercise with our team. We wrote down all the assumptions we had about our users’ friction points: Users don’t like W, but they love X; users are concerned about Y; or stakeholders really want to see more of Z. Once we had a list of individual assumptions, we grouped all of them into themes, and used those themes as a springboard for determining our research hypothesis.

Next, we used our stakeholder interviews to validate the friction points we’d laid out in the assumption mapping exercise. We interviewed folks from nearly every team that touches our internal tooling (like Support, Success, Product, and Engineering), with the goal of getting as representative a sample as possible from across the company. We found during this process that the people we interviewed surfaced a ton of additional friction points beyond the ones we’d mapped out already, enriching our understanding of the places where we might be able to add value and support efficiency.

Now we’re taking those insights, validating them with data or qualitative insights from surveys and feedback, and using them to inform a long-term roadmap for improvements that can be supported by internal tooling. Each project has a dedicated metric associated with it, such as time saved, support tickets reduced, or improved satisfaction scores.

Final Thoughts

While we’ve come a long way, we’re still learning—alongside other teams at Braze—how best to maximize our impact. Making sure the impact that internal tooling has on other teams is concrete, measureable, and scalable is a major part of the challenge (and part of the fun!) associated with building something amazing together.

Interested in building something amazing with us? Learn more about Braze and check our our open postings on the Braze careers page.