I teach product management at Kellogg. For the last two years, I have watched the product manager become a product builder. The product manager’s role used to end at the specification. She understood the customer, wrote the story, defined the requirements, and handed them to engineers who built the product. Every step after the handoff was translation, and with each translation the artifact drifted a little further from the vision.
AI has removed most of the handoffs. A product manager with domain expertise and the judgment to know what good looks like can now carry a product from story to working build. I know this because I have done it with the Pedagogix SIMS titles.
Let us look at how two of my simulations were built, because the contrast shows how much the PM role has changed. DigiStrat, which I designed seven years ago with Michael Bean, now President of Forio, was built the old way: I supplied the design, and a team translated it into a model. YieldForge, a Pedagogix title, was built with me as the product builder, AI as my engineering partner, and my co-founder Subhendu Modak as the developer. The designer, the craft, and the kind of product were the same in both cases, but the process was very different, and so were the outcomes.
How we built DigiStrat
DigiStrat is a multiplayer strategy simulation of the digital services industry. Teams compete for subscribers across wireless, wired, and cloud services, and in the middle of the game they bid for 5G spectrum in a live auction. It is a bestseller in the Harvard Business Impact catalog, and I am proud of it. Yet I built very little of the game itself.
My part was the story, the context, and the key variables. I wrote the narrative of the industry, sketched the decisions a team would make each period, and listed the variables that had to move: subscribers, churn, network capacity, content spend, and prices. Then I sat down with Michael Bean and his developers to translate the story into specifications. They turned my story into causal loop diagrams, the stock-and-flow maps that system dynamics uses to show how variables interact and change over time. I would look at a diagram and say that the loop from price to churn was too strong, or that a capacity investment should arrive with a lag. They would go away and change the model. We would run it and look at the output, and I would say that a strategy I expected to work had lost, or that one I expected to fail had won, and we would go back to the diagram.
This back-and-forth lasted six months. Each turn required the developers to understand my logic well enough to encode it, and it required me to understand their encoding well enough to see where it diverged from what I meant. Both of us were translating, and neither of us could see the other’s side of the translation directly. The simulation that emerged is good, but it is not quite the concept I had in my head, because few products that pass through that many hands ever are. My role, for all the credit I received, was to supply the vision and then wait while other people did their best to turn it into a product.
How I build a title now
A Pedagogix title goes through the same stages DigiStrat did, but I carry it through every stage except the platform build myself. The story comes first, as it always has: the one-line lesson, the role the player occupies, the tension, and the research the lesson rests on. With YieldForge, I wanted to teach that running a plant at full capacity is very different from managing it for profitable yield. The tagline I started with was “The plant is full. The money is missing. Find it.” I also decided which decisions players would make and how the game would evaluate their performance.
With the story and the high-level specifications in hand, I worked with Claude to write the detailed design document, which filled in the company context, the decisions, the user interface, and the game’s level of complexity. In the same session, with Claude as my engineering partner, I wrote the headless engine, the game logic that runs without a screen, and I did it without writing a line of code. I do not know a simulation modeling language, and I do not write Python. I write the logic in plain English, carefully: what each variable is, what moves it, by how much, with what lag, and under what conditions. Claude turns my English into code. The skill lies in defining that logic so precisely that no ambiguity remains.
When the logic is that precise, I can have a playable game within hours of finishing the story. Testing no longer means playing the game by hand, repeatedly, at an hour or more per play. Instead, I built a test harness: a set of automated players, each following a named strategy, that run the engine across every market thousands of times. I ask AI to evaluate the results, and we iterate, fixing bugs and recalibrating variables, until the game behaves as intended. When the harness shows that a hedged strategy beats a committed one, I do not write a note to a developer; I ask AI to change the parameters and rerun. When the debrief does not show a student what her decisions caused, I ask AI to rewrite the debrief.
What I hand to Subhendu is a complete build package: the engine, the interface, the harness with its verification results, the debrief logic, the student and instructor guides, and the design document that ties every decision to a lesson. He takes that package and turns it into the server-side product: authentication, the class code, cohort analytics, the instructor board, the administrative controls, and the cloud infrastructure on Firebase and Google Cloud. His work is substantial, and it is the work of a platform engineer. It is no longer the work of translating my intent into logic, because I handed him the logic already built and already tested.
Iterating with myself
The speed is the visible gain, and it is real: weeks instead of months. The larger gain is harder to see from outside, and it concerns fidelity. Michelangelo is said to have written that the true work of art is but a shadow of the divine perfection. What reaches the viewer has passed through hands, tools, and time, and each of them dilutes the vision the maker held. Every handoff in a product process does the same thing. When the person who holds the vision also builds the logic, the loss in translation shrinks to almost nothing. In DigiStrat, I could tell that a loop was too strong only by watching a strategy fail and reasoning backward through someone else’s diagram. In YieldForge, I set the value of a contested machine hour myself, watched the in-game AI copilot reprice the first two weeks of play, and adjusted the value until the moment of recognition arrived in week three, where I wanted it. The product that ships is much closer to what I envisioned.
Iterating with myself is also far faster. A handoff costs time while the other party works to understand, and it causes drift when they understand imperfectly. Removing the handoff removes both costs. I can change a parameter, rerun the harness, read the result, and change it again in the time it used to take to schedule a meeting about it. Each loop takes minutes, so I can run it hundreds of times. As a result, I am far more confident that the simulation behaves as intended and that it cleanly separates skill from luck.
I tell my students to eat their own dog food, which means using the products they build. I am doing that twice over. I build simulations with the AI tools I teach product managers to use, and the simulations I build teach the management of AI. The method and the subject are now the same.
What this means for product managers
AI did not make me an engineer, and it did not make building simple. Subhendu still does the platform work, and the platform work determines whether a product runs smoothly for ten thousand students or crashes at scale. AI let me carry my own product across the stages where the artifact used to drift from the vision, and it could do that only because I brought three decades of simulation design and several years of close work with AI models to the table. A product manager without domain judgment who picks up these tools will build a fluent prototype of the wrong thing, faster than ever.
That is the lesson I now teach. The product manager’s job used to be to specify well and communicate well, because other people did the building. Today the product manager’s job is to know what good looks like well enough to build it, test it, and hand over something that works. The skills that matter have shifted toward judgment about the customer and the domain, and away from the craft of writing requirements for someone else to interpret. Requirements documents were a workaround for the fact that the person who understood the customer could not build the product. When AI removes that constraint, the workaround goes with it.
Requirements documents were a workaround for the fact that the person who understood the customer could not build the product.
I ask my students to pick a product they understand deeply and work with AI to build a working artifact, even a crude one. Instead of handing a requirements document to engineering, you can hand a working prototype to a platform engineer to deploy. With AI as your partner, the hard part of a product manager’s job is no longer how to build the product. It is deciding what product to build.
Mohanbir Sawhney is Co-founder & Chairman, Pedagogix.