Measuring success for enablement products and teams

6 ways to measure value delivery for products and teams that live behind-the-scenes

In larger companies, it’s not uncommon for a whole swathe of teams to be once removed from the company’s end-customers. There are countless examples, from internal tooling and developer enablement through to backend architecture, design component support, localisation / internationalisation, data transformation and platforming — the list goes on. These teams have stakeholders or products that stand between them and delivering end-customer value, and their impact on end-customer metrics isn’t nearly as clear as those implementing features to be directly interacted with by end-customers.

Understandably, this puts product managers in a peculiar position when company visions are always (and necessarily) centred around end-customer value delivery. As I’ve previously explored, when you’re in this situation as a backend team, it’s often most useful and valuable to frame and treat the stakeholders that stand between you and end-customers as if they are your end-customers.

The question does remain though, how exactly can you define and measure success for these enablement products and teams?

It’s very easy to tie yourself in knots as a product manager trying to draw a clear line between your enablement work and end-customer value. In my experience however, avoiding trying to do this altogether is actually the key to setting fair, actionable and valuable success metrics for enablement products and teams.

Defining and measuring success is made much simpler by framing and treating your stakeholders as your end-customers. After all, enablement teams are solving business problems for company stakeholders. Your stakeholders are your addressable market — identify, observe and deeply understand them, their workarounds and the jobs they need to get done. Deliver things that fill unmet needs and relieve pains for them.

As usual though, unfortunately there is no one-size fits all in terms of measuring success. It depends on what your product is and what value you’re attempting to deliver to your users. That said, below are a handful of measurements I’ve found useful for setting direction, understanding problems and demonstrating the success (or failure) of enablement products and teams.

Some of these might seem obvious, but often the simplest things work best. One thing I have tried to do here is capture areas of measurement that should apply to most enablement or end-customer-removed teams to some degree or another, but it is by no means an exhaustive list.

1. Breadth: Are stakeholders adopting your product?

This is perhaps the common enablement team metric. If you have 10 potential stakeholders of your enablement product, then there’s your addressable market. It’s up to you to increase adoption of your product from 0 upwards to the addressable market ceiling of 10.

For example, take building a data pipeline and platform product for centralising the company’s data into one place and say there are 50 identified stakeholders you need to integrate. There’s your addressable market, and stakeholders meaningfully adopting your data pipeline and platform improves your product’s adoption percentage across the company. Breadth also empowers you to monitor if there is regression of adoption over time.

2. Satisfaction: How valued are you by your stakeholders?

This is a biggie, and it’s sadly an often forgotten measurement of success in enablement product contexts. Far too regularly for enablement products, proper customer satisfaction analysis and real user feedback is skipped over or assumed without the same level of rigour as end-customer satisfaction. You don’t want to build something that merely ‘solves’ a problem, you also want to relieve the pain associated with that problem for your stakeholders.

When in doubt, book in as many real (and potential) user interviews with your stakeholders as you can. Sit with them and chat about or have them walk through how they get things done day-to-day— you’ll be surprised with what you learn and what makes them tick.

For example, let’s say you’re in a team that develops and manages the company’s common design component system. Sure, you might achieve adoption (possibly by company-line force), but do your stakeholders see your team and product offering as a saviour, or a pain in the neck? Do you make it easy for them to make requests? What more could you do for them? If you measured their satisfaction with your product, you’d be able to track improvement (or regression) over time.

Satisfaction measurements can take many forms, both qualitative and quantitative — from net promoter scoring to customer effort scoring to user sentiment analysis. Experiment with different ways and see what generates the most useful and actionable feedback for your product or team over time.

3. Depth: How deeply do you resolve pains?

How thoroughly do you understand your stakeholders’ problems and workarounds? How deeply are their pains addressed by your scope? Should you expand or alter your scope?

This one is another measurement often forgotten about in enablement product contexts. Ultimately you want to address pain points, but it is all too easy (just as in any other kind of product) to jump to solutions and rely on assumptions about what your customers ‘need’. Depth measurement is concerned with how significantly your stakeholders engage with your product. This is interesting because adoption only goes so far.

For example, let’s say you own a data transformation team that utilises centralised data to provide business-level reporting and insights. While you could provide run-of-the-mill reporting on some key business metrics asked for and call it a day, you could also dive deeper. Do you deeply understand the questions your users are looking to answer through the insights you provide? Is there information they don’t actually realise they want? What supplementary insights could provide greater context to the data? What data are you lacking that they might assume is captured, or what caveats are there to the data you’re providing?

