Yonatan Shaham
Product management principles in practice: indie game development
Two days ago, I worked on my new game idea for 60 minutes. In those 60 minutes, I put some key product management, lean, and agile principles into work.
Push for early validation of assumptions
Product managers should push to validate assumptions as soon as possible and focus on the risky ones. Validating assumptions quickly is the thing that allows us to make informed decisions on whether we should pivot or persevere.
In the case of games, the riskiest assumption is always the same: "This game is fun to play." Fun is the core 'business value' of games. Even though fun is very hard to theorize, it is very easy to notice when people are having fun. So as a product manager or indie game developer, the first thing you want to aim at is having the game equivalent of a minimal viable product, a Minimal Playable Game (a term I just made up). Basically, it means you want to express the game mechanics and loops and let some people toy with it.
I started to work on the inner game loop:
- Wait for new traders to come
- Trade with those who can accept your prices
- Adjust prices
- With time, consume food
- Replenish food stocks
Within these 60 minutes, I managed to develop the very basic code of (4) with time, consume food, (5) replenish food stocks and pay for food. Next, I will move to the other items. My plan is to reuse most of the code of the Taxi game.
Deliver a working software
When developing, I plugged in stubs and placeholders to all features and UI components as much as possible. I did not stall on any detail and pushed to close the loop as fast as possible, delaying many decisions for later. Some examples:
- All UI elements are plain texts at the top bar (see image).
- I used MS paint to create a background that reflects the general layout of the scene. I might replace that later with better graphics.
- I did not care about the numeric value of parameters such as food consumption rate and food price. I just verified that they are in values which makes it easy to see their impact in play, for example, food reduces every 2 minutes so I can easily notice it changes only on even minutes, and food price is 0.5, so money changes are noticeable. I will find the right values when I move into the balancing phase.
- Since I did not decide on UI, I mapped the keyboard to the only player action that I have now and set it to work only in the editor. I created a special method in the code for that and named it
PlayTestingInEditor(), so I’m clear this code is not relevant for the real game. This code allows me to test the functionality as a working software immediately, without dependency in any UI or input decisions I will make later.
Get feedback early
This way, I move very quickly toward working game mechanics that can be tested and that users can give feedback on. Getting user feedback as early as possible is a key principle in product management. It is the best way to accelerate the build-measure-learn loop.
The first user is you. Try the play the very basic loops and see if you like it. Don’t invest too much in any local aspect like art, sound, animation, or a variety of content. Then, test with empathic users like your friends, for whom you can bridge the gap of the features you did not yet develop through oral explanations. It is true that you don’t need more than 5 users for every user testing round.
After 60 minutes of work, I have probably completed one-third of the work needed to test the inner game loop. Meaning I can get user feedback just by working 2 more hours (just need to find the time for that…)
Why do things this way? Can’t I just work another 60 minutes?
When developing a new product, games included, the scarcest resource is time, calendar time. You are facing extreme uncertainty about your users and your market. Each bit of other resources like developers’ time or money you spend on the wrong users, the wrong market, or the wrong feature, cannot be recovered. Get to a point you can validate or disqualify your hypotheses and assumptions as soon as possible. The best way to do it is to always push for working software, focus on end-to-end user paths and core feature functionality, and go out there to meet users. For sixty minutes or for 60 days, the same principles should apply.
Share if you think it's good
Don't miss a thing
We promise to only send you the good stuff. No spam.