Header photo originally by Yan Krukau with some edits
This article is thinking out loud, something that has been on my mind for the past few years. A little over three years ago I entered the video game industry and began, like many, by carrying over what I knew about startups to a game studio. Some things fit; others, not so much.
Over time I started asking myself an uncomfortable question: how do you think about the business of a video game? People who make games, especially on their own (solo devs) or in small teams, have their eyes on the product, and rightly so. When it’s time to think about the business, they look for a tool that organizes their ideas without requiring them to be management experts. But what makes a tool good for that? For me: that it looks at the product, that it guides the developer, that it helps handle uncertainty, and that it can be used to explain the project to others.
This is the first of four parts in which I’ll test different tools against that yardstick: the Business Model Canvas, the Lean Canvas, the Game Development Canvas and, finally, a proposal of my own based on product surface and marketing management.
I’m starting with the best known. My thesis for this part has two halves: the BMC is an excellent starting point for someone coming from development, but on its own it is not the most suitable tool for a video game, because it describes the business surrounding the product and not the value of the product itself. To test it, I filled it in with my own studio.
Business Model Canvas (BMC): the best-known map
The Business Model Canvas (BMC), developed by Alexander Osterwalder, popularized a way of describing on a single page how an organization creates, delivers and captures value, through nine interconnected blocks. Strategyzer groups them into three questions:
- Desirability: does anyone want it? Value proposition, customer segments, channels and customer relationships.
- Feasibility: can we do it? Key resources, key activities and key partners.
- Economic viability: does it sustain itself over time? Cost structure and revenue streams.
Its strength is not telling us whether a business is good, but forcing us to put our hypotheses on the table. That’s why it is so popular among people who are just starting out.
What the BMC would look like for Tangara Studio
To test it, I filled in the canvas with my own studio, block by block and in good faith, as any founder would, and kept adjusting it until the blocks read coherently. This is the result:
Filling it in was worthwhile: it forced me to name my customers, my channels, my funding sources and my costs, things that developers tend to leave for later. But along the way, four tensions appeared:
- One value proposition, three different promises. To the player I offer an experience; to the publisher, a project with contained risk; to the B2B client, a service. A single box mixes them, which is why mine ended up generalist (see the note in the canvas).
- Actors wearing several hats. The publisher is a segment, a partner and a funding source all at once. The State is a partner and a source of income, but not a “customer”. Whoever pays is not always whoever plays.
- Studio or title? This canvas describes Tangara Studio, but the economics play out per title: each release is a different bet.
- The main asset has no place of its own. Intellectual property (IP) ended up as just one more line under “Key resources”, next to “knowledge of engines”.
Putting the BMC to the test
By the yardstick I proposed at the start, this is how the BMC fared:
| Criterion | Verdict | Why |
|---|---|---|
| Looks at the product | ❌ Little | The game is reduced to a single box |
| Guides the developer | ✅ Good | It forces you to think about customers, channels and costs |
| Handles uncertainty | ⚠️ Partially | It helps formulate hypotheses, but doesn’t provide a way to validate them |
| Communicates to the outside | ✅ Good, with a caveat | It’s a common language, but you read the business, not the game |
Looks at the product. An important nuance: the BMC doesn’t speak of “pain”. That language comes from the Lean Canvas and the Value Proposition Canvas. The BMC asks what value we deliver and to whom, but when filling it in we tend to translate need into problem, and that’s where games resist: nobody buys a game to get a task done, but to live something. Narrative, aesthetics, challenge, community or simple escapism are experiential needs, and “entertainment” flattens them all into one word.
Guides the developer. This is its greatest virtue. On a single page, someone coming from the product side sees the whole business without needing management training.
Handles uncertainty. The BMC can be read as a set of hypotheses, but it has no blocks to formulate or measure them. A game in development is pure uncertainty, and the canvas describes it as if it were a stable model.
Communicates to the outside. Publishers, funds and evaluators know this language, and I believe many put together a mental BMC when reading a project (that’s a hypothesis of mine, not a fact). It helps, but with a risk: they read the business and don’t find the game.
Conclusion
Going back to the thesis: the BMC is a good starting point. It forces the developer to look up from the product and answer who will play it, how it will reach them, who funds it and how much it costs. But it falls short precisely where a game is most valuable: the experience, the world and the mechanics are reduced to a single box, and intellectual property ends up as just one more line among the resources.
By the yardstick I proposed at the start, the BMC organizes the developer’s thinking well and communicates well to the outside, but it looks little at the product and assumes a more stable model than a game in development usually is. The risk is subtle: with the canvas filled in, it’s easy to feel that “I’ve thought through the business” without having put into words what the game offers and why it matters.
And there is a question the exercise left open: this canvas describes a studio, but a game is a product with its own uncertainty. In the next part I’ll try the Lean Canvas, which starts from a different place: not from how the company works, but from what the problem is and which hypotheses need to be validated. The question is whether, in a video game, that “problem” exists or needs to be reframed.