Airbnb's contrary take on Product Management
Debunking the actual truth of what Brian Chesky said and meant to say in his recent talk at CONFIG, Figma's annual conference. Also, understanding how product management role is evolving.
👋Hi, this is Bandan with a bonus, once-a-month free issue of the Productify Newsletter. As a paid subscriber, you also get access to monthly premium case studies and product courses such as: How Spotify pivoted its Podcast Strategy | How OpenAI makes money? |How Duolingo gets your addicted ,|How Facebook does Product Management | All Product Strategy Frameworks you need | Part 1 of the course on Platform Product Management and all other locked posts. And one more thing, you also get access to exclusive deep-dive product guides, templates and 1:1 access to Bandan. To get the full experience, consider upgrading:
Brian Chesky, Co-Founder and CEO at Airbnb, spoke at CONFIG (Figma’s annual conference) and questioned the traditional product management function, revisited the role of designers in building great products, and spoke a lot about how Apple builds products.
But he did not stop here. The whole talk has comments from him on A/B testing, leadership involvement in building products and role of product marketing. Lot of meat there.
To me, this talk from Brian Chesky was a defining moment about how product roles are evolving today in the big-tech and what’s needed to build amazing products. It reminded me a bit about how Steve Jobs spoke about storytelling, design and user experience. And no doubt, Brian Chesky is taking some cues from him.
Let us dive into top 5 spicy takeaways from Brian’s talk (Relevant for mid-stage and senior PMs). In the second half of this newsletter, I also introduce the concept of ‘Cost of Validation’ (Relevant for product and business leaders, CXOs and Founders). If you have 15 mins this weekend/week - give whole of it a good read.
Going forward, Productify would be sharing (all free) product PDFs, templates and frameworks on its LinkedIn channel. Go to below link and give the page a follow:
Few big product changes matter more than many many small ones
“…we [did] this giant exercise and we put every single thing on one roadmap. Then I said ‘We can only do 10% of the things on the roadmap.’ That was a reckoning. So I said ‘We’re only going to do a few really big things.’ We took the very best people [and] we put them all on a few projects.”
This comment from Brian Chesky reminded me of the talk from Jared Spool (you can search on YouTube) where he talks about organizations ending up becoming feature factories. Each release has more features than previous release. All product teams want to get something done and each team has goals and roadmaps that cascade to one upper level until the whole organisation has one giant roadmap.
Jared’s talk further mentionS how such organizations get disrupted by others. There will come another startup that will do only small % of such features (relevant to customer’s needs) and release a new product which is easier to manage, more friendly for customers and break the incumbent.
Apple also was a big propagator of this idea. Apple even till date publicizes and story-tells all the big stuff they did in last one year rather than all the small fixes. Brian took a cue from Apple’s books and decided to keep focus on doing big things, rather than many small things. (Brian’s message above says he cutoff 90% the roadmap).
Hiring more people doesn’t always mean faster product outcomes
The bottom line any product leader should track is how much does the product change (in-line with metrics) and evolve per unit of time and per unit of people. And if you hire more people, does the amount of product change in line with metrics would faster or slower?
A default assumption most product leaders and business leaders assume is that if they add more product people (PMs, Engineers and Designers), the better and faster the product would evolve. But this assumption and curtain of hallucination breaks apart pretty soon when it starts taking even more time to roll out product changes.
The thing with hiring more people is that each of them (as highly inspired individuals) would find new business opportunities and new customer problems, which leads to more initiatives and projects. I call this a ‘internal pipeline of opportunities’ that individuals want to push for their own success.
But then the delivery unit (being loosely being referred here as set of individuals involved in executing product changes, projects and initiatives) suffers from prioritization traffic jam. Nothing moves because everything moves. But not much gets out into the market.
Brian Chesky referred to concept of inflated organizations in his talk at CONGIF:
“ and the thing I started noticing is the more people we added, the more projects we pursued, the less our app changed and the more the costs went up”
Top-down product leadership culture is good for faster decision making
“I started reviewing all the work. I reviewed the work every week, every two weeks, every four weeks. Before, people thought that was meddling. And I said ‘You know what, screw it. We’re going to review everything, I’m going to be the chief editor, and I didn’t push decision-making down. I decided to pull decision-making in like an orchestra conductor and what we created was a shared conscious of the top 30 to 40 people at the company , and it was like one neural network—one brain.”
Apple pioneered the expert-led culture where experts and leaders would ensure they played a role in every product review and while they would leave a lot to the team to figure out, but they would not let any sub-par experience slip through.
This top-down product building culture works in organizations where leaders have been in the company and industry for long, have high bar when it comes to product and customer experience and can reduce time it takes for teams to make decisions by offering their knowledge and wisdom. This is typically high-agency leadership.
Brian clearly showed his high-agency leadership when he said:
“We can’t do new things unless we have permission. And we don’t have permission to work on new things until people love our core service. If they’re complaining on social media and they’re calling customer service, they don’t love our core service so we need to get our house in order first.”
Note that this culture is not opposite of ‘empowered’ and ‘autonomous’ teams culture but it supports that culture by reducing the time it takes to understand and validate the market (lower cost of validation is a concept we introduce in the second section of today’s newsletter).
Product Managers should stop being feature factory workers
Social media went on its typical shit-sells storm when it started concluding that Airbnb is getting rid of Product Management whereas the reality is that Brian wants Product Managers to have more stake in Go-To-Market and hence wants Product Management to be combined with a strong marketing and storytelling mindset, calling it a Product Marketing role, typical of how Apple works.
There is a lesson here for Product Managers and Product Leaders. If you continue to focus your role on releasing features, your role should soon become obsolete as no scaled organisation can afford a feature factory where PMs celebrate launches but not the success in the market.
Picture this:
PM 1 celebrates launch of the feature, sends out an email and also shares the team effort to release that feature. PM 2 not only launches the product/feature (knows that is not success) but eventually celebrates when adoption in the market by how many customers adopted the feature, and retention. PM2 is what modern organizations will look for. This in no way means that launch success should not be celebrated, there is lot of blood and sweat in that, but it doesn’t make the organisation successful.
“A lot of products fail because they’re not well-marketed. If you ship a feature and no-one knows, did it really matter? So a lot of times people give up on features too soon. They ship something, the data says it doesn’t work, they kill the feature. Well, did you tell people about it? Do they know about it?”
Finally the lesson here is not that you or your organisation needs to introduce Product Marketing Roles to replace Product Manager roles. Infact, my take is that Product Manager is responsible for success of all metrics across the product lifecycle (including adoption, retention, monetisation) and marketing/positioning is part of natural PM focus.
So as a product leader, you can either build that mindset in your PMs or change their titles to reflect it (as Brian Chesky did)
Design-Led Culture of building products for the win
…Actually, we got rid of the classic product management function. Apple didn’t have it either. We combined product management with product marketing and we said that you can’t develop products unless you know how to talk about the products. We made the team much smaller [and] we elevated design. […] We thought of designers very much as architects.”
“There’s a whole new generation of designers ….They’re not just going to be told what to do by product managers; they’re going to be helping drive the product. ..
This is a very Apple way of building products, where Design is at the center of product decision making. Before we even talk about what Brian Chesky meant by this new design-led focus, you could consider reading our newsletter edition that has practical ways product and business leaders can elevate Designers in their organization, Read Here: Bridging the design and business gap (w/Erin Young, Founder at SlideUX)
For such a culture to be possible, Designers need to be elevated as a natural need of the organization rather than leadership spending time on justifying the need for designers. Also, not all organizations may benefit from this design-led approach but as organizations evolve and their core offerings are great product fit, they can start thinking about design decisions more importantly than product decisions.
The Squeeze
Overall if you look at Brian Chesky’s comments, you will find that he is hinting at organizational direction which favors market-mindset (through product marketing role) and design-first thinking (by elevating designers).
While you could naively say this is just Airbnb going the Apple way.
But you could also find the biggest insight of this decade:
that the Designer + Product-marketing duo is the new force to reckon with compared to traditional Product Manager-Engineer duo when you want to roll out amazing products to your customers.
And one more thing in today’s issue:
Introducing the Cost of Validation
"𝐂𝐨𝐬𝐭 𝐨𝐟 𝐯𝐚𝐥𝐢𝐝𝐚𝐭𝐢𝐨𝐧" 𝐨𝐫 𝐂𝐨𝐕 𝐜𝐚𝐧 𝐫𝐞𝐚𝐥𝐥𝐲 𝐜𝐡𝐚𝐧𝐠𝐞 𝐡𝐨𝐰 𝐩𝐫𝐨𝐝𝐮𝐜𝐭 𝐚𝐧𝐝 𝐛𝐮𝐬𝐢𝐧𝐞𝐬𝐬 𝐛𝐮𝐢𝐥𝐝𝐞𝐫𝐬 𝐯𝐢𝐞𝐰 𝐭𝐡𝐞 𝐦𝐚𝐫𝐤𝐞𝐭. 𝐓𝐡𝐢𝐬 𝐢𝐬 𝐡𝐨𝐰 𝐨𝐧𝐞 𝐜𝐚𝐧 𝐚𝐩𝐩𝐥𝐲 𝐢𝐭:
The fundamental definition of CoV is that it is the cost to team (or organisation) for predicting the market right. The longer it takes for a team to reach the point of product-market fit (loosely) or feature-market fit, the higher is CoV. Along this spectrum, there are two types of companies on extreme ends:
Type 1: Cost of Validation is Upfront
When building products, some organizations spend majority of their time, money and resources upfront to validate their product ideas. This could mean going through all steps of customer research (qual and quant), prototyping, user testing and iterations before deciding to launch the product or a feature. From a CoV perspective, 80% is spent upfront and 20% in market.
Type 2: Cost of Validation is Later
While there are other types of organizations that launch product or features (to a limited audience with mitigated downside impact) without much upfront research and prototyping but test out multiple variants in production or live environment to know which one works and needs to be scaled. The ones that don't work are shut down without customer impact. From a CoV perspective, 20% is spent upfront and 80% in market through A/B tests for example.
There could be organizations in between as well, but the point is "Cost of Validation" is spread across a time horizon until the organization 'learns the market'. A well running product organization would overtime lower cost of validation as they start knowing their customers and their choices (+willingness to pay) better. This is not reflected easily in the income statement, but keeping a track of this can make the organization more efficient.
Here are all the reasons CoV could go up, and business leaders need to catch these signals:
1. Product teams do not understand their target customers
2. Product teams do not understand willingness to pay of their customers
3. Product teams do not learn from feedback and iterate fast enough
4. All product evaluations start with deep product exploration work. But sometimes a market is already well known, or there is an expert in organization who’s been in the battle field - then invest less in upfront validation (and get away with a lower CoV)
5. Product teams take time to react to market changes (over long time customer preferences change)
6. Lack of product iteration and experimentation infrastructure/missing data and dashboards to take right decisions faster
𝐇𝐨𝐰 𝐝𝐨 𝐲𝐨𝐮 𝐟𝐞𝐞𝐥 𝐚𝐛𝐨𝐮𝐭 𝐂𝐨𝐬𝐭 𝐨𝐟 𝐕𝐚𝐥𝐢𝐝𝐚𝐭𝐢𝐨𝐧 𝐢𝐧 𝐩𝐫𝐨𝐝𝐮𝐜𝐭?
A) 80% upfront 20% Later (Learn mostly in research) or
B) 20% Upfront 80% Later (Learn mostly in the market)
C) Other ways
References for Airbnb CEO Brian Chesky’s talk:
Watch full video (CONFIG Conference Link)
Twitter thread from Max Wendkos, Design Director at Meta
Want to tell your product story? or do you want to promote your brand on Productify, simply reach out to ProductifyLabs@gmail.com and get details.
As for the 80/20 vs 20/80. I think its the same thing - its whatever experiment can get you the evidence you need to be confident enough to invest further (or not) while trying to minimize the resources needed to get that evidence. Interested to hear what others think. Thanks for the great article!
Thank you for sharing this type of content. I think this mindset is also very aligned with Product Led organizations and I do think that if the role does not evolve it will become obsolete. Part of the problem is companies not understanding the PM role and fomenting only for them to be writing US or managing the roadmap of their feature factory.