Inside the XBOX Insider Advantage: Using Player Feedback to Guide Development

Game dev can be hard. There's a lot to learn, social networks to build, and always new problems to solve. Microsoft wants as many game developers to succeed as possible, and we want to help you on your journey. That's why, every Friday morning at 11:00 AM Pacific, we invite the game development community to join us on our official Discord for Office Hours. By creating an open and welcoming community space, one where you can make connections with real industry professionals and ask questions about the issues that are most important to you, we're making more resources accessible to developers of all sizes from across the globe. Each week, we invite an experienced game developer to join us, tell their story, and answer any questions you might have about their work. If you'd like to keep up with who will be joining us and what topic we'll be covering, join our Discord server and keep an eye on the #announcements channel for calendar updates!

Before we get to this week's guest, a quick bit of news. A Godot sample landed this week, and with it, a plug-in integration model for the GDK. If you've ever wondered what it means for Microsoft to "support" an engine, this is a good, concrete answer. Every engine team decides how much pre-built integration they want. Unreal has a plug-in model. Unity has a plug-in model. Now Godot has one too. The interest in Godot has been real for a while (the raw numbers aren't Unreal or Unity numbers yet, but that's a bit of a chicken-and-egg problem), so this is a nice step forward. The team will be joining us next week to dig into it properly, so save your questions and join us for office hours Friday, June 12, 2026 at 11:00 PT.

Meet Brad

On Friday, June 5, Brad Rossetti joined us to talk about flighting and the XBOX Insider Program. If you've ever seen a game quietly show up in the XBOX Insider Hub and wondered how it got there, Brad is one of the people who built the road it traveled on.

Brad's an Aussie who landed in Seattle, and he's been at Microsoft for 27 years. This is, by his own count, his third career. Before Microsoft he worked for a telephone company in Australia putting in a cell network ("which failed, because it was basically walkie talkies, and Australia's big"), then did telephone and yellow-pages systems in Asia, then came to the US through consulting. Gaming was always the passion. He grew up with three TV channels, an Atari, a Commodore 64, and a homemade racing simulator he built with his Carpenter dad. At Microsoft, he started as a consultant, moved into IT and infrastructure, then helped a team modernize XBOX Live. The first game he worked on was Titanfall, building the back-end Thunderhead services. He's been in XBOX for about 15 years, and today his team sits inside XBOX user research, which (as you'll see) turns out to make a lot of sense.

He also has, on Clint's authority, one of the coolest sim racing setups any of us have seen. We'll come back to racing.

So what is flighting, exactly?

Here's the origin story, because it explains everything that follows.

Cast your mind back to the Durango days, the XBOX One that looked, let's be honest, a little like a VCR. A firmware update went out for the disc drive, and it bricked consoles. Not a good day. The lesson the team took from it was that you cannot meaningfully test a console operating system in a lab. You have to test it in the real world, at scale, in actual living rooms.

So they built a program to do exactly that. The console team ships a recovery, a kind of sample operating system, five times a week, and flights builds every single day. To test all that, they recruited gamers around the world who wanted early access in exchange for telling Microsoft what broke. That's the XBOX Insider Program. Members run the builds, hit the "report a problem" button on the console, and that single action sends back telemetry, an actionable bug, and the last 30 seconds of video and screen captures.

That console foundation is where game flighting grew from. The first game customer was Sea of Thieves, which built its own Insider program for pre-release feedback (and gave the whole thing its name). The job now is audience segmentation: a global audience that matches a profile, an NDA audience under a non-disclosure, or a research-recruited audience for a specific region. All developers need to do is  publish a package in Partner Center for console or PC, and the XBOX Insider Hub delivers it securely to players who don't own the game. No entitlement changes hands. The system creates a consumable that points at your package, then removes it when you're done. The player gets to help you iterate, and never owns something they shouldn't.

Getting your game into a flight

Q: How does a game actually get into the XBOX Insider list? What are the requirements?

A: It's lighter than people expect, because it's a managed program. You reach out to us by email (the address is on the last page of my deck and up on the dev notes), we respond and get a quick understanding of your scope, and then we walk you through an onboarding deck. The setup itself is roughly a three-day SLA. We like a couple of weeks' notice if there are tokens to sort out, but the front door is genuinely just an email. From there, Tim and the team set up an interactive call and onboard you.

Q: How do you build the audience?

A: All we need is gamertags. We create an audience, you prop your build in Partner Center, and you target that build at the audience by seller ID. That's flighting in retail, in a nutshell: an audience, a build, distributed securely so it can't be compromised or pulled out from under you.

