From a missing live product to enterprise adoption.

The gap was a usable live product.

Swish Analytics provides predictive sports data and APIs to business customers. College football was missing an important capability: a live offering that could respond as games unfolded. In-play means during the game; a player prop is a prediction about an individual player’s performance. Delivering that offering required models, data, and customer-facing behavior to work together.

Development began in 2024. When I took dedicated ownership of NBA and college-football priorities in early 2025, I made CFB In-Play P1. I owned the product requirements, dependencies, release sequence, and integration readiness, working across Data Science, Data Engineering, Software Engineering, Trading, and Customer Success. Those specialists built and operated their respective systems; my responsibility was making the whole product coherent and usable.

Decision 01 — Separate two kinds of readiness

Let customers integrate before live validation.

Live validation depended on actual games. Customer integration did not need to wait for them. In May 2025, I released a static test API with documentation and release notes so customers could begin building against the intended production contract before the season.

That separated two risks. Waiting until live data was available would concentrate integration work near launch. Treating static data as a live product would give customers the wrong understanding of readiness. The test API gave them a useful development surface while keeping the live-validation gate explicit.

We then staged production around Week 0 and Week 1 in August. Some internal controls were still being completed, so I kept temporary operating arrangements and market-suspension boundaries explicit. Readiness was a sequence of concrete capabilities, each with its own purpose.

Decision 02 — Make the API a complete product

Define the whole customer workflow.

A price alone does not tell an operator what it can offer. The customer also needs current game state, availability, requests, and results. I defined requirements across those boundaries, including how derived markets inherited suspension behavior and how customers consumed and requested the offering.

After the core launch, we delivered In-Play Bet Request and broader team and match markets in October 2025. Bet Request lets an operator request supported combinations of selections. These follow-on capabilities extended the foundation into more of the customer’s workflow; they were separate releases with separate readiness work.

The same principle shaped the later alternate-line APIs. An alternate line offers a different threshold for the same statistic. I defined two products around existing identifiers and response structures, with explicit distinctions between observed values, projected remaining performance, and projected final performance. Probability, suspension, and incremental-update behavior also belonged in the contract. Engineering owned the implementation.

Decision 03 — Extend the product customers already understood

Turn an adoption prerequisite into shared capability.

A major global operator required live alternate lines before launching CFB In-Play. That made alternates a concrete 2026 offseason priority. I drove a reusable extension of the offering, preserving the identity and structure customers already used.

Delivery included the access path as well as the APIs. Release work exposed customer-enablement and console dependencies, and communication waited until customers could actually be enabled. The alternate-line products shipped in August 2026. The operator subsequently went live. That is the adoption outcome: a stated prerequisite became shared product capability and the customer began using the offering.

A new offering, with continued product ownership.

Swish moved from a missing live college-football capability to an operating product with enterprise integrations, request support, and alternate lines. My work continued beyond the initial launch because the customer’s definition of usable continued beyond it too.

My NBA remit requires the same judgment. In April 2025, I shipped three ready first-quarter markets through Bet Request while deferring team points: its calculations did not reconcile sufficiently with related markets. This delivered useful scope while leaving an unresolved consistency problem out of the release.

Separately, I led CFB prebuilt-parlay scoping and coordinated the generation handoff to Engineering. A parlay combines multiple selections; this summer 2025 work delivered more than 100 prepared combinations and closed the remaining prebuilt-coverage gap across Swish’s six legacy sports. It was distinct from the original in-play launch.

A roadmap has to reach the customer.

The lesson I carry forward is to connect priorities to the full path into use. Early integration access, explicit release limits, consistent APIs, and adoption prerequisites are product decisions. I judge the work by whether customers can use the capability we set out to provide, while keeping the responsibilities of the specialists who make it possible clear.