Why Is The Product Limited To A Maximum Of 30 Picks/Entries?

As much as we'd love to support pick optimization for an unlimited number of survivor pool entries, calculation complexity is a constraint.

If you’re a hard-core player in survivor pools, you may have encountered a limitation of our NFL Survivor Picks product — the size limit. You can only generate a maximum of 30 concurrent pick recommendations* per week across all your pools and entries.

*The limitation applies to picks, not entries. At the beginning of the season, when almost no pools require multiple picks per week, picks and entries are basically the same. Later in the season, when some entries may be making multiple picks per week, the 30-pick limit may mean fewer than 30 entries.

Why do we have to apply this limit? To put it simply, calculation complexity.

Complexity Is Good!

Our pick optimization logic for multiple entries uses something called linear programming. Essentially, we throw all the custom pick rankings for every team available for each of your entries into a set of equations. (Well, not every team, as we filter out obviously bad picks right at the start.)

Then we add more equations for what we like to call “soft constraints.” These are penalties for violating some portfolio construction guidelines. This includes things like:

• Use highly-graded teams more often than teams with low grades.
• Try to make each entry in a pool save different teams for the future, so you have more flexibility.
• Try to limit the portfolio to at most X different teams (where X varies based on your portfolio size).
• Prioritize using the top picks on the entries with the highest expected prize share.
• Prioritize using the top picks on the entries with the most future value still available.

We end up with a huge list of equations, with the unknown variables being which team to use on which entry. Then we feed those equations and variables into an optimization algorithm, and let it do its thing.

The end result is a set of picks that simultaneously tries to maximize the total grade of all the recommended picks (i.e. use the top ranked team whenever possible), but also not violate too many of the soft constraints (i.e. follow as many of the portfolio construction guidelines as possible).

The upside of using this flexible and complex system is that it lets us optimize picks for so many different kinds of portfolios. We can handle anything from a single entry in a single standard rules pool to 30 entries spread across a dozen or more pools, each with different rules, sizes, and entry fees.

That level of optimization wouldn’t be possible if we had to code strict decision rules for every potential scenario.

Complexity Is Bad!

The downside to this complexity is that it’s slow to calculate, even given the power of modern computing. And it gets exponentially slower as we add more picks and more rules into the mix.

Imagine you have only a single entry in a single survivor pool. And let’s say for the sake of example that we’re going to ignore any team ranked worse than 5th in our pick rankings for a given entry, even though we can’t really do that in real life scenarios involving large pick portfolios.

Great, easy! Our system only has to evaluate 5 unique possibilities for potential pick options, and the best option is obviously the one that uses the top-rated team.

OK, now add a second entry to the mix. The system now has 5 x 5 = 25 different potential pick combinations to evaluate. A third entry means there are 5 x 5 x 5 = 125 combos. Thirty entries means there are 5^30 = about 931 quintillion possibilities. For a single one of our customers. Who may be clicking the button to get updated picks multiple times per day, as new information like betting line changes come in.

Now, obviously we can’t directly evaluate all of those possibilities, and there are shortcuts we take to eliminate a lot of the options right at the start. Then the optimization algorithm uses some tricks to further reduce the set of potential solutions for which it actually needs to run calculations.

Still, the complexity grows at an alarming rate once you get up into the larger portfolios. So we had to make a cutoff somewhere.

What Happens With No Limitation?

For one thing, most web browsers won’t let us sit there and run calculations for five minutes before returning a result to you.

(There are ways around this, like letting you request a portfolio calculation that we then deliver later via an email or an alert. We haven’t built that capability yet, but it’s on our list of considerations, as we mention below.)

In addition, the linear programming optimizer we use isn’t perfect. If things get too complex, it can sometimes fail to find a solution.

So we’ve done a lot of testing to find a total pick number limitation that would reliably prevent failures, but still allow fairly large portfolios of picks. And for now, 30 picks is the reliable number we’ve settled on.

Future Plan

Would we like to allow larger portfolios? Absolutely. It’s something on our long term roadmap for the Survivor product.

It’s kind of a classic product building conundrum — a complex feature that would only appeal to a very small fraction of our subscribers, yet be highly valued by them.

Could we justify the time investment and opportunity cost by charging more for it? Maybe. But then that makes our purchase process more complex, etc., etc.

So for now, Option A is an unreliable product that would return an error any time you requested picks that exceeded some level of complexity with your pools that wasn’t even clear to you. You’d then have to keep deleting pools and entries until the system finally returned a solution, with no guarantee that it would even work the very next time you went to get picks for that very same set of pools and entries.

The whole time, you would be crying out in rage and cursing the buffoons at PoolGenius because they built this crap product you paid good money for, and it’s failing you when you only have seven minutes and 37 seconds to get your picks in.

Option B is a 30-pick cap that we’re confident will work every time. That’s why we chose Option B.