Our approach: data, play and iteration

Every studio has a way of working, whether or not it writes it down. Ours comes down to a short sequence: look at what the game actually does, form an honest view, change one thing, and check the result. It is unglamorous, it is slow at the start, and it is the habit that has improved every project we have touched. This article sets out how we work and why.

Measure before you change anything

The strongest instinct in a struggling studio is to fix something, anything, and to start immediately. The problem is that fixing before understanding usually addresses a symptom rather than a cause, and the game ends up with a new feature it did not need and the old problem it did. We insist on looking first.

Looking means two things at once: playing the game as a player would, and reading the data as a studio would. Neither alone is enough. The play shows why a thing happens, and the data shows how often it does, and the useful conclusion lives where the two agree.

Play, then measure, then play again

We treat play and measurement as a loop rather than a sequence. Play the game, form an impression, look at the numbers, play again with the numbers in mind. Each pass sharpens the last, and by the third or fourth we usually have a short list of causes worth testing rather than a long list of symptoms.

This loop is most valuable early, because a diagnosis that arrives before the team has committed to a direction saves an entire rework. Finding the real problem late is expensive; finding it in the first weeks is almost free.

Iterate in small, honest steps

Once we understand a problem, we change as little as we can while still testing the idea. A small change has a clear effect that can be read, while a large one bundles many guesses together and teaches almost nothing. We would rather make five small, readable changes than one sweeping one whose result nobody can interpret.

• Change one thing at a time where the game allows it.
• Write down what you expect the change to do.
• Read the result honestly, including when you were wrong.
• Keep the change if it helped and drop it if it did not.
• Record the lesson, not just the outcome.

The discipline is in reading the result without defending the decision. A change that fails is a cheap lesson when it was small, and a change that succeeds is only trustworthy when it can be reproduced.

What the approach asks of a team

The table below sets out the habits our approach depends on and what each one asks of the people doing the work. None of them are technical; all of them are behavioural, which is why they are the harder part to adopt.

Why we avoid big predictions

We are wary of any plan that depends on a large prediction about the future. Big predictions are seductive because they are impressive, and they are fragile because they rest on assumptions a small team cannot check. We prefer to make the next decision well and let the ones after it be informed by what we learn.

This refusal extends to the promises we make. We do not promise download, revenue or retention outcomes, because no honest studio can. What we promise is a careful method and a straight answer, and that is a promise we can actually keep.

How we know a game is improving

Improvement is easy to claim and harder to prove, so we agree in advance what would count as a sign that a change helped. That usually means a clear expectation written before the change, paired with the behaviour it should move. Without a stated expectation, any result can be read as a success, and a studio can convince itself of almost anything.

We also look for the improvement in the player's experience rather than only in a dashboard. A number that rises while the game feels worse is not progress; it is a warning that has not been noticed yet. Keeping the two readings together is what stops a team from optimising its way into a game nobody enjoys, and it is the habit we trust most when the data and the feel disagree.

Iteration as the whole method

Strip away the detail and our approach is a single idea: understand before acting, act in small steps, and stay honest about the results. It is not clever and it is not quick, and it is the difference between a game that slowly improves and one that accumulates features without getting better. The rest of our work is that idea, repeated.