I like product telemetry.
I have spent enough of my career around networks, observability and software instrumentation to be suspicious of any operating model that relies entirely on opinion.
At IBM I owned the global Digital Customer Success and product-led growth operating model across 34 software businesses and more than 30,000 customers. With Instana, part of the work involved defining the telemetry and instrumentation that helped us see what customers were genuinely adopting, which capabilities they reached and where they stalled.
That information was useful because it changed what we could do. It supported different engagement models across a very large customer base and gave us a way to test Customer Success plays against actual behaviour rather than simply counting activity.
One lesson from that work has stayed with me:
Engagement is not adoption, and adoption is not automatically value.
Activity is easy to count
Software teams can instrument features, sessions, workflows, seats, events and journeys. We can see whether a user reached a particular part of the product and whether usage changed after an intervention.
The risk comes when we quietly upgrade what the metric means.
A customer using a feature is evidence that the feature is being used. It may also be good evidence of adoption. It does not, by itself, establish that the customer achieved the business result that justified the purchase.
Sometimes the relationship between behaviour and outcome is strong and direct. Sometimes it is weak. The distinction matters because teams naturally optimise what they can measure. If success is defined as logins, we will produce more logins. If success is defined as feature adoption, we will design plays to move feature adoption.
The harder question is whether those behaviours are connected to the customer's objective.
We cut plays that moved engagement without moving adoption
One of the useful disciplines in the IBM work was testing engagement plays against the data.
A campaign could look successful in the usual sense. Customers responded, clicked or attended. If the behaviour we actually cared about did not change, that mattered more. We cut plays that created engagement without producing the adoption movement we were trying to influence.
I think the same discipline needs to continue one level further.
When an adoption metric moves, what does that tell us about value?
The answer depends on whether the adoption event has a defensible connection to the customer's objective.
An adoption model needs an outcome model
Imagine two customers using exactly the same feature. For one, that feature is central to the reason they bought the product. For the other, it is useful but peripheral.
The telemetry event is identical. The commercial meaning is different.
That is why a useful post-sale model needs to preserve more than product behaviour. It needs context: what the customer is trying to achieve, which capabilities are relevant, what behaviour would indicate progress and what evidence the customer would consider meaningful.
Without that context, adoption can become another generic score. It tells us what happened inside the application but leaves people to reconstruct what the activity means.
First value, adoption and provable outcome are different moments
In the working Routeability model I separate first value, adoption and provable outcome because they may occur at different times.
A user may get value very quickly. Broader adoption may take longer. The business result may take longer again, and it may depend on process or organisational changes that sit outside the product.
That does not make product telemetry less useful. It makes the interpretation more disciplined.
We can say a customer reached a capability. We can say a pattern of usage changed. We may be able to say the behaviour is consistent with progress. We should be more careful about saying the business outcome has been achieved until the evidence supports it.
Better telemetry changes the intervention
The goal is not to build the perfect measurement system. It is to make better decisions earlier.
If the telemetry shows that a customer has not reached a capability that matters to their objective, that may trigger one kind of intervention. If the product shows strong adoption but the customer still cannot articulate the value, the intervention is different. If the result has been achieved but the evidence is not reaching the stakeholder who needs it, that is different again.
The data becomes more useful when it helps distinguish those situations rather than compressing them into a single health score.
Human judgement still matters because some outcomes are easy to connect to product events and others depend on process change, financial impact or stakeholder judgement that will never appear cleanly in telemetry.
The question I would add to any adoption dashboard is:
What customer outcome do we believe this behaviour contributes to, and what evidence would tell us that contribution is real?
That question is harder than counting usage. It is also much closer to the reason the customer bought.
