The infinite menu

Anything you can name, you can now have built by Friday. That is not the good news it sounds like.

For most of the history of making things, the world did your choosing for you and never sent a bill. You wanted to build the dashboard, the side product, the second newsletter, and the estimate came back at six weeks, or the skill was one you did not have, or the budget was one you could not get. So it fell off the list before you ever weighed it. You were not deciding. You were reading the survivors, the handful of things cheap enough and easy enough to reach the table at all, and picking from those. It felt like judgment. It was a filter you did not build and did not pay for, quietly throwing away the bottom of the menu while you slept.

The tools deleted that filter. Every feature, every product, every side project you can describe is a prompt away, which means the menu is not shorter now, it is effectively bottomless. And the menu did not fill up with junk. It filled up with good options. A menu of bad options is easy. You cut, you move on. A menu where every third thing would actually work is where capable people go to freeze.

I have stood in exactly that spot, and recently. I was putting out a run of pieces, and any single one of them was buildable in an afternoon. Making them was never the wall. Choosing which two or three deserved a careful reader's limited attention that week, that was the wall, and it turned out to be a different wall than I thought. I could not rate them into an order. They were all defensible. What finally moved me was naming the thing I was actually short of, which was not hours and was not ideas. It was the attention of someone who reads carefully and does not have all day. Once that was the budget, the pieces stopped being a list of good things and became a ranking against one scarce thing, and a ranking has a top.

The honest counter is not a soft one. Choice overload is mostly a myth. You have probably heard about the jam. In 2000 two researchers, [Iyengar and Lepper](https://faculty.washington.edu/jdb/345/345%20Articles/Iyengar%20&%20Lepper%20(2000), ran a tasting table at a fancy grocery, and the display with twenty-four jams pulled a bigger crowd but the display with six converted about ten times better. Lovely study. It also does not reliably replicate. In 2010 Scheibehenne and two colleagues gathered fifty experiments, sixty-three conditions, five thousand and thirty-six people, and the average effect of giving people more options on whether they could choose came out at roughly zero. People handle enormous menus every day. The streaming catalogue, the supermarket, the app store, and they mostly do fine, and more options usually leaves them better off. So the whole premise, the argument runs, is a dramatised non-problem. Just build something. Abundance is good. The paralysis is a rare edge case, not the rule.

The meta-analysis is right, and it is the answer, not the objection. Read what it actually found. The effect is not universal, it is conditional, and someone went and mapped the conditions. In 2015 Chernev, Böckenholt and Goodman reconciled the whole messy literature and pinned down when abundance actually jams a person: when the options are hard to compare, when you walk in without a settled preference, when the task itself is difficult, and when you have no clear goal to sort against. Meet those and the menu bites. Miss them and it does not. Now hold the jam up to that list. Picking a jam is low stakes, one dimension, reversible in a spoonful, and you already know you like the apricot. It meets none of the conditions, which is exactly why it does not replicate.

Now hold the build decision up to the same list. The options are not comparable, you are weighing a product against a tool against a course, and there is no shared unit. You often have no settled preference, because the thing did not exist as an option until the tools made it one. The task is hard. And the moment you ship, the thing you built stops being a jam and starts collecting users, obligations, and a maintenance tail that follows you for years. The build decision does not resemble the jam. It hits all four conditions at once. So the counter is correct that most abundance is harmless, and wrong that this abundance is that kind. The freeze is not a character flaw and it is not you being precious. It is the predictable output of a specific decision that happens to have every property known to break selection, handed to a person with no external filter left to lean on.

And the freeze has a twin that looks like its opposite. Faced with a bottomless menu and the low hum of dread that comes with it, plenty of people do not stall. They grab. They seize the first shiny buildable thing, ship it fast, and call it bias to action. It feels like decisiveness. It is paralysis that flinched. The grab and the freeze are the same failure, an unaided person with no way to cut an infinite menu, and one of them just found the discomfort unbearable a little sooner.

Willpower does not fix this, because the problem was never nerve. And taste does not fix it either, which is the trap people fall into hardest, because taste rates one thing at a time. Is this good. It is, they all are, that is the whole problem, and a tool that returns "yes" for every option on an infinite menu is not a tool, it is a mirror. The problem is comparative and it has no edge, and you cannot rate your way out of a comparison.

So you put the edge back on yourself, on purpose, because nobody is going to do it for you now. Three moves, and none of them are about working harder.

Set the binding constraint before you look at the options, not after. Name the one resource you are actually short of this quarter. Not a vague sense of busyness, the real one: your own attention, one specific skill you have and can spend only so much of, the calendar weeks between now and something that matters, a particular audience's patience for being asked to care again. Say it out loud and make it the budget. The menu is only infinite because the tools removed the constraint. Put one back and the menu gets an edge again. Whatever you declare here is the thing that does your cutting, so declare it deliberately, or the loudest option in the room will declare it for you.

Rank the options against each other, do not rate them one by one. Rating is taste and taste passes everything. Ranking forces a single question across the whole set: which one of these, if it works, makes the next three things easier to build. That question only means anything in comparison, and it quietly kills the ties, because two good options are almost never equally good against a real budget once you stop grading them in isolation and make them stand next to each other.

Commit by naming what you are foreclosing, then start a clock. Say what building this one costs you the chance to build. Name the other two you are dropping, by name, out loud. If you cannot name what you are giving up, you have not chosen, you have only begun, and begun is where things go to sit for a month. Then set a hard date to ship the smallest real version, because a bottomless menu has no natural stopping point and the only stop is the one you supply. This is where both failures die. The grab cannot survive being made to name its foreclosures, because it never had reasons for them. The freeze cannot survive a date.

One count to close, and it is the uncomfortable kind. Name the last thing you decided to build. Now name the two comparably good things you decided not to build in order to build it. Two blanks means you did not select. You grabbed the first buildable thing and reverse-engineered a reason on the way to shipping it. That is not a discipline problem and it is not a nerve problem. It is a missing constraint, and the constraint was always yours to set. The tools took away the one that used to set it for you. They are not going to hand you a new one. That part stayed your job.