Discuss Usage Data Without Treating It as a Research Outcome

A program manager pulls up a usage dashboard before a review and asks you, the customer success scientist on the call, whether the numbers mean the science is working. The dashboard shows logins, completed sessions, and support tickets. None of that tells you whether a hypothesis held up or a biological result replicated. Your job in that moment is to hold a line that gets blurry fast under pressure, usage data describes behavior, and scientific conclusions belong to the people who designed and ran the research.

Why this conversation goes wrong

Program managers live under pressure to show that a rollout is paying off. A dashboard full of numbers feels like proof, and it is tempting to round "people are logging in" up to "the research program is succeeding." You get pulled into that rounding because you understand the science, and the manager assumes your judgment covers both the platform and the biology.

Usage counts and scientific validity answer different questions. A high login count can mean a workflow is mandatory, not that it produces good science. A low count can mean a small, focused team is running exactly the experiments it needs. Let a manager walk away believing usage numbers validated their research, and you have handed them a conclusion neither of you can support. That conclusion gets repeated up the chain, and when it turns out to be wrong, the credibility damage lands on you as much as on them.

How to prepare before the review

Before you sit down with a program manager, get specific about what the dataset actually contains. Know exactly what activity is being logged, logins, completed workflows, exports, or something else. Know which users are included, and whether contractors, trainees, or inactive accounts are mixed in with the core research team. A number that includes accounts nobody uses anymore will always look worse than reality.

Check the collection method too. Ask whether the tracking covers every access point or misses a portion of usage because of a separate login system, a mobile app, or an offline mode. A team that lost access for two weeks during a system migration will show a dip in usage that says nothing about their science or their engagement.

Identify the research owner before the meeting starts. Know who the principal investigator or research lead is for the program in question, so you can name that person the moment the talk turns toward biological findings or hypothesis strength. Naming them early, rather than fumbling for a name mid meeting, keeps the redirect calm instead of evasive.

Decide what you want out of the review too. Usage data is genuinely useful for defining adoption. Walk in with your own question ready, something like what behavior would tell us this rollout succeeded, so you can move the conversation from a vague verdict toward a metric the manager can actually act on.

What to say

The program manager opens with the question you expected. "Does high usage mean our science is working?"

You answer directly, without hedging and without pretending the question is unreasonable. "The records show activity, logins, completed sessions, support tickets. They cannot tell us whether the science is working. That call belongs to your research lead, since it depends on the results themselves, not on how often people opened the tool. What I can help with is defining whether the workflow is being adopted the way you intended."

The manager pushes back a little. "Sure, but usage is way up this quarter. Doesn't that count for something?"

You stay concrete instead of getting defensive. "It counts as evidence that more people are using the tool. That is worth knowing. It does not tell us if the work they are doing in it is producing good results. Those are separate questions, and mixing them tends to produce a metric that satisfies nobody once someone asks a harder question later. What would you consider healthy adoption for this program? A target number of active users, a certain frequency, something else?"

The manager pauses. "Honestly, we never agreed on that. We just watched the numbers go up and assumed that was good."

That admission is the real outcome of the conversation. You have not answered a scientific question you were never equipped to answer, and you have surfaced the actual gap, an undefined adoption target, that the review should have been about from the start.

Mistakes to avoid

A few habits turn this conversation from useful to misleading.

1. Answering the science question directly because it feels helpful in the moment. Even a hedged answer like "it looks promising" gets repeated later as your professional opinion on the research, not a guess about a dashboard.
2. Letting silence stand in for agreement. If a manager states a scientific conclusion and you move on without correcting it, they treat your silence as confirmation.
3. Presenting raw numbers without the context that makes them interpretable. A login count without knowing who is included, or a usage spike without knowing about a mandatory training that forced it, invites the wrong conclusion.
4. Skipping the redirect to the research owner. Naming the principal investigator is not a way to dodge the question, it is the accurate answer, and skipping it leaves the manager thinking you are the right person to ask next time too.
5. Leaving the meeting without a defined adoption measure. If usage data comes up and nobody leaves with a shared idea of what a good number looks like, the same confused conversation happens again next quarter.

How to practice and score it

This conversation is easy to describe and hard to run well under real pressure, especially when a manager wants reassurance and you want to give it to them. Practicing it with a realistic counterpart, the kind of rehearsal DealSpeak is built for, lets you make the mistakes in private instead of on a live call.

Build a small practice dashboard with three fields, active users, completed sessions, and support tickets, and nothing else. Have the trainee walk through it and produce one accurate observation about what the data shows, plus two questions that stay genuinely open, such as what counts as healthy adoption and where the research owner should weigh in. That exercise forces a trainee to separate description from conclusion instead of filling gaps with confidence.

A manager scoring the session should watch for three things. Did the trainee keep activity data and scientific conclusions clearly separate, without letting one bleed into the other. Did they name the actual research owner instead of taking on that judgment themselves. Did they still move the conversation forward, landing on a concrete adoption question instead of just repeatedly declining to answer. A trainee who does all three has handled the review correctly, even if the program manager leaves without the reassurance they came in hoping for.

If your team is building out a broader training plan, pair this scenario with sessions on gathering real user feedback. A piece on how to Run a User Feedback Session Before Planning More Research Training covers the listening side of this work, and a companion post on how to Use User Office Hours to Gather Adoption Feedback covers an ongoing format for the same goal. You can find more Biotechnology practice conversations built around reviews like this one.

Usage data will keep showing up in these meetings, and program managers will keep hoping it answers more than it can. Your job is not to withhold the numbers, it is to describe them accurately and hand the scientific verdict to the person who actually owns it. Get that split right consistently, and the metrics conversation becomes useful instead of a source of false confidence.