The post-game is where you actually get better

A Magic: The Gathering Arena match in progress

I play Magic: The Gathering most nights, usually once the chores, the shopping, the school run, whatever the day demanded, is finally done. By that time my family are relaxing and doing their own thing. I’m three games deep into Standard Bo3, mildly furious about a mana screw, and completely at peace with how I’ve spent my evening.

For a long time I thought of it as just a hobby, the same drawer as running or vinyl or whatever else people do to switch their brains off. Except mine keeps running, just on a different track.

Somewhere around my hundredth loss to a deck that outplayed me rather than out-lucked me, I noticed I was thinking about my day job. Not literally. Nobody’s shipping a feature by attacking with a 4/4. But the decisions felt familiar. The more I played, the more I noticed the parallels with the decisions I make as a design leader: how to work with limited resources, when to act and when to wait, how to respond when something doesn’t work, and how to get better without throwing away everything that came before.

The decisions that separate a good Magic player from a mediocre one are surprisingly close to the decisions that separate a good design leader from one who’s just busy.

I’m not the first person to find something useful in it. Game Developer has written about what Magic can teach designers, MIT Technology Review has covered the game’s computational complexity, and Wizards of the Coast has spent decades documenting the strategy behind it. So the mechanics below are the real ones. The interpretation is mine.

Here’s what designing products for a living and several thousand hours of casting spells have in common.

Mana is a resourcing problem with better art

If you’ve never played, the basic idea is fairly simple. You play land cards, lands produce mana, and mana is what you spend to cast everything else. A card might cost 2RR: two mana of any kind plus two specifically red mana. Until you have the right lands in the right colours, that card sits in your hand doing nothing.

The challenge is that you don’t get an unlimited supply. You normally play one land per turn, so the mana available to you grows gradually throughout the game. Your deck therefore needs a sensible mix of cheap and expensive cards, along with enough of the right kinds of land to make them playable.

Get too few lands and you’re mana screwed: you have plans, but not enough fuel to execute them. Get too many and you’re mana flooded: plenty of resources, not enough useful things to spend them on. Neither problem necessarily means the strategy itself is bad. You can simply have the right plan at the wrong time.

Wizards’ guide to the basics of mana goes deeper into how lands, mana and the cards you want to play relate to each other. Once you understand it, the connection to product work is hard to unsee.

I’ve sat in plenty of planning conversations where the idea is sound but the team simply doesn’t have the capacity to execute it properly. The person with the critical expertise is already committed elsewhere. The project needs a capability the team doesn’t currently have. Or there are so many competing priorities that the attention required to do the work well never really arrives.

That’s mana screw.

I’ve seen the opposite too. A team can have plenty of capacity, but if everything is considered important, that capacity doesn’t translate into much progress. People have time, but no clear place to spend it.

That’s mana flood.

The temptation in both situations is to treat the problem as one of motivation or execution. Maybe the team needs to move faster. Maybe we need to push harder. Maybe we just need to be more ambitious. Sometimes the more useful question is much simpler: do we actually have the resources to do what we’re asking this team to do?

Good Magic players build their deck so that, whatever turn they’re on, they have something useful to do with the mana they’ve got. Good leaders do something similar with a team’s capacity. They think about the skills, attention and time available, then make choices about what can realistically happen with them. A surprising number of strategic failures are really failures of curve, not ideas.

The lesson I keep relearning is about changing the plan when the resources don’t support it, rather than simply resourcing teams better. If the work can’t be done with the capacity you’ve actually got, asking the team to somehow produce more is wishful thinking with a deadline attached. The better decision is usually to reduce the scope, change the sequence, or stop doing something else.

Knowing when to mulligan

Every game starts with a decision most Magic players have to learn to make well: do you keep your opening hand, or do you mulligan and start again with one fewer card?

Reid Duke’s guide to mulligans explains that there are useful guidelines, but no universal answer. One of the simpler rules of thumb is the “Two to Five Lands Strategy”: a starting hand with roughly two to five lands is generally playable, while hands with none, one, six or seven lands are usually candidates for a mulligan.

