Product teams love usage because usage is visible. Someone clicked. Someone logged in. Someone created a report. Someone ran the workflow. The graph moved.
That feels like proof. Sometimes it is proof of exactly one thing: people used the product. That is not the same as proving the product created value.
Activity is a step in the chain
Imagine a procurement platform launches a new workflow. Adoption rises quickly. More buyers use it every week, and the product team reports success.
But procurement cycle time has not improved. Users are still doing manual work outside the system. Suppliers are not getting paid faster. The business outcome is flat.
What happened? The team measured the easiest part of the value chain. Use. A more complete chain looks something like:
Use → behavior change → customer outcome → business outcome
Usage matters. It is just upstream.
We measure usage because it is convenient
Usage has several advantages. It is usually available quickly, product teams can instrument it, and it is easier to attribute to the feature than a company level metric. It gives teams a sense of movement. And usage often is a necessary condition for value. A feature nobody uses is unlikely to create much value.
But necessary is not sufficient. A customer can use a feature because it is mandatory, because the old path disappeared, because they are experimenting, or because the feature simply moved work from one place to another. An experience can generate activity without making the job better. The graph cannot tell you which story is true by itself.
Ask “and then what?”
This is one of my favorite product questions. Adoption increased. And then what? People created more forecasts. And then what?
Teams opened the risk dashboard every day. And then what? Customers used the AI assistant. And then what? If the answer is another activity metric, keep going.
Eventually you should reach something that matters to the customer or the business: fewer late shipments, faster decisions, lower audit effort, higher renewal, reduced cost to serve, better conversion, less waiting, fewer errors, more revenue, or some other meaningful outcome. The exact answer depends on the product. The discipline is making the causal story explicit.
Value does not always mean immediate revenue
I do not want this argument reduced to “everything must map directly to dollars.”
Product teams create customer value that may appear before or outside an immediate financial outcome. Trust. Confidence. Ease. Speed. Reduced cognitive load. Better collaboration. Reliability.
Those can be legitimate outcomes.
But be clear about what value means. If you say the product creates confidence, how do you know? If you say it saves time, where does the time go? If you say it improves a workflow, what behavior changed?
Product value should be observable enough that the team can learn whether its hypothesis about the value is holding up.
A popular feature can still be a bad investment
This becomes especially important when usage has cost. An AI feature can have extraordinary adoption and weak economics. A free tool can become beloved without creating a sustainable path to value. A feature can keep customers busy while distracting from the workflow that actually drives retention. Usage can consume support, compute, roadmap capacity, attention, and customer time.
That is why I do not want teams celebrating usage in isolation. The question is what the usage produces.
Build a measurement ladder
For consequential product work, I like a simple ladder: Activity: Did people use it? Behavior: Did they do something differently? Customer outcome: Did their work or experience improve? Business outcome: Did the change create value for the company?
Not every experiment or small release needs all four measures. But the team should know where it is on the ladder. If all you have is activity, say that. Do not smuggle the business conclusion into the adoption metric.
Usage can even conceal a worse workflow
More activity is not always neutral. A new feature may force users to perform steps the old process did not require. A dashboard can create more checking because people do not trust the underlying data. An AI assistant can generate more follow up review than the manual process it replaced. Usage goes up because the product created more work.
That is why behavioral context matters. Look at the surrounding workflow: time to completion, rework, error, workarounds, drop off, human review, and the amount of effort required before and after the new interaction. Sometimes the most valuable product improvement causes a usage metric to fall because the customer no longer needs to touch the system as often.
Product teams need the discipline to disappoint themselves
The hardest version of measurement is when the usage chart is green and the outcome is not.
That is when teams become creative. Maybe retention needs more time. Maybe the cohort is wrong. Maybe we need another metric. Maybe the feature is strategic.
All possible. Also possible: the thing people are using is not creating the value we thought it would. That conclusion is painful. It is also useful, because now the team can learn.
The product is not successful because the graph moved
Usage tells you something important. It tells you people interacted with what you built. Celebrate that when it matters. Then keep going.
What did the interaction change? What became easier, faster, safer, cheaper, more reliable, or more valuable? What happened to the customer? What happened to the business?
If you cannot answer yet, you do not have to declare failure. You do have to be honest about what you know. Usage is evidence of behavior. Value is the consequence. Do not confuse the two.