Metrics question

Pick one platform-level growth capability for Glean's enterprise context: invitations, notifications, in-product education, or lifecycle messaging. Design it so it creates team-wide adoption rather than just repeat usage by one person, and explain the core loop, the main risks, and the metrics you would use to know it is working.

Practice this question out loud. An AI interviewer asks it, follows up like a real interviewer would, and scores your answer. Type or speak.

What this question tests

Ability to design a growth mechanic for enterprise wide adoption, distinguishing team wide spread from single user engagement.

Pick one capability, for example invitations, and define why it specifically drives team wide adoption: an existing user inviting teammates directly expands the user base rather than deepening one person's usage.
Design the core loop: an active user finds value, is prompted to invite a specific colleague relevant to a real need, for example sharing a useful search result or answer with a teammate who would benefit, and that colleague activates.
Ground the trigger in genuine value rather than nagging, for example prompting an invite right after a moment where collaboration would naturally help, like finding an answer the user wants a teammate to see.
Name the main risks: invite fatigue if prompted too often, low quality invites sent just to dismiss a prompt, and admin discomfort if invitations bypass IT controlled provisioning.
Mitigate the provisioning risk by tying invitations to existing enterprise directory permissions rather than allowing fully open invites in an enterprise context.
Define metrics: invite to activation rate, share of new active users originating from an invite, and team level coverage, the percentage of an eligible team that becomes active, as the true adoption signal over raw invite volume.

Chooses one capability and explains specifically why it drives team wide spread rather than single user repeat usage.
Grounds the invite trigger in a genuine value moment rather than a generic growth nag.
Names a real enterprise specific risk, invitations bypassing IT controlled provisioning, showing context awareness.
Picks team level coverage as the core metric instead of raw invite count, which better reflects true adoption.

Picking a generic consumer growth loop that ignores enterprise specific risks like admin control and provisioning.
Measuring success by invite volume rather than actual team wide activation.

How would you prevent invite fatigue from hurting the metric over time?
What would you do if invitations to teammates outside a customer's eligible license count caused billing friction?