How to make a game that's a decent simulation of a real job
How to make a game that's a decent simulation of a real job
Balancing the fun factor with the "ouch, it really do be like that" factor
The Product Management Cardgame can't all tongue in cheek. Sure, I'll throw in some puns and sarcasm that hit too close to home, but it still needs to reflect what's a typical day in the life of Product Manager.
For the first iteration of the game, before having any feedback, this is what I did:
Made a list of real-life situations that I had faced while PMing (e.g. messy Reorganization efforts that slow everyone down, losing a team member, suddenly getting positive attention from the executive level, etc)
Grouped said situations (e.g. being sidetracked by firefighting is in the same family of thing as losing a member of your dev team)
Tried to see how they would fit with the Mechanics, Dynamics, Aesthetics framework. (I'll write a post on this later on)
Starting from a list of real-life situations allowed me to begin with something that would immediately connect with potential players. During testing sessions, people had a few laughs going through the game and seeing it reflect some of the chaos that surrounds PM life.
However, my initial list could not contain every possible situation that a PM faces on the job. During testing, a common question is "what about situation X, it happens all the time, will it be in the game?".
The initial effort of coming up with a structure that I could fine tune paid its dividends here.
The game has a simple objective: players score points with each successful launch. To make the game easier or harder, all I need to do is to include events that slow down or accelerate the launching of products. This is a lever I can fine-tune.
When people suggest something they have faced as PMs, I can check if it could be represented within the structure of the game. Sometimes it can, sometimes it can't.
When a suggestion cannot be included in the existing rules of the game, there's a decision to be made:
A) Do I change the next iteration to include it
B) Do I go without it
C) Do I create a watered-down version of said suggestion and include it in the current ruleset?
How to tune the game
We don't think much of it while playing, but there are a few things that affect how the game is played. A few examples:
Types of possible projects a player can launch
Are they expensive or cheap to launch? Are they quick or slow to complete? Do they belong to a specific family of projects?Distribution of resources
the resources in the game are people (talent) and projects to work on (deliveries). If there are a lot of low-level talent resources, it takes longer to build up a team to work on a delivery. If there are a few high-value/low-risk projects to work on, we teach the players that not all cards are the same and some are particularly valuable.Number of cards a player can pick at the start of a new turn
in initial playtests, players could get one talent card per turn, this made the game too slow, as you would need to go through several turns before assembling a team that can work on a delivery.Number of resource cards a player can hold on her hand
When there's a limit of cards you can hold AND some cards are better than others (e.g. Jr and Sr SWEs) you now have space to develop mastery of the game: you can learn how to better prioritize which cards you keep and which ones you discard.
Simulating Product Management reality in a game is about balancing the fun aspects and the professional side of PMing. The very word “balancing” points towards a dynamic effort to adjust different levers. This is why so much of the game is defined by points, numbers, weights: these are easily adjustable variables that I can move to reach a captivating equilibrium.
If you don't yet follow me here on Substack and you enjoy reading up on the realities of creating a cardgame around the Product Management profession, I have a suggestion: