Survive the week. Outlast the field.

NFL survivor pools are simple by design: pick one team each week, and if they win you survive. That simplicity makes the game easy to understand, but it also makes it repetitive, especially when the whole thing is run by hand through spreadsheets, email threads, and chat messages. I built Gridiron Island as a personal project to explore how a familiar survivor format could become a more complete digital product: keep survivor football simple, then add stronger game mechanics, automation, strategy, and personality. Players select one NFL team each week they believe will win. A correct pick keeps them alive; a losing pick puts their season at risk. Underneath that familiar mechanic sits a game system designed for an 18-week NFL season and a pool of about 20 players, with rules governing weekly selections, survival status, team reuse, deadlines, elimination, tie-breaking, immunity, standings, simulation, and season progression. The objective was to make the game simple for the player while increasingly sophisticated logic operates behind the scenes.

Traditional survivor pools create unnecessary administrative work, and the game itself tends to flatten once people learn the rules:

• Someone always has to collect weekly picks, check whether they arrived on time, verify game results, track eliminated players, enforce rules, resolve ties, and maintain standings.
• The bigger the group becomes, the harder that process is to manage; the organizer spends the season running the pool instead of playing the game.
• Once players understand the basic rules, most survivor pools do little to create additional strategy or differentiation, so everyone converges on the same safe pick.
• Unusual situations have no agreed answer, so the organizer becomes the interpreter of the rules, and that costs trust.

Product Manager, Product Designer, and Builder on a personal project spanning game design, product strategy, automation, UX, a rules engine, and AI-assisted development.

1. 1.

   Weekly survival pick

   Every active player makes one NFL selection for the week. If the team wins, the player survives. The mechanic intentionally stays familiar so a new player can understand the basic experience immediately.

2. 2.

   Boldest Survivor

   Instead of rewarding whoever picks the week's biggest favorite, the game recognizes a player whose selection stands out from the rest of the field. That player can earn an advantage such as immunity. It adds a real strategic question: do you make the safest possible choice, or take additional risk in exchange for a potential advantage?

3. 3.

   Least-picked tie-breaking

   Another design challenge was deciding how the game should handle players who perform similarly. I developed tie-breaking logic based on how frequently a team was selected, so a player choosing a less popular team can gain an advantage over someone making the consensus pick. That reinforces the philosophy behind the game: survival matters, but smart differentiation should matter too.

4. 4.

   A rules engine, not a tracker

   As the game became more sophisticated, the project stopped being a tracker and became a rules engine. For every player the system had to know whether they were still active, which teams they had selected, what they picked that week, whether that team won, whether they held immunity, whether the pick was valid, and how the result affected the standings, plus the NFL schedule and week-to-week advancement. Rules that sound simple when explained verbally become much more complicated when they have to work consistently in software, so informal game rules had to be converted into explicit product logic.

5. 5.

   Simulating the season before launch

   I created an 18-week simulation with 20 players to test how the game behaved across a full NFL season: multiple players choosing the same team, unusual elimination patterns, immunity affecting survival, tie-breaking, shrinking player populations, repeated selections, season progression, and edge cases late in the season. Rather than waiting for real players to discover rule problems, simulation surfaced them before the pilot. The project reached 127 passing tests, giving confidence that the core rules and game logic behaved consistently.

6. 6.

   Keeping the player experience simple

   Even with that much logic behind the scenes, the player experience stayed deliberately minimal. A player shouldn't need to understand the architecture of the game; they need to know who they can pick, whether they survived, who is still alive, and what happens next. The principle that shaped the experience: complexity belongs in the system, not in the user's workflow.

7. 7.

   Automating the administration

   Automation wasn't just a technical convenience here; it was part of the product value. A well-designed game platform shouldn't depend on someone updating spreadsheets every Sunday night, so the system validates player selections, evaluates results, updates player status, applies game rules, calculates standings, advances the competition, and resolves defined tie-breaking scenarios. That reduces administrative overhead and makes the experience more trustworthy: players compete against the rules, not against someone's interpretation of the rules.

• Even simple products contain significant systems complexity. The visible product is a football game. Underneath it are state management, rules, exceptions, user behavior, fairness considerations, data dependencies, and edge cases, which made the project as much an exercise in systems thinking as in product management.
• The best automation often disappears from the user experience. Players don't need to appreciate the complexity of the rules engine. They simply need the game to work. The more reliable the system becomes, the less attention the underlying complexity requires.
• Simple for the player doesn't mean simple in the system. Complexity belongs in the system, not in the user's workflow. The application handles the rules so the player can focus on the game: who can I pick, did I survive, who is still alive, what happens next.
• Product thinking can transform a familiar activity. I wasn't trying to reinvent football; I was trying to make the experience around it better. Take a simple game, remove the administrative friction, add meaningful strategy, and make the rules trustworthy.