Barriers to Adopting Simulations, and Getting to Zero Friction

Most business school faculty acknowledge that simulations are an effective learning tool, yet most of them do not use simulations in their teaching. I write simulations, and I use simulations that others have written, so I know the barriers to adoption from both sides. Friction arises at every step: choosing a simulation, running it, and grading it. That friction can be eliminated, and our mission at Pedagogix is to get adoption friction to zero.

One of the largest surveys of business faculty on this subject went to 14,497 professors at AACSB schools in 2004. Of the 1,085 who answered, fewer than a third used a simulation, one in six had used one and stopped, and more than half had never used one. Preparation time was the reason they gave most often, poor fit with the course came a close second, and lack of information about available simulations came third. Only a quarter of the never-users said they were even somewhat familiar with simulation games.¹ Later researchers grouped these reasons into three barriers: the risk of trying a new method in front of students, the suitability of the simulations on offer, and the instructor time required to run one.² A survey that ranked 32 possible barriers placed lack of time to plan, inability to try before buying, inability to customize, and inability to track student progress near the top.³ Ernest Cadotte, who has designed simulations for forty years, wrote that instructors fear looking bad in front of a class, and that in a research-first environment the less labor-intensive teaching option wins.⁴

That survey is more than two decades old, but recent research tells the same story. A 2022 review found that risk, suitability, and resources still explain most non-use.⁵ A Delphi study of instructors found that the biggest obstacles were uncertainty about whether a game suits a particular course, a lack of infrastructure or budget, and uncertainty about the learning outcomes a given game produces.⁶ A multinational survey of 180 educators, published in January 2025, found that perceived usefulness and the norms of academic peers drive adoption.⁷ The findings have not changed because the products have not changed. Everest and Markstrat, two of the most widely used simulations in management education, are decades old. Publishers have bolted on newer user interfaces and AI chatbots, but the underlying engines remain clunky.

I teach product management, and that discipline shapes how I think about this problem. Product-led growth (PLG) rests on one idea: remove every step between the user and the value of the product, and the product will sell itself. Traditional simulations work the opposite way. They resemble heavyweight enterprise software such as SAP and Oracle, and adopting one is an implementation project, with a manual, a training session, a facilitator, a license negotiation, and a course rebuilt around the software. My own DigiStrat, which Harvard Business Impact distributes, demands this level of effort: four competing teams, twelve hours of play across a term, and a live spectrum auction. It works, but many capable colleagues I know have decided they cannot make that investment.

At Pedagogix we set out to build simulations the way modern zero-touch SaaS products are built, and to apply the zero-friction principles of product-led growth to the whole adoption path. This post explains where instructors encounter friction and how we removed each source of it.

Sources of adoption friction

Adopting a simulation runs through six stages: consider, place, commit, learn, run, and close. I mapped every point at which faculty stop. Exhibit 1 shows the map.

The accounting distinction between capital expenditure (Capex) and operating expenditure (Opex) offers a useful analogy for friction across the lifecycle. Before adoption, the instructor makes a one-time investment of design time, usually in the month before the term, to decide whether a title fits, where to place it, what to remove, and how to change the grading. That investment is the Capex of adoption. After adoption, the instructor must learn the game, administer it, get students started, make sense of the results, and build the debrief, and must repeat all of this every term the simulation runs. That recurring effort is the Opex of adoption. Publishers compete on the price of simulations, but a lower price reduces neither the Capex nor the Opex of effort. Instructors get stuck in two ways. Some do not want to incur the Capex of adopting a new simulation. Others have already adopted one, and the Capex of switching to a new simulation daunts them even when the Opex of the legacy simulation is high.

Everest and Markstrat: two ways of being stuck

Everest, the leadership and teamwork simulation by Michael Roberto and Amy Edmondson, is among the best-selling simulations in management education. Five climbers with private information and conflicting goals decide, day by day, whether to push for the next camp, and three hidden challenges test whether the team shares what it knows. I chose it as an example because the friction I describe has nothing to do with quality. The packaging causes it.