The interesting part is knowing when to break it. You can have seven individually good cards and still hold a bad hand, because they don’t give you a coherent way to play the first few turns. And a hand that looks slightly awkward on paper can be exactly what you need against a particular opponent.

A genuinely bad opening hand: five lands and nothing to do with them

That feels familiar in product work. Teams often have plenty of good things in front of them: research, ideas, opportunities, customer requests, strategic initiatives. Recognising that they’re good is the easy part. The difficult part is deciding whether they form a hand you can actually play.

I’ve become increasingly wary of confusing a collection of good ideas with a good strategy. A strategy has to tell you what you’re going to do, but just as importantly, what you’re not going to do. It needs to give the team a sensible sequence of decisions rather than simply giving everyone more cards to hold.

A collection of good ideas is not a strategy. A strategy tells you what you’re going to do and, just as importantly, what you’re leaving in your hand.

The same tension continues throughout a game. You might have an opportunity to remove an opponent’s creature, but doing so means spending the mana you could have used to develop your own board. You might have a counterspell in hand and need to decide whether to use it now or wait for something more dangerous. The right answer depends on what you know, what you expect, and what you might learn by waiting.

A few weeks ago I was playing against an opponent who had built a genuinely horrifying board around Doubling Season and a proliferate engine. Their creatures were climbing into triple digits of power and counters were accumulating so quickly that the numbers had stopped looking real.

Every instinct said to panic. Start trading resources. Try to slow the game down. Do something before the board became impossible to recover from.

Instead, I waited.

I took the hit and held everything back for one more turn than felt comfortable. On the following turn, I had exactly enough pieces in place to close the game in a single sequenced attack. From the outside it probably looked like a miracle. In reality, the important decision had happened one turn earlier, when I decided not to act.

Board state showing the opponent's proliferate engine at -114 life, with Anim Pakal at 33/34 having closed out the game

I see the same tension in product discovery, including in myself.

There’s an understandable bias toward action. Shipping something feels productive. It creates movement, gives the team something tangible to work with, and is far more satisfying than saying we’re still trying to understand the problem. But there’s an opposite failure too. “We need to learn more” can become a comfortable place to hide when making a decision feels risky.

I’ve become more conscious of asking what we’re actually waiting to learn. If another round of research is likely to change the decision, waiting is the right choice. If we already have enough information and we’re simply uncomfortable committing, more discovery probably isn’t going to help.

For me, that’s one of the more useful lessons from Magic. Good decision-making has less to do with speed or caution than with weighing three things: the information you have, the information you could still gain, and what it costs you to wait for it.

Sometimes the best move is to play the card.

Sometimes the best move is to leave it in your hand.

Sideboarding is iteration

Here’s a part of Magic that most non-players have never heard of, and it’s probably the mechanic that maps most neatly to product iteration.

In a typical Constructed match, you have a sixty-card deck plus a fifteen-card sideboard. Between games, you can swap cards between your deck and sideboard to adapt to the opponent you’re facing. Lose game one to an aggressive deck? You might bring in cards that are better at dealing with lots of small creatures. Facing a control deck? You might want cards that help you fight a slower, more reactive strategy. Wizards’ guide to sideboarding describes it as a way to adapt your deck to the matchup in front of you.

The swapping itself is easy. The difficult part is working out what actually went wrong.

Did you lose because your deck is bad? Was the matchup difficult? Did you draw poorly? Did you make a sequencing mistake? Did your opponent understand your strategy better than you understood theirs?

The diagnosis matters because the wrong diagnosis leads to the wrong change. You can take out cards that were actually doing their job, overreact to a single unlucky draw, or completely rebuild a strategy that only needed a small adjustment.

I’ve made the equivalent mistake in product teams. Something doesn’t work, so the instinct is to change everything around it. A test exposes a problem, and suddenly the proposition changes, the experience changes and the process changes, all at once. It feels responsive, but it makes learning harder, because you no longer know which change produced the outcome.

Good sideboarding is more disciplined. You look at the evidence from game one and decide what needs to change for game two while preserving the parts of the strategy that are still working.

