From air mattresses to IPO, the outside world loves founder myths, design faith, and valuation curves.

Lenny Rachitsky tells another story.

In 2012 Airbnb acquired his startup Localmind; he joined as an engineer and became one of the early PMs, spending seven years across supply growth, conversion, trip quality, community, and more. After leaving in 2019 he wrote “What Seven Years at Airbnb Taught Me About Building a Business”—meant to clarify what he had learned, it accidentally became the seed of Lenny’s Newsletter. Fast Company later noted that those “seven things” lit the subscriber flywheel; he now packages product, growth, and career advice into one of Substack’s top business publications.

This is not a celebrity bio, and it does not teach you to copy Airbnb.

What Lenny did was compress scale experience into a work order ordinary teams can run: keep shrinking the problem space—nail the problem, define the ideal end state, then put resources on one line only.

The three steps answer three common questions: What are we actually solving? What would count as truly solved? With so much to do, what comes first—or rather, what do we refuse to do first?

Step one: not work harder on the problem—shrink the problem first

What people copy easily are slogans: strong culture, wild goals, “build something the internet has never seen.” Joe Gebbia once told a designer exactly that; Lenny remembers thinking, what does that even mean? Slogans can inspire; they do not tell you which ticket to kill on Monday morning.

In his seven-year write-up Lenny is blunt: aligning on the problem statement is the single most important step in solving anything. Vague problems let simple projects spin for weeks; crisp problems let hard projects move.

What ordinary teams can copy is not Airbnb’s one-pager format. It is admitting that most fake diligence comes from problems that are too big. “We need growth” and “we need quality” sound right and stay unexecutable—every direction gets a little headcount, so everything is on fire and nothing compounds.

When he took over supply growth, a small team was smeared across a long funnel: local wins, no momentum. Trip quality looked the same. Early Airbnb’s real edge was not that every team tried hard; it was that they kept compressing “we need to grow” into “which concrete problem does this quarter own?”—supply split into referrals, organic top-of-funnel, performance marketing; quality spent a quarter on one lever (host response rate, review rate) and doubled down when a big opportunity showed.

Shrinking the problem does not yet tell you how to win.

It only decides you stop pretending every funnel stage matters equally. Next: where do you draw the finish line?

Step two: don’t optimize inside the status quo—define the ideal first

Once the problem is nailed, the easy mistake is to start immediately: polish buttons, tweak copy, chase 2% A/Bs on the current flow.

The Airbnb habit Lenny describes is closer to Amazon’s working backward: imagine the perfect experience, then reverse-engineer the gaps. The Snow White storyboards treated a trip as a story with a beginning, middle, and end, marking emotional beats—finding strategic gaps from the ideal journey, not optimization items from a status-quo checklist.

The hard case is Instant Book. Booking once had many steps and a wait for host approval; Instant Book was only about 5% of bookings. The team did not spend months micro-optimizing each funnel ring. They stepped back and asked:

If we refuse today’s constraints, what should a perfect booking experience be?

The answer was almost obvious—guests book a home instantly, no idle wait.
“Truly solved” became a step-function, not a smoother version of waiting for approval.

At first it felt impossible: convincing hosts to open Instant Book was hard. Only after the long-term end state was clear did resources earn the right to pile on: sketch the ideal flow on paper, draft a sample announcement post as if it were real, split gaps into “can” and “want,” and when people feared instant booking would hurt quality, check the data fast. Over a few years the marketplace flipped so that the vast majority of bookings became instant.

Step one and step two lock here:

Nail what you are solving;
then refuse to let the current system define the destination.

Once the ideal is set, resistance appears everywhere—hosts won’t open it, internals fear quality, engineering is heavy. What decides success is no longer the idea itself, but where resources concentrate and which paths you publicly refuse.

Step three: once the end state is set, cut the other roads

Focus here is not a freestanding slogan. It is the consequence of the first two steps.

If this quarter’s real problem is host response rate, the team cannot also own search, payments, recommendations, and retention—the problem already shrank; spreading out voids step one.
If the ideal is “nearly any home can be booked instantly,” resources must pile into why hosts won’t turn Instant Book on—not into button-color tests on the old funnel—the end state already moved; polishing the old path voids step two.

Lenny wrote about dedicated squads, clear mandates, cross-functional teams that can move alone; ideally one or two goals with fast feedback. Org design itself is a product—wrong structure, and individual effort never compounds. On the product side, some of the biggest guest conversion gains he saw came from making users think about one fewer thing—open listings in new tabs, longer sessions, strip links from payments. Less distraction inside the company and less distraction for the user are the same cut.

The racecar growth framework in his later writing extends the same logic: long-term growth rides a few self-sustaining engines; early on, don’t bet all engines at once. Until the primary engine is chosen, spraying nitro everywhere only makes noise.

Step three is concrete: after problem and end state are written down, publish what you will not do this quarter—no headcount across the whole funnel, no token ownership for every direction.

Nail the problem → define the ideal → concentrate resources.
Or, more like an essay: first decide what to solve, then how far “solved” must go, then what not to do.

What to take away is not three tips—it is shrinking the problem space

After Airbnb, Lenny did not keep influence with internal gossip. He kept it by writing an executable order. That a newsletter could get this large shows the market was hungry not for another Airbnb legend, but for sentences that change Monday’s calendar.

What he carried out of Airbnb was not three parallel tips. It was a method for shrinking the problem space.

Shrink the problem first, and you know what to solve;
pull the end state farther out, and you know what “solved” must mean;
pull resources back in, and you might actually get there.

Ordinary teams usually do the reverse: ship features first, then optimize forever, then sprinkle people on every direction. It looks like progress. It never answers—what is the only thing this stage needs to win?

You cannot copy Airbnb’s scale.

You can copy, starting tomorrow, the order: shrink the problem → define the end state → concentrate resources.