The feedback you get back

This was the part developers leaned in on, so we slowed down here.

Q: What does the feedback loop actually look like? What lands in my inbox?

A: We produce what we call a **Justifier report**. The name is an old console-team joke (it started life as a much blunter phrase), but it's simply a daily bug report for your title. It's an HTML report that gathers up every "report a problem" submission: a short video clip pulled from the last 30 seconds of Game DVR, some screen captures, and the player's own comments about what they hit. Because of privacy laws it's a little obfuscating, but your account team and ID team can work with you to fill in detail. We're not duplicating storage to do any of this, by the way. We lean on Game DVR and Azure blob storage to manage the captures.

Q: How do I access all that securely?

A: We set up a secure SharePoint for each flight, and the report points back to it. We don't hand out access to our actual bug database, because there's other first-party and third-party data in there that simply isn't ours to share. The SharePoint keeps player privacy and title privacy intact, and we can share the videos out from there. After a flight, we can also run surveys to quiz players on the experience and wrap the constructive feedback up for you. It's all free.

Q: Are there bugs you see over and over?

A: On console it's often "how do I get access to a feature" or a game that failed to launch. On the game side, honestly, it can be as simple as "unable to join multiplayer sessions." That's exactly why a multiplayer game is a great candidate for testing at scale, so you can see how your back end, PlayFab included, holds up. One of my favorite examples is from about ten years ago. A couple of university students iterated on their ID title with us for a year and a half, and they ended up changing their level design because the feedback was so direct. They even asked to spin up a Discord channel in parallel so they could talk to players in real time. That's the flexible version of what this can be.

Streaming, other platforms, and what's next

Community member Maddy asked the obvious modern question: what about Mac, or arm, or other operating systems?

Q: Can players on other platforms get in on this?

A: For a native experience you'd need a native build for that OS. But streaming is where it gets interesting. Last year, before id Software launched their latest Doom, we ran weekly play tests with internal employees and about 60 external gamers under NDA. We captured video of people actually playing, streamed from the console, using a video playback tool we've been building with our research and telemetry teams. Every week the dev could sit down and watch where players got stuck, hear them say "I'm lost here," and tie it back to telemetry. That real-time picture, video plus survey data while someone plays, is exactly what we're hearing developers want. We think of it as flighting's next chapter.

Q: (from Ethan) Are there good resources for learning how to run AAA-scale play tests?

A: Honestly, not a formal one yet, though teams like The Coalition are picking up best practices from Turn 10 and sharing them around. Clint jumped in here, because this is exactly the kind of gap his Dev Ed team exists to fill. He's tracking it as a community request, which means it lands on the top-needs list, gets assigned, and turns into a doc on Microsoft Learn (PlayFab already has a fair amount on play tests and live ops to build on). Ethan, consider yourself signed up to review the result.

Q: What about PlayStation, Switch, or Steam?

A: We haven't built tooling for Nintendo, but we can help recruit an audience and provide the code. For teams like the ones behind Gears and Forza, we've helped them run their own flighting on PlayStation and on Steam using our toolset. And Discord keeps coming up as the feedback mechanism teams love (id and Bethesda both lean on it), so we use it in the back end for real-time chat during play tests.

Clint asked the question a lot of you have been circling: is self-service flighting coming?

Q: Will developers ever be able to flight without the hand-holding?

A: That's where the move into user research pays off. Picture this: you go into Partner Center, say your package is ready for PC, and push it to one of a few ready-made shell audiences. An FPS audience, a platformer audience, an RPG audience, maybe a couple thousand players each. Those players already expect a new game every week, and they'd see it surface in a new section of the PC Xbox app. Self-serve for you, a steady stream of games for them. We're working through it now with an internal product team that wants exactly this. I'll set expectations, though: we have a firm rule about not committing to public timelines, so consider this a sneak preview rather than a promise.

Designing for the first 30 minutes

We turned the table around and asked Brad what he wishes developers were more ready for. His answer was both practical and a little tough-love.

Q: What's the thing developers are least prepared for going into a play test?

A: Honest feedback. People can be blunt, and you have to be ready to take it. We get it ourselves all the time ("your Insider program has too many login screens"), and we have to absorb that too. The pattern I'd most like to see die is gating players at step one. A game launched this week whose very first screen was "create an account on our service." Please don't do that. Bring the player into the game first.

