It’s been just over a month since Brian Chesky made headlines in the digital product development world by announcing “we got rid of the classic product management function” at a Figma conference. This was in reference to layoffs made back in 2020, but the manner in which he told the story (and the setting) may be what attracted all the attention. He significantly reduced the number of product managers at AirBnb and moved them to the marketing department as product marketers.
Quite a few posts and follow-up articles have been written fueling an intense debate about what the move means for product management as a profession. Before we get into what we can glean from all this, let’s recap what Chesky was seeing prior to making these moves:
“We had 10 different divisions, they had like 10 different subdivisions, we were very much run by product managers. We had a plethora of A-B experiments. The thing I started noticing was the more people we added, the more projects we pursued, the less our app changed, and the more our costs went up. And I didn’t know what to do.”
He also cites having many different disconnected roadmaps for a connected experience.
“I told every single leader in the company to show me your roadmaps. They couldn’t even figure out their roadmaps because everyone had a sub-roadmap and sub-teams. And those teams had roadmaps.”
What’s important to call out is that this was all happening as they were preparing to go public, and then Covid hit:
“When you’re our size and you lose 80% of your business in 8 weeks, it’s like an 18-wheeler going 80 miles an hour and then slamming on the brakes. Nothing good happens.”
This was like a war-time decision. AirBnb needed to make some immediate changes. The changes he ultimately made not only included the changes to product management and a general reduction in their workforce, but he also:
- Combined the disparate roadmaps into a single roadmap.
- Cut back on 90% of the projects on the roadmap to focus on a few with only the best people.
- Refocused A-B testing to be done only when there was a clear hypothesis first.
- Elevated the role of design to be on equal standing to other roles (like PM) and more like architects.
- And last but definitely not least, he took over product decision-making. He called this being the “Chief Editor,” and he describes it as “I decided to pull decision making [related to what they ship] in like an orchestra conductor.” While he may not have used the title, he was taking on the work of a Head of Product.
Were these changes ones that should cause us to worry about the outlook of product management as a role?
Not at all – and point in fact, the number of PM roles have continued to grow in the last 2 years since these moves were made, according to Glassdoor.
Chesky made a strategic decision to restructure his company to be more lean and connected in a time of immense pressure and dramatically reduced revenue. However, as product leaders, we can use this as an opportunity to reflect and learn. True, the company was in a tough spot, but that in and of itself is not enough for the CEO of a company with over 6,000 employees to take on the Head of Product role himself.
One Way to Interpret This
Do we know exactly what was going through Chesky’s head. No. But we can make some assumptions given what he said and did.
Clearly Chesky was questioning the product management-run operating model at AirBnb prior to Covid, as he moved away from this model when the going got rough.
Some of you have probably been witness to companies struggling with how to define and value product management as a function. This is especially true when the company leaders don’t have a lot of direct experience with PM or a clear understanding of the role. But that’s not what’s at issue here. Chesky still valued the “work” of product management such as understanding customers and their problems, driving product strategy, prioritization, etc.
So what might we glean from his statements and actions?
- There was a perceived lack of and end-to-end view of the product strategy
- There was a lack of clear focus
- There was a sense that not all the right perspectives were at the decision-making table
For product management, the value of the function is much less tangible. We don’t code or design. We facilitate the “building” of products without doing any of the actual building ourselves. Our value is the direction we set, the tradeoffs we make, and the output of the experience for which we orchestrate the building. And it seems that some of this was missing for Chesky.
…And we can learn from this.
What Can We Do as PM Leaders?
It’s critical for product management teams to step back and make sure there is a clear line of site between the day-to-day work to the broader business outcomes at every level. Leadership teams lose confidence in product management if they can’t see this connection and don’t understand what’s most important. Making it difficult to make educated tradeoffs when things get tough.
Here are some ways PM leaders can mitigate the challenges Chesky was seeing in the organization at this critical time in history.
- Align the end-to-end product strategy (and roadmap) with strategic goals: Do you have a set of company goals and broad company strategy but no product strategy that focuses the product efforts on how best to achieve the company goals? Develop one. Then tie each roadmap initiative back to that product strategy with clear logic around how each major effort supports that strategy. Everyone in a product management role (at every level) should be able to articulate how their team’s work fits into the strategy and is advancing the company’s agenda.
- Focus on critical few priorities tied to outcomes: Too many initiatives not only becomes hard to manage (even if you’re a large company with a lot of resources), but it makes it difficult to understand what’s most important. Be purposeful on selecting the “critical few” priorities (i.e., “3 to 5, maybe 6, never 7”) …those initiatives that are most impactful in meeting company objectives. Ask each of your product managers at your next 1:1: “What are your critical few.” See what you get. Can you tie each back to the product strategy? Would you agree that they are the most important things they could be working on? Could you explain that connection to another leader if they asked?
- Be open and transparent in decision making: Two things here. One, involve key stakeholders in product strategy decision-making. This isn’t about consensus. It’s about gathering input from stakeholders to ensure your decisions are fully-informed. And two, be transparent in your logic in the decisions you are making. Sharing relevant data, customer insights, and analysis that lead your stakeholders to the same conclusion. Both of these build confidence among your leaders that PM is an effective steward of development investment. If you are seeing skepticism or an overturned decision, chances are your stakeholders (or leaders) don’t understand why you made the decision. And there may be important data your stakeholders have, that you don’t, that is necessary in making the right decisions for the company. Either way, this a great opportunity for you to gather additional stakeholder inputs to ensure you are fully informed and to be more transparent around your logic you’ve built.
- Showcase successes and lessons learned. Beyond rote progress reporting. Highlight examples of initiatives that make a big impact on the desire business outcomes (showing that connection) and those that don’t and why. This is about sharing how the strategy and prioritization is paying off (or not) in the desired business outcomes. And showing where big learning is happening to explain where pivots need to be made. In other words, close the loop. “We set out to do X in order to achieve Y. Heres where we won and here’s where we lost and why, and here’s what we’re going to do about it (strategy change, roadmap change, backlog change, functional change, etc.) in order to meet our desired business outcomes.” This maintains the connection between the day-to-day and the broader objectives and strategy that most of the organization misses causing potentially unnecessary questioning or distrust.
- A roadmap for a single experience should be clearly connected and rationalized as one roadmap. This is usually a challenge for companies where the development for a full end-to-end experience straddles multiple organizations. Chesky seemed to feel he couldn’t get a clear picture of their product direction given the myriad of nested roadmaps within each division of the company. And while we already talked about the “critical few,” we can also think about roadmap alignment across the different organizations. Ensuring we are connecting and rationalizing our roadmaps across multiple teams to ensure a cohesive experience. Does your roadmap create a clear line of sight from the work you’re planning to the product strategy up to the company strategy? The roadmap is the vehicle to bring your strategy to life.
All of these, when done well, provide the context leadership needs to make informed decisions when times get tough. All of these deliver clarity on what is most critical in meeting the desired business outcomes and understanding of the implications of making any necessary tradeoffs (canceling projects, redirecting investments, etc.) in pivoting and addressing major market changes.
A Few Other Tidbits We Can Take Away
There were a few other things we gleaned from AirBnB’s situation and org changes made. I mention these because they epitomize some of the philosophies espoused in the Product Rebels’ Groundwork program and book.
- Product managers *must* be able to communicate the value of the product effectively. Chesky highlighted this as a must have for the function, so much so that he refocused PM on this as their primary role. Being able to communicate the value of what you’re delivering is table stakes. Releases should be planned around the delivery of benefits and impact, not new features. A good practice is requiring the team to articulate the value/benefits to the customer before any work starts.
- All experiments should be hypothesis-driven. One of the main modules of the Groundwork Method is about identifying the most critical questions for the business and developing hypotheses for each as a way to drive focus around experimentation. Chesky lamented that they had “A-B tests on top of A-B tests,” but they weren’t advancing the experience. He felt that they were using A-B tests as “abdicating responsibility to the users” for decision making. Product managers need to have a point of view, and any experiments should be created around a well-founded hypothesis for which to prove or disprove. Check out our post on the “6 Elements of a Strong Hypothesis” for guidance. It’s a helpful checklist to make sure you’re getting the most out of your experiments.
- Your PMs should be working shoulder to shoulder with their UX partners. Many PMs take the view that they drive the product, and they view their UX partners like an agency with tasks to complete. Of course, the best PMs are design thinkers, but the best performing product teams develop vision and direction through collaboration with their key functional team members, including UX. How does the current relationship with UX work in your organization? Are you getting the best outcomes from that relationship? Are we leveraging the strengths of each function and team member?
So Should We Worry?
Nope! Chesky made his decision to take over product decision-making and “get rid” of the PM role for some simple AND some complex reasons. The simple reason was that he wasn’t seeing a clear way forward and felt the voice of the design function was missing from that direction setting…and he was in a very complex situation that required immediate action.
But we can learn from this. We can learn that without driving focus, collaboration, and transparency in our decision-making, we can lose stakeholder confidence quickly.
Published: August 31, 2023 Author: Steve Cook