AI Prototypes Should Learn from Game Development
Or how games teach us how to make better products
Over the last few years, I’ve led the exploration and development of new data products. Some were machine learning features for a startup, others were generative AI tools for the US government. A few were just silly home automation tools I built for fun.
As I’ve gotten better at identifying promising product ideas and validating them with my team, I’ve found myself thinking more and more about game development. Not because I was building games (although I am now), but because game developers intuitively understand three things that some product teams may miss:
You need to prototype early
You need to test if it’s fun (or in our case, at least useful)
You need a design document to serve as a source of shared vision to keep the team aligned on goals and scope
When we apply these (seemingly obvious) principles to our product work, I’ve found we’re much more likely to land on something that makes users, developers, and stakeholders happy.
Prototypes Should be Built for Testing, Not Production
When building AI-powered products (especially generative AI or those which have stochastic output) users don’t experience a fixed, known output every time. Because of this variability, testing with real users is essential. It’s even more essential to do this user testing before the product is fully baked.
This can feel at odds with how many teams think about software development - particularly in enterprise environments, where users can’t touch a product unless it’s deployed with logins, databases, and compliance checkboxes. If your team (as mine once did) defines an MVP as something that must be production-grade, in my opinion you’re already far beyond “minimum.” For AI prototyping, what you really need is a Minimum Testable Product.
Build something extremely simple. A “static UI with a prompt box and a call to a language model” simple. No account login. No data persistence. No styling. Just something you can put in front of users and see how they react to what the AI does and whether it’s useful. This includes prototyping features that might be later integrated into an existing application. Build the prototype first to test the AI, then decide if you’re going to put it in the production app.
This kind of quick, scrappy prototyping won’t fly in every environment. Regulatory and security constraints may limit what you can test and when. But even then, you can carve out internal sandbox environments or test flows that simulate usage without full production compliance. The goal is to move the learning earlier, not to bypass governance entirely.
This was a big mental shift for my team at OPM. I came from a startup background; they came from an enterprise one. But once we aligned on expectations, we reframed success early on as “get something testable in front of users” rather than “deploy it to production”. That meant stripping away any nonessential functionality. And it worked. We were able to iterate fast, run deep feedback sessions with subject-matter experts, and hear from over 50 active users in regular retrospectives. We also held 1:1 interviews with power users who shaped where we went next.
If we waited to have the “real” product in place, we wouldn’t have been able to test our ideas and we would be waiting to get on the app team’s roadmap. When your product depends on AI output, that output needs to meet the bar for usefulness and value — the rest of the product doesn’t matter.
This approach has really stuck with me. We didn’t need a lot of polish, we needed signal. It reminded me of something game developers do (seemingly) instinctively: build the bare minimum to test if the core mechanic is fun. They might have placeholder art, “under construction” areas, or grayed out buttons while a game is in early development. But the goal is to test feel, get feedback, see if it’s fun, and pivot if necessary.
Like games, AI products can’t be fully predicted. You don’t know exactly how a language model will respond or even what the main use cases might be until people start poking at it. You don’t really know if a product is “fun” (useful) until you have them play.
Of course, not every product needs to be “fun.” A compliance tool for internal audits doesn’t need to be delightful, it just needs to be correct and fast. But when you're working with AI, especially generative or probabilistic models, you're often building something users will explore, push, and prod similar to how they would in a game. And that means the “feel” of it matters. The unpredictability of AI output makes early testing not just nice-to-have, but essential. You won’t catch real failure modes through static wireframes or spec reviews, you need to see how people actually poke at the thing.
Build a Living Design Document
The second lesson I’ve taken from game development is the power of a good Game Design Document (GDD). These documents help teams align around the vision: what’s the core mechanic, the art style, what tools do we need, and (ideally) what’s the timeline for finishing? It might seem like overkill when you’re building a prototype, but I’ve found that having the core decisions clarified in a document can help facilitate and even speed up discussions on any decisions, tradeoffs, pivots and team alignment.
In AI/ML product development, I’ve found the equivalent Product Spec to be an essential artifact. When you’re building something creative and uncertain you need a place to answer questions like:
What is the core issue we’re trying to solve?
What is the smallest thing we can build to test it?
How will we know it’s working? (what data do we need?)
But here’s the twist: it doesn’t need to be a doc. Our team had great success using a canvas-style board like Miro. It gave us a flexible space to:
Drop in UI mock ups
Record user feedback
Include data analysis and preliminary results
Organize sprint goals and address open questions
Now, I hear you: “We’re not building a game, we’re building a serious tool.” Fair. But game developers build in uncertainty too. They rarely know upfront what players will enjoy or exploit. That’s why they might use living design documents to evolve with the team’s understanding. I’ve found the same approach powerful for AI products: you need a place to track ideas, shifts, surprises, and learning.
A traditional Product Requirements Doc might be too rigid for this kind of exploratory work. But a flexible, shared canvas gives you a place to ask: what’s the real problem? what’s the smallest test? what feedback have we gotten so far? If you're building in the unknown, you need a way to track your learning, not just your delivery plan.
This kind of design document is clearly not very rigid. But that’s by design (ha). It allows us to evolve our thinking as we learned more and keep track of everything we’ve compiled so far. It can get messy if you’re not careful to keep it organized or you have a very large team, but for a team working on a prototype you want to keep your team small anyway.
To complement our master design board, we maintained a short presentation deck that we would use to keep stakeholders up-to-date on scope, progress, and any key findings along the way. These two tools, a living canvas and our summary slides, help keep everyone aligned and focused even while prototyping and evaluating quickly.
Why go to this effort? Because in fast-moving, high-uncertainty work like AI and games the biggest risk isn’t slow delivery. It’s building something no one wants, or no one understands. By committing to clarity (even messy, iterative clarity), we gave ourselves the best shot at alignment without overcommitting to any one path too early.
You could argue that an infinite whiteboard and evolving slide deck aren’t a “real” design document. You’d probably be right. But by clarifying and committing to our intentions they aligned the team, captured our learnings, and made the work feel tangible and evolving long before it hit production. As always, find what works best for your team!
Bringing game dev to your products
The overlap between game development and AI product development isn't immediately obvious, but it's surprisingly applicable. Both domains involve building experiences with unpredictable elements, where user interaction and feedback are essential to success.
My teams have built better AI products because of these kinds of adaptations, so I hope these anecdotes will resonate with you. Next time you're tasked with building an AI feature or product, consider if you have:
Made a Minimum Testable Product that focuses solely on validating the AI's usefulness
Created a space for real users to interact with your prototype before investing in production infrastructure
Aligned your team around a flexible, living representation of your teams goals
Have you found any game dev practices that are useful in your product work? Or are there any other domains I should consider?