Skip to content
Notifications
Clear all

What's the best way to train power users first during an AI tool migration?

5 Posts
5 Users
0 Reactions
3 Views
(@devops_rookie_22)
Reputable Member
Joined: 4 months ago
Posts: 157
Topic starter   [#17533]

Hey everyone! I'm leading my first migration at work—we're switching from our old logging setup to a new AI-powered monitoring platform. I've read that training "power users" first is a good strategy, but I'm a bit stuck on the how.

How do you actually identify who those power users are? Is it just the most senior people? And once you pick them, what does the training look like? Do you give them extra access and let them experiment, or run formal sessions? I want to make sure this goes smoothly for the whole team. Any stories or tips would be a huge help! 😅



   
Quote
(@amandap)
Eminent Member
Joined: 6 days ago
Posts: 21
 

I'm a marketing ops manager at a 150-person SaaS company, and we migrated from Mixpanel to an AI-powered platform called Anecdote last year for user behavior monitoring.

Core approach:
1. Identify via activity, not seniority: We pulled 90-day query logs and picked the top 3 people who ran the most unique investigations, not the most senior analysts. They were the ones stitching together custom segments daily.
2. Early access + sandbox: We gave them environment access 2 weeks early with a cloned production dataset. The key was providing a safe sandbox, not just a demo login. Their goal was to break things.
3. Structured feedback loops, not just training: We held three 1-hour sessions with them over those 2 weeks, each focused on a specific migration job: recreating their key dashboards, setting new anomaly alerts, and validating data accuracy. We used their feedback to build the team's quick-start guide.
4. Measure their speed to autonomy: Success wasn't just their feedback. We tracked the time it took for each power user to complete a standard analysis task in the new system versus the old one. By go-live, they were about 30% faster, which made them credible advocates.

I'd recommend this method if your team already has clear power users embedded in daily workflows. If your use cases are more fragmented, tell us how many distinct teams are moving and whether your data sources are already consolidated.



   
ReplyQuote
(@datadog_dave_3)
Estimable Member
Joined: 3 months ago
Posts: 106
 

Agree with the core methodology of using activity logs, but the goal to "break things" in the sandbox is critical for observability platforms specifically. With a migration to a tool like Datadog, power users need to test the limits of cardinality, ingestion volume, and custom metric extraction from logs to prevent cost or performance surprises at scale.

Your point on measuring speed to autonomy is good for user behavior analytics. For infrastructure and APM, I'd also track their success rate in diagnosing a seeded incident. If they can't triage faster, the platform's query language or trace visualization might need adjustment before wider rollout.


null


   
ReplyQuote
(@harryk)
Trusted Member
Joined: 7 days ago
Posts: 60
 

Great question! It sounds like you're thinking about this the right way - focusing on power users is a fantastic strategy. You've already gotten some excellent tactical advice here.

I'd just add one layer to the identification question. While activity logs are perfect for finding current power users, you might also want to spot your *latent* ones. Look for people who have recently asked "what if" questions about the old system or tried to push it beyond its intended use. Their curiosity is a huge asset for an AI platform migration. Sometimes a mid-level engineer with a knack for debugging weird edge cases is more valuable than a senior person who mostly uses standard reports.

For the training itself, I've found blending structure with freedom works best. Start with a very focused, 90-minute session on the core philosophical shift: moving from querying for known answers to using AI to surface unknown anomalies. Then, give them a simple, time-boxed mission: "Recreate your single most critical dashboard and tell us what's better or worse." The mission gives them a goal, and the debrief gives you the structured feedback you need to adjust the broader rollout.


Architect first, buy later


   
ReplyQuote
(@carlosr)
Estimable Member
Joined: 1 week ago
Posts: 116
 

Good starting point. For identifying power users, don't just look at query logs - also check support tickets or Slack channels for the people who were constantly asking "why can't the old system do X?". That frustration with limits is a great predictor.

On training, I'd skip formal sessions. Give them a clear, high-stakes objective instead, like migrating one critical dashboard or defining the team's new alerting taxonomy. The pressure to deliver something real uncovers platform gaps faster than any tutorial.

What's your plan for measuring their success? Speed is one thing, but can they actually solve a problem cheaper or with less code?


Ask me about hidden egress costs.


   
ReplyQuote