Consider a colleague who teaches organizational behavior and hears about Everest. The listing says leadership and teamwork, and her course has three weeks on teams. Nothing tells her which week to use, what she would drop, or whether Everest duplicates the team exercise she has run for years. To say yes, she must rewrite the session schedule, the assignment list, and the grading table in the month when she has no time to spare. Most adoption efforts end here, with the words “next year.” If she pushes on, she must buy before she has seen the game in her own classroom, at 165 dollars per participant through a coursepack or a license. The surveyed faculty had this moment in mind when they ranked the inability to try before purchasing near the top of their list.³ After adoption, the publisher’s own timing calls for three to four hours of synchronous play in teams of exactly five: thirty minutes of introduction, sixty to ninety minutes of play, and forty-five to sixty minutes of debrief.⁸ She must learn the five roles and the hidden challenges well enough to facilitate, form the teams, find the time block, run the session live, and turn a completion percentage into a debrief. The publisher ships good materials for each of these steps, but she must still perform every one of them, every term. This is what Opex looks like in a classroom.

Markstrat illustrates the other way of being stuck. It runs six to ten decision rounds across a term, with hours of team work per round and an instructor who must administer each round. It teaches segmentation, positioning, and R&D allocation well, and the faculty who run it are loyal for good reason. A course that has run Markstrat for ten years, though, no longer just uses a simulation; it is built around one. The session sequence follows the rounds, the teams follow the game, the grading carries the ranking, the slides reference the market reports, and the instructor’s intuition about what students will do in week seven is Markstrat intuition. To switch, the instructor must redesign the entire course. The switching cost is prohibitive, so nobody switches, and the tail wags the dog: the course now serves the simulation. A Kellogg colleague told me privately that she had run the same simulation for years, that she knew newer ones would serve her students better, and that she could not see how she would ever switch.

So faculty are in one of two states. Some do not use a simulation because the Capex of adoption is too high. Others keep an obsolete one because the Capex of switching is higher still. The first is a greenfield adoption problem, and the second is a brownfield substitution problem. One cause produces both, and we address each one differently.

The friction has nothing to do with quality. The packaging causes it.

Removing friction at each stage

We treated the lifecycle as a product specification and built an instrument for each part of it.

Before adoption: the Curriculum Concierge. The Concierge solves the problem of finding, choosing, and integrating a simulation into your course. You upload your syllabus and session schedule, or an executive education program matrix, at pedagogix.ai/concierge. The Concierge, an AI agent, scores every title in our catalog against your course on five criteria: discipline match, how many of the title’s lessons your stated objectives cover, audience, format, and whether the course has a session where the title belongs. The score multiplies relevance by feasibility, so a title that is easy to run but off-topic scores near zero, and you see the arithmetic. If no title fits the course well enough, the report says so, and you receive no revised syllabus. If a title fits, you receive your own syllabus file with the simulation built in. The plan names the session by number and date, names the case or lecture that makes room for the simulation, and rebalances the grading. Every change appears as a tracked change that you can accept or reject in the review pane, and nothing else in the document changes. With AI, the Capex of adopting a simulation falls to almost zero.

The Markstrat problem, brownfield substitution, needs a different treatment. The Concierge detects the legacy simulation in the syllabus, compares it lesson by lesson with the best-fitting title, and recommends a switch only when the new title covers the old one’s core lessons and either adds lessons or frees sessions. When the plan recommends the switch, the new title takes the old one’s slots and grade weight, so the course keeps its structure, and you get back the sessions that the multi-round simulation held, each with a proposed use. When the two titles teach different lessons, the plan treats them as complements and leaves the old one in place. Software now absorbs the switching cost that kept my colleague stuck.

At commitment: the site. You get twelve free plays of any title. A course section takes two minutes to create and produces the class code. Students pay per seat when the course runs, the way they buy a case. There is no license, no purchase order, and nothing to install. This is the product-led motion: try, adopt, then pay per use.

