Eleven stars and back

Brian Chesky has a precise definition of a five-star stay. On Invest Like the Best this spring, he described the check-in where the host greets you or the door code works. "In other words, nothing went wrong, and you give a five-star."

Plenty of engineering roadmaps define success the same way: the release shipped, incidents stayed flat, nobody complained. They also describe the moment when nothing went wrong, which is easy to confuse with the moment a customer's situation got better.

Chesky's answer is the eleven-star exercise. Take one moment, like arriving at a stay, and keep raising the bar past reason. Six stars is your favorite wine and a handwritten card. Seven is a car waiting at the airport and a surfboard, because they know you surf. By ten, in his telling, Elon Musk takes you to space. The absurd end is a vantage point, and he is explicit about why it matters: "go beyond the edge of reality and work backwards." Push all the way to ten, past the parade in your honor, and six or seven stars no longer looks crazy.

The second idea I keep returning to is less playful. Technical leaders need business acumen more than they used to. Knowing how to build something should come with knowing who benefits, what changes for them, and why the work deserves the investment. Chesky gets to a version of this through industrial design, which he studied before Airbnb: in that field, he said, "a design is only successful if it sells." His example: an architect can win awards for an office building that never gets leased. A product nobody buys has failed, however beautiful.

At first these ideas seem to pull in opposite directions. One asks you to imagine past what is possible. The other asks you to justify the spend. I read them as two halves of one exercise, and what separates them is timing.

When the business case arrives

Consider what happens when the business case arrives first. A team starts from the budget, the quarter, the current architecture and the headcount, and asks what experience fits inside them. The answer is almost always five stars. The plan describes what the team already knows how to deliver, and the customer gets the version where nothing went wrong. Nobody chose mediocrity. The spreadsheet chose it before anyone had pictured an alternative.

When the business case never arrives, the team falls for the parade and builds the demo that anticipates everything, the onboarding that feels like magic in a pitch and quietly costs a person's time for every new account. That is the expensive fantasy.

The useful detail comes earlier in the same conversation, where Chesky describes starting something new. Make the problem as small as possible, he says. Inside that small problem: "do things you've never thought before, do them by hand, make them unscalable, don't worry how much it costs, just prove the model." Product-market fit, in his words, "is a distinct problem from industrialization."

Read together, that gives the exercise a schedule. Go wide on one moment straight away: one customer whose mind you are trying to change, and no ceiling on what you imagine. Bring in the cost once you know which part of the extraordinary version the customer actually feels. Dream wide on one moment, then let the business case decide what comes back. The common failure runs the other way, with a broad scope and a cost ceiling that decides the experience before anyone has imagined one.

Out: dream wide on one momentBack: the business case decides

1. 1 An ordinary moment
2. 2 Five stars
3. 3 Eight stars
4. 4 Eleven stars
5. 5 Back to six or seven

What agents change

This matters more now because trying things got cheaper. When I wrote about smaller teams, the change I described was shrinking teams and giving team leads 60 to 70% of their time hands-on, so they could learn to build with agents by shipping with them. What I took from that period is that once building gets faster, the scarce skill becomes deciding what deserves to be built.

When a working prototype takes an afternoon, the eleven-star exercise stops being a whiteboard game. A team can put a rough seven-star version in front of one person this week. The same speed makes the opposite failure cheaper too. Luca Ferrari, who runs Bending Spoons, told the same podcast that "people in general overestimate the value of R&D," and that "there's a very small number of things that pay off handsomely, and most things are a waste of money." Agents lower the price of each attempt without changing that ratio. A team that ships twice as many features without better judgment ships twice as many of the ones that never pay off.

Ferrari's answer is to start from what customers need, "rather than maybe what your engineers think is cool, or fancy visions that have very little to do with the core problems you're solving." On AI, he said it accelerates quality and efficiency "if used properly, but it doesn't do it by itself." I don't read him as an argument against imagination. He describes his company's model as rethinking each business it buys, forming a vision for its most successful version, and working to close the gap. The vision has to pass through the customer's pain before it gets funded.

That is where business acumen earns its place in the exercise: on the way back. Applied on the way out, it holds the imagination at five stars. Standing at eleven, someone has to ask which part of the impossible version the customer would feel, what a real piece of it would cost to deliver, and what evidence would show it was worth paying for. This is the part of a technical leader's job that agents make more valuable, and it is hard to do from a distance. Chesky's version is blunt: "You don't manage the people, you manage the work." A return trip planned entirely on slides tends to come back at five stars.

Where the exercise breaks

The exercise comes from a consumer marketplace with compressed reviews, told by a founder who says he feels like a designer more than a CEO. It is one leader's creative prompt, and it fits some products badly. In regulated or safety-critical work, some questions have to come first. Consent, privacy, irreversible actions and other people's money protect the customer from the team's imagination, and any schedule that defers them is a bad schedule.

The extreme version can also mislead. Climbing the stars tends to add things: more anticipation, more automation, more surprise. Sometimes the extraordinary version has fewer parts. Chesky credits Hiroki Asai, Apple's former creative director, with teaching him that "simplicity is not removing things. Simplicity is distilling something so fundamentally that you understand its essence." A six-star experience might come from removing three steps rather than adding a concierge.

The concierge carries its own risk. Doing something by hand teaches you what customers value. It says little about whether you can afford to give it to all of them. An interface that feels effortless often hides somebody's labor, a risk somebody else is absorbing, or data the customer never knowingly handed over. A product that already seems to understand every important decision you made raises a consent question before an engineering one. And when the six-star version works for ten people, the business case is still a hypothesis until you observe it at scale.

None of that makes me want to drop the exercise. It makes me want to be honest about what the return trip has to carry: the benefit worth preserving, the bet the business is making, the cost someone will pay, and the smallest test that could prove the whole thing wrong. Alongside this piece I built a small sandbox, Beyond five stars, that walks one hypothetical moment out to eleven stars and back, then lets you try your own.

The question I would leave with any leader is about the next item on their roadmap. Write down what five stars means for it. If the honest answer is that nothing went wrong, you have described the floor. Agents will get many teams to that floor faster than before. Deciding how far above it to go, and paying only for the part customers will feel, still takes someone who understands both the product and the business. Who on your team does that work today, and are they close enough to the work to do it well?