Thoughts on Brian Chesky Interview

Thoughts on Brian Chesky Interview

TL;DR:

This discussion has been most commonly framed as whether product managers are necessary, but I think that's missing the larger context, which is whether or not the company leader wants to empower her product teams, or wants to instead direct them herself (as feature teams). So this is really about the two main leadership styles of empowerment versus command and control. The truth is, with feature teams and command and control leaders making the value and viability decisions, you don't really need product managers.

The Details:

Now that I’ve published the two articles Alternatives to Product Managers and Alternatives to Product Leaders, I wanted to connect the dots for people that are still unclear about my views on the recent Brian Chesky interview.? If you haven’t yet read those two articles, I’d suggest you do, otherwise my comments below will probably not make much sense.

Disclaimers

First, I don’t know Brian, and I’ve never been asked to do an assessment of his organization, so I can only go by what he said (and didn’t say) in the interview.? I have known quite a few product people that worked at Airbnb and have attended sessions I’ve given, so their comments to me also informed my thoughts.?

I will say that I love the fact that Airbnb was founded by three designers, and I think I would very much like Brian personally.? I also think Airbnb provides a truly valuable service, that they try to run an ethical company, and I think they deserve their success.? Finally, I’ve been a shareholder in the company since their IPO.

Realize that Brian went from an entry level industrial designer to a founder and CEO, never having had the opportunity to work at a strong product company, and see how things are done when they’re done well. And it certainly seems like along the way he has learned some very valuable lessons.

Yet he also made some statements that I’ve already seen cause real confusion.? At the end of the interview, Brian said he expected that in a few years, he’ll look back on this interview and that maybe 70% of what he said he would still believe, but that he expects that 30% he will have evolved his thinking.? I was impressed he realized and admitted that, and I think that’s going to prove pretty accurate.? And I think I can guess the 30% he will come to regret.

Influence of Apple

It is very clear that Brian has been heavily influenced by people from Apple, but the two people he cited are both from the design side, which makes sense as Brian is also a designer.? But listening to Brian, it seems clear to me that he has a very incomplete understanding of the relevant dynamics at Apple, and I think this led him to some questionable conclusions.

Confusion about Empowerment

Brian shared that he had tried to “empower his teams” by backing off and letting the product teams step up, but they didn’t respond so he had to move back in, and take over control.??

While Brian may have allowed the product teams to make some decisions, it seems clear from his comments that he did not actually empower his people with what is necessary for them to succeed.??

He did not staff and coach his teams with strong product managers skilled in value and viability.? He did not share with those teams the strategic context of product vision and product strategy.?

Now he didn’t explicitly say this in the interview, but he didn’t say anything to indicate he did, and instead he described the symptoms of what happens when you don’t.

A Feature-Team Company

What Brian described sounded very much like a feature-team company, with all the common symptoms: weak product leaders, product managers that are really program managers, frustrated designers, teams doing optimization work instead of discovery work, to name a few.

He also described an organizational structure with ten GM’s, so it’s very likely those business leaders/stakeholders were the ones actually making the product decisions, and just using the product teams as feature teams to implement the roadmaps.? So it sounds like they were squarely in the stakeholder-driven feature team model.

From what I could see, he had a feature-team company before he took over, and he still has a feature-team company, but now rather than stakeholder-driven it is founder-driver.

Although that’s not to say he has not made progress, as I think he has:

Forward Progress

In terms of the product managers, it sounded to me like he realized these were feature teams (even if he didn’t know to call them that), so he made several changes, many of which I consider good changes:

  • retitled most of the feature-team product managers to program managers
  • realized that junior product people are not so useful?
  • dialed up the investment in product marketing managers?

Organizationally, Brian realized that his 10-business unit structure wasn’t great for a company at this stage.? It’s worth noting that while I’m glad he made this change, he could have made things work much better without changing that structure, if he had been doing what he needed to do as acting head of product. That said, I still would say he made several significant improvements:

  • learned value of doing fewer things well rather than lots of things poorly (focus)
  • learned value of a holistic product vision?
  • moving to rolling product strategy rather than annual business planning?
  • learned the importance of shared strategic context?
  • learned the importance of company alignment “all rowing in the same direction”
  • learned the value of both qualitative and quantitative learning and insights
  • learned that product is more than technology and design, it includes business viability
  • understands the value of storytelling and making sure you have a meaningful, coordinated message for your customers

