How to build a football analytics portfolio that works

A CV says what you have done; a portfolio shows how you think. In football analytics, where almost every candidate claims to love both data and football, the portfolio is the only part of an application that can actually be checked.

This guide covers what a working portfolio contains: analysis written out, small models that show method, visuals that survive a second look, and the written conclusions that separate an analyst from somebody who can run code.

Why a portfolio beats a CV

Recruitment in football is a small market with many applicants and few entry points. A hiring manager cannot verify a claim about enthusiasm, but can read a few hundred words of your analysis and see immediately whether you understand what a metric measures.

The portfolio is also a test of the job itself. Most of the work is writing, choosing and explaining, so a portfolio that consists only of code notebooks demonstrates a different job from the one being advertised.

What a good project looks like

One project, finished and written up, beats six half-built ones. A finished project has a question, a dataset, a method, a result and a limitation section, in that order, and it can be read in ten minutes.

Choose questions a club would actually ask. How does a team's pressing height change when it leads, and which pass types precede entries into the box? Which players receive in the half-space most often per touch? These are answerable with public event data and they show tactical awareness rather than library knowledge.

A finished project also shows judgement about scope. If a question needs three datasets and a month of cleaning, shrink it until it needs one dataset and a couple of evenings, because the point is to demonstrate reasoning rather than to reproduce a club's entire workflow.

Written analysis is the part candidates skip

A notebook that produces a chart is not analysis. Analysis says what the chart means, what it does not mean, and what a coach should do differently because of it.

Write the conclusion first, then the evidence. Three paragraphs are enough: the finding, the support, the caveat. If the finding cannot be stated in a single sentence, the project is not finished yet.

Mini-models that show method

You do not need proprietary data to demonstrate modelling. A simple expected goals model built from public shot data, a pass probability surface, or a clustering of player roles from event counts will show how you handle features, validation and failure.

Keep it deliberately small and explain the choices. Why this feature and not that one, how the sample was split, what the model gets wrong. A modest model explained well reads as more competent than a complex one presented as a black box.

Visualisations that survive scrutiny

Most football visuals fail for boring reasons: unlabelled axes, no baseline, too many series, colours that carry no meaning. A reviewer notices these in seconds and concludes that the analysis is careless, however good the underlying work may be.

• Label what the number measures and the units it uses.
• Always show a comparison: league average, previous season or next opponent.
• Limit each chart to the single message it needs to carry.
• Use pitch orientation consistently across every visual.
• State the sample size in the caption, not only in the text.
• Prefer a table when the reader needs exact values.

How to present code and notebooks

Code should be readable by a stranger. That means meaningful names, no dead cells, and a short readme that says what the project does and how to run it. A repository nobody can open is a repository nobody will read.

Version control is part of the message. A history of small commits suggests a working process, while a single commit labelled final tells the reviewer that the project was assembled once, for the application.

Common portfolio mistakes

The most common is breadth without depth: a dashboard, a scraper, a model and a chatbot, none of them finished. The second is invisible reasoning, meaning a chart with no sentence explaining why it matters or what follows from it.

The third is borrowed work presented as original. Reviewers in this field have usually seen the public tutorials, and a project that reproduces one without saying so reads as a lack of honesty rather than a lack of skill.

What to send and how

Send a short link, a one-paragraph summary of your best project, and nothing else until somebody asks. Attach the writing, not the whole folder. The reviewer's first question is whether you can communicate, so the application itself should answer it.

A portfolio is not a museum of everything you have learned. It is an argument that you can do this specific job, and every item in it should be there to support that argument rather than to pad it.