Recapturing fan engagement from third-party platforms and giving the league full brand control over its most-anticipated annual event.

Client: MLB
Role: Product Manager
Date: 24-09-2025

Post-season Bracket Challenge

Recapturing fan engagement from third-party platforms and giving the league full brand control over its most-anticipated annual event.

The Brief

Major League Baseball needed an official home for postseason bracket predictions. The strategic challenge was twofold: recapture fan engagement leaking to third-party platforms and establish total brand control over the league’s most-anticipated annual event.

The immediate ask was straightforward: build a bracket product. The product opportunity was harder: design and execute it in a way that didn’t create a one-off bespoke solution for MLB, but instead advanced our core FanKit platform with features that future clients could reuse, building competitive moat in the process.

The constraint that shaped everything: 80% of what MLB needed already existed in our product. The question was what to do with the remaining 20%.

The Strategic Question

We could have built it three ways:

1. Bespoke. Ship fast, keep MLB happy, lock in 200 days of engineering resource that vanishes when the project ends. Repeat this for every new client at different scale.

2. Customisation layer. Bolt on MLB-specific features, accept that they won’t transfer. Marginal product improvement.

3. Platform investment. Identify the 20% gap. Determine which pieces solve problems we’ve seen before or will see again. Build those into the core product. Deliver MLB on top of the improved platform.

Option 3 was the only one that created lasting value. It also meant saying no to some of what MLB wanted and pushing back on what the commercial team was comfortable with. That’s where most of the actual product work happened.

Discovery & Prioritisation: The Master PRD

I started with inventory, not prioritisation. One master PRD that listed every single feature in FanKit that could possibly go into a bracket experience: every micro-feature, every UI component, every backend service call, everything.

Then three questions for each:

1. Does MLB need this?

2. Have we already built this?

3. Does this feature exist in the product yet?

The output was a map. Some features were shelf-stock—use as-is. Some existed but needed customisation for MLB’s specific case. Some didn’t exist at all and needed definition.

For the features that didn’t exist, I went a layer deeper: How do we need this to work for MLB? But how do we need this to work generically, so it transfers to the next client?

This wasn’t a prioritisation matrix. It was an architectural decision made visible. It forced the question: Are we solving for MLB, or are we solving for the product? If the answer was “both,” we had to define it at a level where it served both.

Three pieces stood out as platform-wide improvements:

1. Sports Betting Market Integration with State-Level Gating

MLB wanted to surface relevant betting markets within the bracket experience. The obvious approach: hardcode betting market logic for MLB. The platform approach: build a reusable betting market layer that respects state-level regulatory constraints, so any future client in a regulated vertical could plug in their own market feeds with automatic geographic filtering.

This wasn’t just a nice-to-have. Every sports entertainment client we’d spoken to wanted to cross-sell betting or gaming—and every one of them needed to handle geo-fencing. We solved it once, properly, instead of three times badly.

2. Automatic Advancement & Buy Logic

In a traditional bracket, all competitors and their seeding are known at the start. MLB’s postseason isn’t. Wild Card teams haven’t played yet. Division Series outcomes determine seeding into the Championship. The bracket itself was unknowable until late in the calendar.

We’d seen this pattern before (low priority, mentioned by several previous clients as “nice to have”). But we hadn’t solved it. The solution: pre-bracket pools. Users predict which teams advance through qualification stages and where they’ll sit in the bracket, then lock their main bracket prediction based on that seeding.

This wasn’t bespoke to baseball. Any tournament with qualification rounds needed this. We built it as a first-class feature in FanKit, not a baseball-specific bolted-on hack.

3. Seeding Prediction Game

The pre-bracket pools feature unlocked something none of our competitors shipped: a competitive advantage at pitch time. When we presented FanKit to future bracket clients, we could show that we’d already solved the “tournament with unknown seeding” problem. That’s the feature that closed deals.

Execution: PRFAQ & Feature Ticketing

I structured the project around a PRFAQ that made the platform investment case explicit. The document forced clarity: Why are we building this? Who benefits beyond MLB? What does success look like in year two when the second bracket client arrives?

From there, every feature got a ticket. Every ticket got scored for:

Effort – t-shirt sized with the engineering team

Type – pre-existing feature, customisation on existing, new platform feature, or bespoke

Reusability – does another client need this?

Commercial value – does MLB need this to launch?

The feature matrix revealed the actual load distribution:

~ 60% existing FanKit features, used as-is

~ 20% existing features needing customisation or new variants (e.g., bracket UI reskinned for MLB branding, new filter options on market selection)

~ 15% new platform capabilities (the three pieces above)

~ 5% bespoke to MLB (league-specific content, branded UI treatments that don’t transfer)