In terms of management, he also made some significant improvements:

  • removed extra layers of management?
  • made sure managers truly engaged with their people?
  • made sure every manager was an expert in their functional domain - no “pure people managers”?
  • understands that a good manager being in the details is not necessarily micromanagement?

Unintended Consequences

So those were all positive changes, and I would say that overall represents some very real forward progress.?

However, there were also several changes I think he’s going to regret:

The most significant change is his embracing of command and control leadership, and giving up on attempts at empowerment:

  • he has embraced a command and control model of leadership, and the typical enforcement mechanism for command and control, which is a strong program management function.
  • not surprisingly, when moving to command and control and project-based execution, the focus is now on shipping projects (output) rather than solving real problems (outcomes).
  • he is now driving specific projects off a rolling 2 year product roadmap.? Precisely the opposite of what you do when you want to optimize for outcomes.
  • he emphasized the twice a year marketing releases, but if you listened carefully, he did say that you can and should still release continuously, so I’m assuming by this he meant releasing dark in between the marketing releases. While continuous deployment and releasing dark is good, holding things back from your customers for as long as six months would mean he is paying a very large price for this by delaying the ability to learn from the data.? Again, understandable for managing projects and output; but not at all good in terms of achieving outcomes.
  • he is clearly the bottleneck now, especially with the review cycles and the focus on dates.
  • longer term, I am very worried about the impact on innovation, because the major source of innovation are the engineers closest to the actual technology, and the designers closest to the users.? That's precisely why strong product companies strive to push decisions down to the team closest to the relevant technology and customers.? The fact that Brian didn’t even mention engineers is more than a little worrisome.
  • last but not least, I am very concerned about morale and retention of top talent as a consequence of embracing command and control, and the heavy program management that comes along with that. I don't know of strong people that want to work in this model.

Overall

The way I view Brian’s situation is that he’s making progress on his journey to becoming the leader that his company needs.? He has undeniably come a long way from an entry level industrial designer to the CEO and effective head of product for a major public company.? To his credit, he seems to understand that his thinking will very likely evolve.??

I consider some of the moves he’s made recently as solid steps in the right direction, and others, while understandable, are unlikely to generate the results he’s looking for.

It doesn’t take much of a prompt for inexperienced company leaders to revert to command and control (or stay with it).? The most worrisome consequence of Brian’s public statements is that others may follow.? I’m hoping these people both educate themselves about the consequences, and also wait to see how things play out at Airbnb.

Special thanks to Mike Fisher for his thoughts on the two articles and this post.

I find Brian Chesky incredibly interesting to listen to and I feel he is pushing the envelope on how a product organization can operate. As someone who has read a lot of SaaS and business books in general (including yours), I felt your overall assessment is overly critical based on a single interview. I totally see a world where you have more "GTM focused" leaders with design takes a larger role in building of the product.

回复

Great review

回复
Tucker Christiansen

Product Management Leader @ Intermountain | Ex Adobe | Building world-class teams and software that deliver results

1 年

Excellent article Marty Cagan! I love the breakdown of the pros/cons (and specifically all the good learnings). This really does sound like a failed empowerment attempt (for a number of reasons) now reverted to command and control. I would love to see L. David Marquet's intent based leadership team do a take on this story.

Jason Knight

I help leaders build outstanding product organisations

1 年

What I will say is that any leader of a company where "the crowd of designers cheers" the alleged end of product management has some serious cultural work to do

回复
James Hsu

Product leader, tech entrepreneur, creator, executive coach, marathoner.

1 年

Marty, really compelling analysis. I loved that you pulled in different perspectives and context from your own conversations, instead of choosing to only analyze Brian's words. For every principle, there is an opposing principle. There's no free lunch. As long as leaders articulate WHY they chose top-down vs. empowerment philosophies, based on the company's lifecycle and personal preferences, then things can make sense. It's when leaders obfuscate the true reasons that things become challenging. Really enjoyed this article, as I have with all your writing ever since I started with your Product Management "bible" so many years ago.

要查看或添加评论,请登录

社区洞察

其他会员也浏览了