Metrics for depth are complex and very product specific. In this case — metrics might include engagement with the different data views you provide, time spent reading and manipulating the insights, how often your reports are shared with others, the average volume of feature requests that come from a stakeholder, or could even take the form of a satisfaction metric.

4. Frequency: Regularity of use, retention

It’s all well and good to have an enablement product ‘adopted’ by a stakeholder, but do they actually use it? How often do they use it to relieve their pain? How often to they engage with specific features you believed would help them?

This metric is akin to retention — i.e. how often people come back to and use your product. While the retention window / cycle will vary depending on the product, it matters that the stakeholder is using your product with regularity.

For example, take a developer enablement tooling team that is building project cookie-cutters for company stakeholders to assist with speeding up early stages of the development lifecycle. How often do stakeholders actually use these cookie-cutters? How often do they use them compared to another option? How many stakeholders that use the cookie-cutter for the first time return and use the cookie-cutter for a second or third time?

Admittedly, this is slightly less useful or at least more tedious when the company forces a stakeholder to use your product (take an enforced data platform or developer tooling for example). However, frequency metrics can still be useful despite this situation. Frequency metrics could help to identify stakeholders not using the company provided solution, help to prioritise which enablement products or features require the most attention for maintenance and continuous improvement, or even show you what optional features go unused and could be deprecated.

5. Efficiency: What time do you save?

The underlying purpose of so many enablement products and teams is to address a company demand for efficiency or introduce standardisation for the purpose of efficiency. In other words, to help stakeholders more quickly get a job done, increasing their shipping velocity for the benefit of end-customers.

Efficiency metrics are concerned with improving the time and effort it takes to get through a workflow. There are many ways to measure this depending on what you’re building, from theory of constraints analysis to pure ‘time to get X done’ measurements.

For example, say you are a tasked with building a backend platform and API for integrating supply-side partners into the stack. You could have it built so every partner you’d ever imagine you might want to integrate with could do so, but this could very well make any given single integration a complex and lengthy process. Does your solution standardise at the cost of efficiency, or does it strike the right balance of the two? Does it help the supply-side integration teams get their job done faster? Efficiency could be the competitive edge you need to get ahead of your competitors.

Efficiency is a great one when you can’t impact direct end-customer metrics, it just takes some pre-thinking. Start with measuring baseline time taken or effort involved for whatever it is to be made more efficient, then take steps to improve that while monitoring qualifying metrics to ensure that quality isn’t inadequately suffering at the cost of speed.

6. Conduit Metrics: Can you represent end-customer value improvement via data slicing?

This one is definitely a more advanced one and not as applicable for all enablement products and teams, but I’ve found it incredibly powerful. This type of metric involves you slicing an end-customer metric in a way that shows deficiency as a result of the pain points you hope to address.

One of my favourite examples of this is EIJAL scoring (English is just another language) in the context of globalisation enablement teams. While a globalisation team isn’t responsible for a specific feature, they’re attempting to improve the internationalisation and localisation of a product for the benefit of end-customers in globally targeted markets (and languages).

As people in English companies disproportionately favour English in their thinking, designing, programming, and solution-building, English is actually good rough proxy for “easy”, “our best effort”, and “ideal state” in the vast majority of cases. Products built in English are biased for English users, so cutting end-customer metrics by market and especially by locale, and comparing that against your English performance gives you a conduit metric that represents your enablement team’s influence on an end-customer metric.

Conduit metrics are fantastic when you can use them, as opportunity size before engaging in a piece of work can be calculated roughly in dollar amounts. Say your English conversion rate was 50% better than in non-English languages — you’re leaving a lot of money on the table for not focusing on other languages alone.

To summarise

• Frame and treat the stakeholders that stand between you and end-customers as if they are your end-customers.
• No need to be fancy — sometimes the simplest metrics work best.
• The six measurements noted here were Breadth, Satisfaction, Depth, Frequency, Efficiency, and Conduit metrics.
• Unfortunately there is no one-size fits all in terms of measuring success — some will definitely apply and work better than others for your enablement product or team.
• When in doubt, I’d bias toward starting with stakeholder satisfaction. This will reveal pains worth solving, then you can flesh out metrics around these.