Choosing what not to build when the data already existed

Every input the predictive version needed already existed. Building it first would still have been the wrong call, and the reason generalises well beyond sport.

Summary. Every input the ambitious version needed already existed. Building it first would still have been the wrong call, and working out why is the thing I have reached for most often since.

Context

Between 2020 and 2021 I co-founded a sports analytics company and ran product for it. The setting was amateur club rugby, and almost everything that mattered follows from that.

The data was already being generated and nobody held it in one place. Wearables and phones carried sleep, activity and recovery. GPS units carried what happened on the field. Physiotherapists held injury and rehabilitation history. Coaches held availability, selection, and what they had watched with their own eyes on a Saturday. Every source belonged to a different person, and none of them met.

The intent

One view of a player across all of it, on field and off, with a model sitting over the top. Not a report describing what had already happened, but something that could see where load was accumulating, who was drifting toward injury, and whether a player was quietly improving or quietly going the other way.

That is a real product. The inputs existed. The techniques were not exotic. On paper there was nothing stopping us building it.

Why the obvious plan was wrong

A model like that needs a season or two of joined-up history before it can tell a coach anything he could not already tell you himself. We had none of it, and there was no way to buy it. The only route to that history was to be installed, opened and trusted through a full season first.

So the part of the product that justified the company was gated behind the ordinary part surviving long enough to collect its own inputs. The constraint was never technical. It was that we had not yet earned the year of use that made the interesting thing possible.

My role

Co-founder and product owner. The call on what not to build was mine.

Constraints

Amateur sport has no mandate and no budget line. Nobody's job description says open the analytics platform, and nobody can be instructed to. Adoption had to be voluntary, from people already giving up their evenings.

The users were not analysts. A coach has minutes, not an afternoon, and no obligation to learn anything.

And the company was resource-constrained enough that the first release was not a step toward the product. For a while it was the whole company.

Stakeholders

Coaches, players, physiotherapists and domain experts. None of them reported to us, and all of them could simply stop.

The decision

We built the first release around performance, wellness and availability, and chose those three because each one fed a decision a coach was already making, not because they were the most sophisticated signals available. The predictive layer was designed and deliberately not shipped.

The uncomfortable part of that decision is that it made us look less capable than we were. What went out could be mistaken, at a glance, for something a diligent manager could keep in a spreadsheet. We knew what was behind it and nobody else could see it.

Approach

Discovery with coaches and domain experts before the MVP was defined, a live pilot with a club side, then feedback loops during the pilot so changes came from watching real use rather than from what we assumed people wanted.

Outcome

The MVP was defined, built and piloted with a real club in a real season. The company paused after that pilot on market conditions, so the accumulated history the predictive layer depended on never arrived.

That is the honest ending. What we proved was that the modest version was usable and used. The thesis underneath it was never tested, and I am not going to claim otherwise.

Lessons

The constraint is almost never the technology. It is whether the organisation, or the club, or the team has arrived at the point where it can absorb the thing. Capability that depends on trust, data or habit can only be built in the order those accumulate, and no amount of engineering shortens that.

Leading with the ambitious version spends credibility before there is anything to spend it on. Leading with the ordinary version buys the year that makes the ambitious version possible. That is not a compromise on the vision. Most of the time it is the only route to it.

I have met the same shape repeatedly since, in an enterprise rather than a clubroom, and with considerably more at stake. It is the reason most of what I write here is about the distance between a capability existing and an organisation being able to use it.

What I would do differently

I would have treated the first release explicitly as the instrument that collects the season, rather than as a smaller version of the eventual product. Largely the same features, a different design brief, and a much clearer answer to what the first year was actually for. I would also have said that out loud to the people funding it, because a first release that is openly the foundation for the second is a far easier thing to be patient with.

Confidentiality

This account describes my own company. The club is not named, and no player, medical or performance data is described. It does not represent the views of any current or former employer.