After adoption: how we built the simulations. This is the Opex, and here the design work matters most. Students play in one sitting before class, 25 to 75 minutes depending on the title, in a browser with a class code. We put the briefing, the practice round, and the advisers inside the game, so students read nothing beforehand and you explain nothing. Your administration is a single act: posting the class code on Canvas. A shared market code puts every student in the same market so that results are comparable, result codes verify who played, games save and resume, and you run nothing between play and debrief. Grading is just as simple. Every title produces a personal result for each student on the instructor board, so you verify completion without collecting a submission. The written deliverable is a short memo based on the student’s own board review, which you grade on reasoning rather than on score. Performance counts for a small share of the grade, because the market a student draws is partly luck. When play ends, you open the cohort analysis: the distribution of results and the two or three decisions that separated the strong runs from the weak ones. Each student receives feedback written from the game they played, and you receive a debrief deck built from the title’s lessons. You walk into class with the scores computed and the debrief deck in hand.

Compare this with the two canonical simulations. Everest requires a three-hour synchronous block in teams of five. EYEWALL, our crisis leadership title, also seats a team with private information, a cabinet of six, but the team plays before class, in an hour, on its own devices, and the class session is the debrief. Everest reports a completion percentage. EYEWALL scores teamwork from what the cabinet did: how much private information reached the table, who voted without speaking, and whether the mayor explained an override. Each student then receives an after-action review from the game they played. Markstrat requires a marketing course to give it eight rounds and a term. MarketMoves seats the student in the chief executive’s chair of a retailer facing a digital challenger for eight quarters, in one sitting, and the board review at the end names the strategy the student’s decisions built. The lessons are similar, but the instructor hours differ by an order of magnitude.

The goal of zero friction

Zero friction is a destination, like zero defects, and progress toward it can be measured. For the instructor, design work shrinks to reading and approving a plan, administration to posting a code, and debrief preparation to opening the cohort view. For the student, it is one sitting, nothing to install, and feedback that belongs to them. We hold ourselves to four numbers: days from first contact to a scheduled course section, under seven; instructor hours from adoption to debrief, under three; the share of students who finish the assessed run before class, above 95 percent; and second-term retention, above 80 percent.

Faculty already believe in simulations. What they lack is time, information about fit, and a way to try without committing, and those who do commit incur a switching cost that holds them captive to outdated simulations. Product management taught me that these are design problems, and design problems yield to design. Send us your syllabus and see for yourself.

Notes

1. Faria, A. J., and Wellington, W. J. (2004). A survey of simulation game users, former-users, and never-users. Simulation & Gaming, 35(2), 178-207.
2. Lean, J., Moizer, J., Towler, M., and Abbey, C. (2006). Simulations and games: Use and barriers in higher education. Active Learning in Higher Education, 7(3), 227-242.
3. Justice, L. J., and Ritzhaupt, A. D. (2015). Identifying the barriers to games and simulations in education: Creating a valid and reliable survey instrument. Journal of Educational Technology Systems, 44(1), 86-125.
4. Cadotte, E. (2016), as quoted in Rogmans, J., Teaching with business simulation games: Identifying and overcoming hurdles to adoption, Proceedings of the European Conference on Games Based Learning.
5. Faisal, N., Chadhar, M., Goriss-Hunter, A., and Stranieri, A. (2022). Business simulation games in higher education: A systematic review of empirical research. Human Behavior and Emerging Technologies, 2022, article 1578791.
6. Calabor, M. S., Mora, A., and Moya, S. (2019). The future of ‘serious games’ in accounting education: A Delphi study. Journal of Accounting Education, 46, 43-52, as summarized in note 5.
7. Pejić Bach, M., Meško, M., Stjepić, A. M., Khawaja, S., and Quershi, F. H. (2025). Understanding determinants of management simulation games adoption in higher educational institutions using an integrated technology acceptance model/technology-organisation-environment model: Educator perspective. Information, 16(1), article 45.
8. Harvard Business Publishing, Leadership and Team Simulation: Everest V3, product listing on Forio (accessed September 2026): teams of five, played synchronously; total time three to four hours; 165 dollars per person.