That’s how I increasingly think about iteration in design. A user test doesn’t necessarily mean the product is wrong. Stakeholder pushback doesn’t necessarily mean the strategy is wrong. A launch that underperforms doesn’t necessarily mean the whole proposition is wrong. The useful question is what the evidence actually changed.

If everything changes after a setback, we’ve learned very little about what caused it.

I’ve become wary of retrospectives that produce six new actions. A better retrospective identifies the important decision, looks at what was known at the time, and makes one deliberate change based on what has been learned.

There’s another Magic concept that fits here too: goldfishing. Before taking a deck into a real game, players can play through hypothetical hands and turns against an imaginary opponent that doesn’t interact with them. It lets you understand how the deck behaves on its own: whether the curve works, whether you can consistently make your early plays, and whether the strategy actually does what you think it does.

It’s essentially a form of prototyping. You test the system before introducing the complexity of another person making decisions against it, then take it into the real game and see what survives contact with an opponent. That’s not so different from the way I think about prototypes, research and live product feedback. Each gives you a different kind of evidence, and the mistake is expecting one of them to answer every question.

The post-game is where you actually get better

Losing at Magic used to just annoy me. I’d queue into the next game, still tilted, making worse decisions because I hadn’t processed the last one. What changed my results more than any deck tech was learning to review a loss before immediately moving on.

What did I keep?

What did I hold back?

Where did the game actually turn?

What did I know at the time, and what do I know now?

The honest answer is often uncomfortable. Sometimes I lost because the opponent had a better deck or drew exactly what they needed. But quite often, the outcome can be traced back to a decision I made several turns earlier, which I just didn’t recognise as important at the time.

Mark Rosewater, Magic’s long-standing lead designer, has written a whole series on the lessons of twenty years of design, including a mechanic that failed because it rewarded players for ignoring each other. His conclusion was that when players don’t enjoy what a mechanic asks of them, the fault belongs to the designer. That has always resonated with me, because it’s remarkably easy to blame the player, the user, the market or “the org” when something doesn’t work.

It’s much harder to sit with the possibility that the design was the problem.

That same instinct shows up in product organisations. When something doesn’t land, there are usually plenty of plausible explanations. The market changed. The brief wasn’t clear. Engineering couldn’t deliver. Research was inconclusive. A stakeholder changed their mind. Sometimes those explanations are completely valid. But if we never go back and examine the decisions we made, we lose the chance to tell the difference between bad luck, external factors, and decisions we could actually improve.

“Learn from your mistakes” is advice so generic it’s almost meaningless. The useful part is the discipline behind it. A good post-game asks you to reconstruct the decision from the information you had at the time, rather than judging it entirely from the outcome. That matters, because a good decision can still produce a bad result, and a bad decision can occasionally produce a good one.

I’ve found the same distinction useful when running retrospectives with design teams. Rather than asking simply what went wrong, I want to understand what we believed, what evidence we had, what assumptions we were making, and where those assumptions turned out to be wrong. That usually produces fewer actions, but better ones, which is the entire point. A retrospective earns its hour by improving the next decision, not by making everyone feel reflective.

We can’t always know exactly why something failed. We can get better at examining the decisions that led us there.

None of this makes the hobby less ridiculous

I’m not claiming Magic is secretly a leadership course, or that I’ve cracked some code by playing a card game with dragons on it. What I’ve found is narrower, and more useful.

Magic gives you a system where decisions happen quickly, consequences are visible, and feedback arrives before you’ve forgotten what you were thinking when you made the choice.

Product organisations are almost the opposite. The consequences are slower, the variables messier, the feedback noisy. By the time you know whether a decision was good, the context around it has changed and there are plenty of other explanations available. Which is exactly why the post-game matters more here, not less.

Good decisions can still produce bad outcomes, and sometimes luck really is just luck. But teams get better when they’re willing to look honestly at what the last decision taught them and carry that into the next one.

So if you’re a designer or design leader who’s never played Magic, I’m not telling you to start. Although if you do, come find me on Arena. I always need better competition.

I’m more interested in the version of this that already exists in your own life. Somewhere, there is probably a system that gives you unusually honest feedback about the decisions you make.

Pay attention to it.

Mine happens to involve a lot of dragons.

Further reading, if this scratched an itch: