Method
How I work
Every case on this site runs through the same six phases — and so does most of my paid work, where this process sits behind financial reporting that people make decisions on. What makes it a method rather than a habit is that every phase has an exit gate.
I don’t move to the next phase until every item on that gate is met. When something fails, I go back rather than improvise forward — finding out during analysis that the data can’t answer the question means returning to Ask, not writing a softer conclusion.
The six phases
| # | Phase | Question it answers | What it produces |
|---|---|---|---|
| 1 | Ask | What is the real problem, and whose is it? | A business question, the decision it unlocks, and metrics with operational definitions. |
| 2 | Prepare | Is this data any good, and can I trust it? | A record for every source: origin, licence, period, known biases. |
| 3 | Process | Is it clean, and can I prove it? | A cleaning log where every transformation carries its reason and its row counts. |
| 4 | Analyse | What does the data actually say? | Results, plus the checks I ran to try to break them. |
| 5 | Share | Will the audience understand it? | Charts whose headline is the finding, not the variable name. |
| 6 | Act | What should the business do? | Recommendations ranked by impact against effort, with their limits stated. |
Three rules I don’t break
I document as I go, never afterwards. In three of the six phases the documentation is the deliverable. Reconstructing decisions from memory produces weak work, and it’s exactly the detail an experienced reviewer notices.
I don’t invent numbers. If a figure didn’t come out of the data, it doesn’t enter the report. Where there’s a gap, I declare it as a limitation instead of papering over it.
I never edit raw data in place. Every transformation produces a new file and an entry in the cleaning log, so the whole chain can be re-run from the original source — by me next month, or by you today.
What you can read, and how deep
A case study produces far more material than anyone wants to read at once, so I publish it in three layers. This page and the case pages are the first two; the third is one click away in each case’s repository, for anyone who’d rather check the work than take my word for it.
| Layer | Time | What it is |
|---|---|---|
| The card | 15 seconds | Headline, key chart, and what the case demonstrates. The home page. |
| The case | 5 minutes | Context, data, process, findings, recommendations, limitations. |
| The evidence | 30 minutes | Cleaning log, scripts, source records, the full case record. In the repository. |
Where the questions come from
I pick questions I actually want answered. The Steam case started because I wanted to know whether cheap games really are worse, or whether that’s just something people repeat — and the only honest way to settle it was to go and look. That’s the first filter: if I’m not curious enough to argue with my own result, the case won’t be worth defending to anyone else.
The second filter is what a case will teach me. Each one is chosen partly for the tool or technique I want to get better at, which is why the next will lean on SQL: it’s what I use daily at work, and nothing here shows it yet.
The six-phase spine — Ask, Prepare, Process, Analyse, Share, Act — comes from the Google Data Analytics process. The exit gates, the three-layer publishing model and the templates behind every case are mine, built while running this on real work.