I am finally catching up on the big “Airbnb canceled PMs” debate of 2023, and like most online arguments the whole thing seems pretty silly to me. First, here’s a good overview from Aatir Abdul Rauf, in which he publishes the full quote from CEO Brian Chesky:

“…The designers are equal to product managers. Actually, we got rid of the classic product management function. Apple didn’t have it either.

5-second applause

(smiling) Let’s be careful. Hold on.

We have product marketers. We combined product management with product marketing and we said you can’t develop products unless you know how to talk about the products. We made the team much smaller and we elevated design.”

Aatir does a great job of putting the quote in context of the entire talk, so it’s well worth reading. The TL;DR is this: “Airbnb didn’t kill PM. They relabeled it and consolidated their team roles.” That seems like a completely reasonable organizational change to make within the context Airbnb is in, and considering the thought they clearly put into that decision. It definitely won’t work for every organization, but it’s also clearly not some kind of thought leadership mandate that they want to force on the entire industry.

I say good for Airbnb for making a decision that aligns their organizational design with the way they believe they can design and develop products most effectively. One last plug for Aatir’s post: he does a great job explaining the Product Marketing function, and what product managers can learn from it.

Now, the real topic I want to get to with this post is this idea of merging PM into other roles. That concept has been around as long as the profession itself. As with so much in product, it’s not inherently good or bad, it’s about the context of the change. Here’s another example (that I happen to agree with). In Melissa Perri’s response to the controversy she made a slightly different case that the PM role will start to merge with the GM role:

Product Management has always firmly sat between business, tech, and the user/customer. In SAAS companies, the Product Management role has always been about figuring out how to grow the business by solving customer problems with the right software. In other companies that are not software-native, you saw this same act being done by GMs of the business, but just with the tools available to drive the business at the time - sales, marketing, and human operations. What does a GM look like in a product-led business? Someone overseeing the teams that build the things you sell.

As more and more companies become predominately software companies, I believe the Product Management role and GM roles are going to merge. You won’t be a great GM unless you deeply understand software, along with understanding your domain. Product Management was never purely about “tech” and if companies were treating it so, of course, they didn’t see the value of the role.

The point is that organizations will always need someone who understands the product, customers, technology, and the broader market—and guides conversations towards what that all means for priorities and what to work on to help the business grow. In the current SaaS environment we’ve settled on that role being filled by product managers. That’s great, but it might not always be so, and that’s ok too. It doesn’t mean we’ll lose our jobs. It just means we’ll keep evolving.

Ask Questions, Repeat The Hard Parts, and Listen →

Michael Lopp’s latest is an excellent reminder of what good leadership is all about:

Earlier in this piece, I wrote I was disappointed when you asked me to decide. I’m not disappointed in you; I’m disappointed with myself. See, my primary job as your leader is to give you the skills and experience I’ve gained over the years. If I cannot guide you toward making the decision, I’m reminded I’ve not yet achieved my primary goal in our professional relationship.

My job is to teach you not to need me.

The Creators of Disney’s New Platformer Explain the Hard Lessons of Making Games for Kids →

Patrick Klepek writes about making games for kids, but there are some great generalizable product lessons throughout. Like this reminder not to drift toward the “average” user:

“We have this phrase internally, we say ‘don’t make a rosé,” said Grand-Scrutton. “And it’s because one of my friends in the industry, one of my mentors, he said this phrase to me, and he said that if you go to a restaurant and you’ve got someone that loves red wine, or someone loves white wine, you don’t give them a rose because no one’s happy. You gave them an awesome red or an awesome white. So we say that internally, when we are riding this line of only half doing something, we say ‘it’s too rosé.’ Rosé is a perfectly fine wine choice, but we felt we were rosé-ing it.”

Failure →

Mike Fisher writes about a really interesting tool to get teams comfortable with taking risks, called the Failure Workshop:

One strategy to familiarize team members with failure is to conduct a Failure Workshop. Think of it as a tabletop exercise on failure in a safe environment. The workshop’s objective is to “stay in the failure” while fostering a supportive space for peer interaction. This is similar to a pre-mortem but it keeps the participants thinking about possible failure scenarios instead of brainstorming solutions. 

Reality has a surprising amount of detail →

I missed this 2017 piece by John Salvatier, and it’s so good. He talks about how easy it is to get intellectually stuck in our ways, and how to break out of that:

The direction for improvement is clear: seek detail you would not normally notice about the world. When you go for a walk, notice the unexpected detail in a flower or what the seams in the road imply about how the road was built. When you talk to someone who is smart but just seems so wrong, figure out what details seem important to them and why. In your work, notice how that meeting actually wouldn’t have accomplished much if Sarah hadn’t pointed out that one thing. As you learn, notice which details actually change how you think. If you wish to not get stuck, seek to perceive what you have not yet perceived.

Fitness Technology and the Templated Body →

In today’s example of “technology is not neutral” Audrey Watters talks about how depressing fitness tracking can be:

Fitness technologies shape how we think about fitness; they shape how we think about our movement — why we move, how we move, and so on. We covet the gadgets that promise to give us more and more data and deeper and better insights about ourselves, supposedly to learn more about ourselves. And yet, we are simultaneously un-learning to trust ourselves (or trust professionals — our teachers and coaches), waiting for the “nudge” and the badge to compel us move.

Related, also see Lukas Mathis’s Streak Redemption about what happens when you break a streak in one of these apps:

Conversely, losing a streak can be so demoralizing that it can be difficult to start from scratch, and get going again.

The Slow Productivity of John Wick →

You’re going to have to trust me that this is actually really good:

John Wick may be shallow entertainment, but the story of its success highlights some deep lessons about what the rest of us might be missing in our pursuit of a job well done.

A Practical Guide to Executive Presence →

Some great advice here:

If you take nothing else away from this post, it’s this first point: Don’t freak out. Visibly losing control of yourself is one of the most damaging ways that leaders self-sabotage. Seeing the person who’s supposed to be in charge lose control under pressure is confidence-destroying and can take a very long time to recover from.

Also:

You only sound as smart as the dumbest thing that comes out of your mouth. The more you say, the more dumb stuff that you have the chance to say. Consciously try to have a timer going in your head that tells you to wrap it up after you’ve been talking for ~30 seconds, unless there’s a specific reason that you need to speak for longer (e.g. a presentation).