Working with the accounts manager and commercial team, we looked at the matrix and made hard calls. Features that were bespoke and high-effort got cut or deferred. Features that were new but reusable got resourced. Features that were both bespoke and low-effort got scheduled as “nice-to-haves” if engineering had time.

Distributed Ownership: Why This Needed a Product Manager

This is where the project shape became clear. The master PRD wasn’t owned by one team. Features were distributed across four separate teams:

APIs & Services: Data ingestion, backend market feeds, state-level gating logic, analytics pipelines

Frontend Web: Bracket UI, scrolling animations, market selection filters, live score updates

SDK & Native: Bracket embedding into native apps, cross-platform data passing, offline state management

Analytics & AI: Predictive ranking algorithms, user segmentation for betting market exposure, real-time scoring

No single team owned “the bracket.” The bracket was the intersection of four domain areas, each solving part of the product architecture.

If this had been a project management exercise—ship MLB’s bracket—one PM would have tracked timelines and handoffs. But this was a product exercise: ensure that four teams, many of whom had never worked on the core platform before, built features that would survive beyond October.

That meant the PRD wasn’t a specification. It was a contract. It said: Here’s what we’re building. Here’s why we’re building it this way, and here’s how your piece fits into something bigger than this one client.

Each team got the full context: not just their slice, but how it connected to the others. The APIs team needed to know that the Frontend team would call their endpoints in a specific sequence. The SDK team needed to know that Native apps would pass context upward in a way that the Analytics team could consume.

A project manager assigns work. A product manager ensures the pieces connect intelligently and stay connected for the next client.

Design & Technical Alignment

At each phase—PRFAQ, feature definition, design, build—I worked in parallel with design and engineering to reality-check effort estimates and uncover dependencies.

The betting market integration surfaced a question from engineering: What happens if a market is legal in California but not in Nevada, and a user travels between states during the bracket window? That’s not a theoretical edge case in sports; it’s a known user pattern. We designed for it properly—market eligibility re-evaluated on each session, not cached—which meant the solution worked for every regulated vertical, not just sports betting.

The seeding prediction feature looked simple on a wireframe (select advancing teams, confirm bracket slot). Engineering pointed out that it needed versioning logic—if predictions changed between lockout and bracket start, did users’ brackets rebase automatically or stay locked? We designed for both modes and made it a configuration flag, because different clients would want different behavior.

Execution: Documentation as Definition of Done

Most projects define done as: shipping, code review, tests passing, no P0 bugs. Those things matter. But they don’t tell you if another team can pick up your work nine months later and ship it for a different client without rediscovering everything you learned.

I reset the definition of done for this project to one measure: exemplary documentation.

Not documentation as an afterthought. Documentation as the proxy for whether the feature was actually built right.

Here’s why: if the documentation explained what the feature does and why, if it pointed to the right parts of the code, if it helped a new user set up a bracket, if it explained the feature to sales and design and another engineer who’d never touched it before—then everything else was done well. If the documentation was rigorous, the code was modular. If the documentation was complete, the feature was reusable.

Different teams approaching the same product for the first time needed to understand not just their piece but how it fit. The APIs team needed docs that explained state-level gating logic. The Frontend team needed docs on when to call which endpoints. The SDK team needed clear contracts on what data flowed upward.

Saying “documentation is done” meant each team had to think beyond their sprint. They had to think like someone else would maintain it. That discipline surfaced design decisions that otherwise would have been hidden in pull requests. It forced versioning conversations early. It prevented custom hacks that only one person understood.

The secondary benefit: when the next bracket client arrived, their setup cost was configuration and documentation review, not rediscovery.

Outcome

MLB launched with a fully branded experience built entirely on FanKit. Zero bespoke code in production. Every feature either pre-existed or became a reusable platform capability.

More important: we closed the 20% gap in the product. The next bracket client arrived nine months later. Their seeding prediction requirement—which had been “nice to have, low priority” for previous clients—was now a 15-minute configuration in FanKit, not a two-sprint build. The betting market geofencing worked out of the box. Their time to launch dropped from an estimated 20 days to 4.

The payoff wasn’t speed on MLB. It was the leverage we built for the platform.

Key Lessons

Bespoke is cheap to sell, expensive to ship. The commercial team wanted to say yes to everything. Saying no to bespoke features meant harder contract negotiation in the short term. It meant explaining the value of reusability to a client who just wanted their bracket built. Worth it, every time, because you’re not explaining it again to the next client.

Low-priority features compound. Seeding predictions were “nice to have” on multiple projects we’d pitched. It took seeing the pattern repeat to realise this was a real product gap, not noise. The matrix helped surface which “nice-to-haves” were actually systemic problems waiting for a budget to solve them.

Feature-level effort estimates are half the job. Scoring features with engineering matters less than mapping dependencies. Market geofencing isn’t complex logic, but it touches data pipeline, session management, and UI state. Getting those conversations early (not during build) saved weeks of rework.