This Week #13: Balancing outcome-thinking with design and technical requirements ⚖️

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.

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 example, at Airbnb we had a team oriented around the outcome of getting hosts more bookings, NOT a team owning the “host products” that then figured out how to drive bookings. Similarly, we had a team focused on the outcome of improving trip quality, NOT a team owning the “reviews product” that then figured out how to drive up quality.

Though this wasn’t always the case (as you correctly noted in your question), I saw a VERY strong correlation between teams that drove significant impact and teams that were outcome-oriented.

Some ways to tell if your company is outcome-oriented or product-oriented:

  1. Do you organize teams around a goal, or around product/surface areas?

  2. Are teams encouraged to work on any part of the product to achieve their goals, or are they pushed to stay within their lanes?

  3. Do teams build a strategy and roadmap rooted in business goal, or rooted in making the products/features they own more successful?

In an outcome-oriented model, you still need to assign ownership of product areas to teams (for bug triaging if nothing else), and you need to create processes for teams to help each other out when they’re working in unfamiliar code. But both of these become secondary to working backward from the outcome — give a team an outcome to achieve (e.g. increase host supply), and let that team figure out what it’ll take to achieve it (e.g. make changes on the home page, emails, and dashboards).

Jonathan Golden, Airbnb’s first PM, has more to say about Airbnb’s approach to this in his excellent First Round Review piece, and this piece I co-authored has more detailed advice for how to execute an outcome-oriented structure.

To answer your question about how we balanced this outcome-thinking with engineering and design needs (which often don’t directly drive that outcome), it’s simple — extend your outcome thinking further out into the future. How much would this work benefit your outcome (e.g. growth, quality, retention) 1+ years out? What happens if you don’t do it? What are the chances of it being successful?

At Airbnb, we had to decide at one point whether to invest significant resources into migrating from a monolith codebase into a handful of stand-alone services (i.e. SOA). To do this, we laid out scenarios of what would happen if they did it now, did some of it now, or did none of it now, and looked at:

  1. How long do we anticipate this work taking, best case and worst case

  2. What resources would it take up from the team

  3. What impact would it have on our immediate goals and strategy

  4. What impact would it have on our long-term goals and strategy

  5. What risks would it introduce, or take away

Depending on the scope and impact, you either make a decision within your team and move forward, or if it significantly hurts short-term goals you surface the options (along with your recommendation) to the higher-ups for buy-in. In the end, it always comes back to the ROI, and what would best help you achieve your short-term and long-term outcomes. Just know that it’s never an easy call — that’s normal.

For more food for thought, check out this read that I just came across this week about diversifying your team’s time investments based on the company stage.

Good luck!

Inspirations for the week ahead 🧠

  1. ReadA Data-Driven Guide to Effective Personal Climate Action by Erika Reinhardt — “This post details the most effective individual changes you can make to fight climate change in your personal life” 🌎

  2. WatchGoogle Maps Hacks — Watch how this guy creates a virtual traffic jam in Google Maps with a pile of phones, a cart, and a stroll 🚶‍♂️🛒📱

  3. SubscribeAlex Danco's Newsletter — Every issue makes me smarter about business and tech. Start with his latest edition 🤯

That’s it for this week!

Photo credits: Airbnb Is Inc.'s 2014 Company of the Year

If you’re finding this newsletter valuable, consider sharing it with friends (or subscribing if you aren’t already)


Lenny 👋