Dear friends,
In JC’s Newsletter, I share the articles, documentaries, and books I enjoyed the most in the last week, with some comments on how we relate to them at Alan. I do not endorse all the articles I share, they are up for debate.
I’m doing it because a) I love reading, it is the way that I get most of my ideas, b) I’m already sharing those ideas with my team, and c) I would love to get your perspective on those.
If you are not subscribed yet, it's right here!
If you like it, please share it on social networks!
👉 Airbnb CEO Brian Chesky on taking it back to basics: ‘I can’t make products just for 41-year-old tech founders’ (The Verge)
❓ Why am I sharing this article?
Product, org, & roadmaps:
Blueprinting the full experience
Permission to do new things thanks to exceptional experience in the core thing
Push for intuition but don’t be afraid to explain your thinking, without that intuition are not useful.
Having one roadmap, with release cycles, have our communication a lot more connected to big product releases. They ship stuff twice a year.
How could we connect even more product & marketing?
Having the CEO as an editor that ensures the coherence of one product story
Their org is not bottom up
Product marketing == product management @ Airbnb (like at Nest/Apple)
Is Program Management the equivalent of our crew leads?
Have more product deadlines.
Communicate with authenticity not by being afraid of the risks.
I believe in our designers building software thanks to LLMs
Remote:
Gathering people at least a week per quarter makes sense
Product vision & Permission to do new things:
We basically created a storyboard of the guest journeys and the host journey.
Then we took all 150 product screens on our app and our website, all 72 user policies, some of which are as many as a hundred pages long.
Every interaction with customer service. We actually blueprinted everything.
Then we analyzed millions of phone calls, thousands of social media posts.
We talked to guests and hosts around the world, and we prioritized all the top complaints, and we tried to work them down the list one by one.
➡️ How could we be more radical about looking at member/customer’s complaints?
One of the things Jony and I talked about is we need permission to do new things.
We have permission when people love the core thing.
And I came to the conclusion that we needed to focus much more on our core service.
People were still complaining about pricing, cleaning fees, all sorts of things about Airbnb. And again, it comes from this disease that happens to a lot of founders or this thing that happens where we fall out of love with our core business.
➡️ Is our core thing good enough? To make it better we need to be also always cheaper thanks to verticalization of care.
I think maybe that happened to our core business, and we said, “Before we go on to new things, before we do whatever we’re going to do, we’re going to get back to the core, back to the basics, and really just focus on making this product something that people love.”
“Let’s be systematic about the complaints. Let’s be systematic by how we address the feedback, and let’s tell a story to the community about all the things we’re fixing.”
➡️ I love this
And my hope is that by the end of this year, we’ll have addressed to some extent every single thing people are complaining about. They really do love the service. It feels truly delightful.
Making product decisions:
I try to have qualitative and quantitative information, art and science. I try to balance being in the lab with being in the field. And I try to be as close as I can to decisions as possible. I try to get emotionally invested.
The exercise of having to explain your thinking clarifies your thinking. A lot of people, they feel something, but they can’t explain their thinking. It’s a good indication that their thinking is still cloudy.
➡️ push for intuition but don’t be afraid to explain your thinking, without that intuition are not useful.
Org & Roadmap:
We put the entire company on one road map.
So for most tech companies, every executive has their own swim lanes.
We said, “You have no swim lanes. Everyone works on everything together. Your only swim lane is your function.
➡️ we are now close to one roadmap too.
We’re going to all collaborate.”
I said, “I’m not going to push decision-making down. I’m going to pull decision-making in.”
I’m the chief editor. I’m like an orchestra conductor, and I have to understand enough about each instrument to make sure it creates one sound.
The other thing I said is, “We’re going to connect product and marketing together.”
What if you actually have them collaborate on product? What if marketing, you know, challenges engineering and engineering inspires marketing? They could actually be connected.
➡️ how could we connect even more product & marketing?
We then started doing release cycles, which meant instead of doing this agile, bottoms-up AB testing, shipping continuously every minute of every day... Now we do some of that still. We said 70–80 percent of our product release is going to be done like hardware.
We’re going to ship stuff twice a year.
And the reason we’re going to do that is we’re going to embrace constraints. When you ship stuff at the same time, everyone’s on a deadline.
➡️ having everyone on a deadline.
Then I meet with every single team every week, every two weeks, or every four weeks.
I’m working and editing the work.
I’m making sure it all fits together.
It ladders up to a cohesive product story.
Roles in the org:
And then we have this function called product marketing. It’s actually outbound marketing plus product management in one role.
We don’t have senior product managers at Airbnb.
If you’re a senior product manager, you also have to do outbound marketing.
You’re not allowed to decouple the roles.
We have no pure product marketers who don’t do product management.
First of all, the organization’s decision-making and product generation is not bottom-up, but this is a very important thing: the ideas don’t all come from leadership.
We do believe the best ideas come from anywhere and ideas do flow up the organization, but ideas travel up the organization, but decision-making comes top down, not bottoms up.
We have a really robust program management function at Airbnb. Most companies don’t.
We have a very robust program management function that organizes everything.
That’s not the role of product management.
The role of product management is to work with program management, but their job is to make sure we know what we’re shipping, why we’re shipping it, and that we actually deliver it.
Program management is the people that keep the schedule, not product management.
And because we have a robust program management, what ends up happening is I get a report every Sunday.
Most people get metrics reports. I get program management reports.
Every single project that I’m tracking, a couple dozen projects, have a color code of green, yellow, red, orange, or lime green.
It tells me a color code of like who’s on track, who’s off track. Then I review the schedule. I have a schedule where I’ll either review the work with the teams, with the key leadership every week, every two weeks, every month, every quarter. And this rhythm keeps us really, really on track.
➡️ Is Program Management the equivalent of our crew leads?
And then we can see all the dependencies and everything moves toward these very public launch dates so nothing can ship.
if you want people to work faster, there’s two mechanisms to get people to work faster.
One, you review the work on a cadence.
Two, you have public deadlines. If you give a crazy deadline and then you review the work leading up to the deadline, that allows you to modulate the amount of intensity that people have.
The future of software development:
130 years ago, only probably a few people could use a camera, right? It was a highly technical thing. It was expensive.
Most people take photos now. Anyone in the world can basically use a camera. They’re ubiquitous, they’re on our phones.
I kind of think software development’s going to be like that, that pretty soon, everyone will be able to develop software because software is just a language you have to learn.
Now there’s always going to be development below the stack at the deeply technical level, but a lot of that front-end development is going to be replaced by natural language.
As this happens, so many more people can develop software, and as so many more people can develop software, I think you’re going to see software in everything.
➡️ I believe in our designers building software thanks to LLMs
Community:
But actually Jony Ive said that he spent 30 years building tools. And what he realizes now is that we don’t just need more tools — we need more connections. And I thought that was a really profound thing and. He really helped us think of ourselves — this is a subtle word shift, Nilay — but going from a marketplace to a community because in a marketplace, everything’s a transaction, and in a community, everything should not be a transaction.
➡️ How to build a community
Communication:
I hired these crisis communications professionals, and I had these outside counsels, and they were giving me what seemed like good counsel.
They basically said, “Be careful about admitting fault. Be careful about this. Don’t say that. Do this, do that.”
And every time I got advice and every time I tried to manage to an outcome, I seemed to make the situation worse because I think what people really wanted was authenticity.
They really wanted me to, you know, just speak from the heart.
➡️ Communicate with authenticity not by being afraid of the risks.
Working policies:
Airbnb employees can live and work anywhere.
We decided to design this in-between state where we’re going to gather people at least a week per quarter. Some teams are going to be together much more frequently.
➡️ Gathering people at least a week per quarter makes sense.
👉 Engineering excellence: Rubber Duck channels (Matt Mochary)
❓Why am I sharing this article?
I like this notion of speed for engineering excellence and how it is described.
How can we rubber duck more? Should we also test it during our interview process?
One of the primary tenets of creating excellence in an engineering org is speed.
Speed from idea to prototype.
Speed from getting stuck on a problem to getting help.
Speed from having feedback to give to actually giving that feedback.
Speed from realizing that someone doesn’t meet the talent bar to letting them go (with kindness).
Rubber Ducking is a familiar concept to most engineers.
If you are struggling to solve a problem, it often helps to say it out loud to someone else.
By explaining it, the answer often appears.
So much so that you don’t even need to explain it to another person.
You can simply put a Rubber Duck on your desk and explain the problem to the duck.
Aaron takes this familiar concept and puts in online … actually on Slack.
Each person in the engineering org gets their own “Rubber Duck channel” in Slack.
There, they can write out the engineering problems that they face.
This often leads to the solution. But if it doesn’t, it also allows the more senior engineers to quickly see when another engineer is stuck and offer helpful suggestions.
These channels also allow the whole team to learn from the most senior engineers, to see how they solve problems.
The channels are so effective that Aaron now tests an engineer’s ability to use the channel during the interview process.
Aaron gives the engineer a problem to solve on the spot that he knows the engineer will not have time to solve.
Aaron tells them that, and simply asks them to share their thinking out loud as they tussle with the problem.
Aaron is not looking for a solution, he is simply looking for their willingness to let their struggling thoughts be known by others.
If a new engineer does not use the Rubber Duck channel, Aaron gives them feedback within 24 hours that they need to.
If they continue to not use the channel, or they continue to struggle in the same way even after getting help, Aaron lets them go quickly.
Aaron feels that he knows within 2 weeks whether someone will be a great addition to the team. All that are not, he lets go within days.
👉 Product: What product to build? How to position it? (Matt Mochary)
❓Why am I sharing this article?
Good guide about product research and defining what to build based on the problems of potential customers.
Here is what the Product Development process should be:
1. Talk to lots and lots and lots of people who are potential customers. Ask them, "What are your core problems and frustrations related to … (the area that you are focused on)?"
2. Repeat back to each potential customer what you heard them say, by stating "I think I heard you say …."
a. Then ask, "Is that right?"
3. Keep repeating back until they say "Yes."
4. Write down every customer type and problem. Start to see the trends. Put them in buckets. Example
a. Customers with over 1,000 employees have this pain.
b. Customers in FL have this pain.
c. The Marketing departments have this pain.
5. For each bucket (also called segment), ask.
a. How many such customers are there?
b. How much money do they have to spend on a solution?
c. How good are the current alternative solutions?
6. Pick your beachhead. It should be the segment that has
a. The most customers, with
b. The most money to spend on a solution, and
c. The worst alternative current solutions
7. Now build a product that solves that segment's problem.
It’s already over! Please share JC’s Newsletter with your friends, and subscribe 👇
Let’s talk about this together on LinkedIn or on Twitter. Have a good week!
I love the idea of rubberducking. A great way to sort out a team.
More great ideas from Claire Hughes Johnson- have you read Scaling People yet? If not, here's a great taster- https://youtu.be/GIiaFW874q8?t=196
You’re not being the good version of your tendencies
setting norms for decision making
no undiscussables
9.36 put it in the parking lot
Setting the vocabulary for work
11.35 someone’s got to run the meeting, otherwise anarchy
Who is the decision maker for each item on the agenda
How long will each item take
Vocab red yellow green blue "You’re acting a bit red here"
I stole from Fred Kaufman- I don’t like most books
A check in and a check out
Top of mind personal-remember they’re humans
Check out one word
Skin in the game
structure can matter
people conflate criticizing an idea and criticizing a person
Insufficient conflict