One bit of advice has stuck with me for years, from Eric Norsteter, who used to run XBOX Live. Reward the player in the first 30 minutes. Make them feel like part of the game, even with something small like an early achievement, and walk them through it. Keep your controls consistent (don't tell me it's A to jump on one screen and B to jump on the next). And if someone hasn't played in 30 days, welcome them back and remind them how. We've all loaded an old save and felt like Gandalf saying "I have no memory of this place." (For the record, my personal version of this is going back to Red Dead Redemption 2 and shooting the person I meant to talk to. Every time.)

If you want to know when a player last touched your game, by the way, there's telemetry for that through XBOX game services and PlayFab Foundation services, and similar data through Epic Online Services.

Accessibility is for everyone

Q: Is there a player audience you wish you heard from more?

A: Honestly? Disabled gamers, and gamers with accessibility needs. It slapped me in the face over the last few years that even our own app sometimes isn't accessible. Making a game accessible can be as basic as making it readable. Can I read the subtitles? I watched my mother-in-law, who just turned 80, try to play one game on a phone and keep accidentally installing new ones because every ad looked like the thing she was supposed to tap. There's a market there we keep overlooking. Some games do this beautifully. Last of Us did an amazing job. Others drop the ball.

Jen made the point that lands every time: when you fix accessibility, you improve the experience for everyone. Bigger subtitles help people who never thought they needed bigger subtitles. Brad agreed, and brought a hardware example. When the team flighted a recent accessory, he pushed to include players with accessibility needs in the test, and the feedback reshaped how they thought about the product. It's the same arc as the XBOX Adaptive Controller, which inspired add-ons from Logitech, from Sony, and from the 3D-printing community.

Clint tied it to a phrase from a former manager: "you fix what you measure." If we can connect the active, vocal communities of disabled gamers into your play tests, you get feedback from that audience, and you fix what you measure. You might even end up on the front page winning a Gaming Accessibility Conference award. This is also where Game Input earns its keep. It folds 66 legacy input models into one unified data stream, so when a player plugs in something you never anticipated (including something they 3D-printed that morning), it can register as native input by default.

Brad's favorite framing came from an accessibility PM he admires: "There's no such thing as a disability until we create one." Every steering wheel, door handle, and cell phone was designed for a certain body type and a certain level of ability. Accessibility isn't a niche. It's just good design. And a game like Mini Shoot Adventures, with options to make health more forgiving, shows how accessibility settings can simply make a game more joyful to sit down with.

A few quick ones to close

We always seem to get the best questions in the last ten minutes, and this week was no exception.

Q: Our community member Manue asked “If I get accepted to ID@Xbox and receive a dev kit, can I only use it with the approved game?”

A: No. Dev kits carry certificates, and you can switch between retail and dev kit mode. In retail mode, you log in with your normal account and play whatever you own. In dev kit mode, you use the account attached to your Partner Center, the one the kit is signed to, and you only see the non-retail games that account can access. Hot tip: don't use your personal account. Create a business-specific one (we now require Azure tenant accounts for building dev kits), because we've seen real headaches when a studio grows and everything was tied to someone's personal login. And if you're ever playing pre-release content on a retail account, turn off your sharing and rich presence so you don't leak it.

Q: I can't get a dev kit yet. Am I stuck?

A: Not at all. For questions about getting hardware, Keith and Jessica Bonell in the ID@XBOX channel can help with the inventory and timing side. But the bigger answer is that your PC is your first dev kit. If your game runs on PC with the GDK, it'll run on console with the GDK. You don't have to wait.

(We also spent a genuinely unreasonable amount of time trying to remember what the "..." symbol is called. For the record, the chat solved it: it's an ellipsis. Thanks, Todd.)

Before you go

Brad closed on the thing that clearly drives him: he loves games. He plays one every morning to validate the service, he's "spoiled" right now with Forza Horizon 6 on the way, and he had real affection for Le Mans Ultimate, a studio that listened to its community, patched based on what players actually wanted, and earned a devoted daily player base as a result. His pitch to all of you, the people making games, is the same one he keeps making internally: walk the player through it, make them feel valued, and if they get lost, help them find the way back.

If it's no longer fun, it's no longer a game. This whole program exists so players have a way through the hard parts, and so you have a way to hear from them.

Thanks to Brad Rossetti for demystifying flighting, and to Clint and Tim Woodcock for keeping it all on the rails.. As always, drop into the XBOX Game Dev Discord and keep an eye on #announcements for who's joining us next. Have a great weekend.