By Lenny Rachitsky · lennysnewsletter.com · @lennysan on X · YouTube · LinkedIn
Lenny Rachitsky answers a reader question about how Airbnb balanced outcome-oriented thinking with design and engineering requirements that don't directly drive a target metric. He argues that outcome-oriented structures, where teams own goals rather than product surfaces, correlated strongly with impact at Airbnb. To reconcile this with necessary foundational work, he suggests extending the outcome horizon further out, asking what the work contributes 1+ years ahead, what happens if it's skipped, and how likely success is. He illustrates this with the monolith-to-services migration decision, which weighed scenarios across timing, resources, short- and long-term impact, and risk. The key message is that such calls are ROI judgments, escalated to leadership when they significantly hurt near-term goals.
01Key takeaways
- Organize teams around business outcomes such as host supply or retention rather than around owned product surfaces.
- Ask whether each product area still needs a clear owner for triage, and build processes for cross-team help in unfamiliar code.
- Justify foundational design or technical work by projecting its impact 1+ years ahead, not just against this quarter's metrics.
- Model multiple scenarios (do it now, partially, or not at all) with best and worst-case timelines, resource costs, and risks.
- Decide within the team for small-scope tradeoffs, but escalate with a recommendation when a choice significantly hurts short-term goals.
- Expect these tradeoff decisions to be hard; difficulty is normal and the decision ultimately comes down to ROI.
02Key sections
- Outcome-oriented vs. product-oriented teams
- Airbnb organized many teams around outcomes like host bookings or trip quality rather than owning product surfaces. Lenny notes a strong correlation between outcome-oriented teams and significant impact.
- How to tell which model your company uses
- Three diagnostic questions check whether teams are organized around goals or surfaces, whether they can work across the product, and whether their roadmaps are rooted in business goals.
- Ownership still matters in outcome models
- Product areas still need owners for bug triage, and teams need processes to help each other in unfamiliar code, but these are secondary to working backward from the outcome.
- Extending the outcome horizon
- To justify design and technical work that doesn't move near-term metrics, evaluate its benefit one or more years out, the cost of skipping it, and its chance of success.
- The monolith-to-SOA decision
- Airbnb modeled do-it-now, do-some-now, and do-none-now scenarios across duration, resources, short- and long-term impact, and risk, escalating to leadership when short-term goals were significantly hurt.
03From the post
“Hello and welcome to another edition of my weekly newsletter! Each week, I’ll tackle reader questions (keeping your name and company anonymous) about building product, driving growth, and anything else that’s stressing you out at the office. Send me your questions (just reply to this email or DM me) and in return I’ll give you free actionable real-talk advice 🤝 If you’re finding this newsletter valuable, consider sharing it with friends 🤜🤛 Q: How did Airbnb balance outcome-thinking with design and technical requirements? I know there is probably no “all teams operated this way“ answer, but I would love to hear how the company as a whole managed this. [](https://substackcdn.com/image/fetch/$s!0leJ!,fauto,qauto:good,flprogressive:steep/https%3A%2F%2Fbucketeer-e05bbc84-baa3-437e-9518-adb32be77984.s3.amazonaws.com%2Fpublic%2Fimages%2F7ea8d5c6-8fe6-45a3-a7d1-f7a20c0596931940x900.jpeg) I’d venture to say that outcome-thinking was one of the most important ingredients in Airbnb’s success. Really. From the day I joined until the day I left seven years later, the majority of Airbnb teams thought in the outcomes they wanted to achieve, not in features they wanted to build or products we wanted to launch. And just as importantly, prioritized work and structured the teams around these outcomes. For…”
04Frameworks mentioned
Summary and takeaways written by PM Atlas; quotes are short excerpts. © the original author.