Context
A standing part of my work at Jump is client implementation. The three names cleared for this site are Bucknell, the North Carolina Courage (NCFC), and the Minnesota Timberwolves.
Courage and the Timberwolves also appear in Jump’s public case studies. Those pages are the company’s results. Bucknell is named here from the implementation record, without a public metric attached.
Problem
Moving a club or a campus onto the platform is a cutover, not a login. Records, rules, exceptions, and the people who have to run the next event all have to arrive together.
Approach
- Discovery. Write down the workflow people actually run, including the exceptions a process map skips.
- Migration. Move records and rules, with a cutover plan.
- Training. Leave the skill with the people who stay after the project team leaves.
- Go-live. Stand next to the date, not only the project plan.
Bucknell followed that pattern. Courage (NCFC) followed that pattern. The Timberwolves followed that pattern, with an extended stretch on site in Minneapolis around 2025. Time in the building changes which questions get asked.
I also worked a Timberwolves and Target Center implementation years earlier, at Veritix, from 2013 to 2015. That is a different chapter, on the About timeline. This page is the Jump work.
Outcome
The personal record here is qualitative: the names, the pattern, and the Minneapolis on-site stretch. I am not attaching a cycle-time or revenue figure to these three as my result.
Role
Director of Product, Enterprise AI Strategy at Jump Platforms. The implementation pattern is part of the delivery work, alongside the enterprise AI engagements.
Artifacts
The cutover board in Prototypes is a sketch of this shape: contract, configuration, training, an ingress dry-run, go-live. It is not an internal Jump playbook.