Before we wrote a line of code
In the first post, I said the brain has two halves. This post is about the first half: the context and the work we did before writing a single line of code.
When you build products, you need to understand who you're building for. For us, that meant speaking with people at football clubs, learning about their day-to-day, and researching how they collaborate and report.
When we started this discovery phase, we thought we knew what we were looking for: we wanted to understand what information should flow from one person to another within the same department to improve decision-making. We believed that if we could consistently capture the context passed from one person to the next, and connect those people, we would achieve our goal. We were wrong, and once we got inside a club's operations, we discovered that making a decision takes a lot more context, from a lot more departments.
We'd opened a can of worms, and we kept digging.
What we actually did
Thanks to the ve2ventures network and our direct connection to clubs through Estrella Football Group, we had three design partners from the get-go who opened their doors to us. We spent hours with the people working at those clubs, and across the project we interviewed hundreds of football professionals about their workflows, how they make decisions and how they work together. For every single role, all 61 of them, we mapped three things.
First, what somebody needs to know to do their job. That doesn't mean what data exists somewhere in the building, but what this specific person needs in front of them to make their decisions. The scout needs different things from the sporting director, even when they're looking at the same player.
Second, what the job involves day to day. That means the real activities and responsibilities, in the order they happen, including all the bits that never make it into a job description. This is where you find out how a club really runs, because the official version and the lived version are never the same. We also mapped how each person enters and shares information, which matters if the software is going to feel native to the way they already work.
Third, who else depends on the work they produce. That means whose work can't start until this person finishes theirs, whose next decision depends on their input and where a single report fans out into four other people's days. This is the wiring of the club, and it's almost always invisible until you go looking for it.
Put those three together across every role and you get a dependency map of the entire club. It isn't an org chart, which only tells you who reports to whom; it tells you how the work actually moves.
The distinction that makes it all work
There's one separation we were deliberate about, because the whole product runs on it.
We separated who has access to a tool from whose data flows into it.
They sound like the same thing, but they're not. The person who can open a screen is often not the person whose work feeds it, and the person whose work feeds it often never opens the screen at all. If you collapse those two ideas into one, the connections break the moment real data starts moving, because you've wired the club to the permissions instead of to the work.
Keeping them separate is what lets a single update travel to exactly the people who depend on it, and only them. Without it, you don't have a brain; you have a filing cabinet with logins.
Why one club wasn't enough
We decided early on that this had to be a platform any club could adopt, regardless of size, league or location, and that decision shaped how we approached the research, because it meant we couldn't learn from just one club.
If you only map one club, you end up building the brain of that one club, with all its habits, workarounds and particular quirks. What we were after was the general shape of a club. We wanted the roles that always exist and the dependencies that always form, even when the names, org charts and football cultures differ. We also wanted the patterns that hold whether you're in the top flight or two divisions below it, in the Netherlands or in Portugal.
Mapping across multiple clubs is how you tell the difference between how a club works and how this one club happens to work. The first becomes a product; the second becomes a very expensive piece of custom software.
Where we are today
None of this is aspirational. Here's what the map looks like today, grounded in real interviews with real people doing real jobs:
- 13 platforms mapped
- 61 roles across the club, defined by what they need and what they produce
- 247 distinct jobs-to-be-done, each tied to its data and its dependencies
That's the first half of the brain: not a feature list, but a working model of how a football club operates.
In the next and final post, I'll cover the second half: the logic, and what happens when one update reaches four departments at once.
If you'd like to see how ClubOS captures context in practice, take a look at this video.
Modernising decision-making