Cagan vs Chesky and the Quest for the Best Product Team

The world of product management has been buzzing in the past few weeks as Marty Cagan , of Silicon Valley Product Group, responded to an interview with Brian Chesky (the co-founder and CEO of Airbnb ) on Lenny’s Podcast.

Cagan’s long held position is that there are three basic types of “product teams:”

• Delivery Teams - These pair a group of developers with a product owner or product manager who acts as “a sort of backlog administrator.” Their success is defined by output: executing flawlessly on clearly defined deliverables.?
• Feature Teams - These are also all about output - features or “projects” - that are generally provided to the team by business leader/stakeholders in the form of a prioritized list that they work through: “the roadmap.”
• Product Teams - These, conversely, are outcome-driven teams. Cagan defines their mission being to “solve problems in ways our customers love, yet work for our business.”

Both delivery teams and feature teams are told what to do and are measured on delivering output - generally to a time schedule. Their top priority is releasing capabilities, with the expectation that the way in which those capabilities create value for customers has already been worked out by someone else. They tend to have fixed capacity and skills on the team, without cross-functional participation from outside of engineering & product. Most notably, they have almost no autonomy. Direction in feature or delivery teams follows a command and control model where authority and direction comes from an external authority (in startups, it’s often the technical or product visionary CEO/founder).

Product teams are different from the other types in that they have three distinctive characteristics:

• they are cross-functional (product, engineering, product marketing, design, etc)
• they are focused on and measured by outcomes (rather than output)
• they are empowered to figure out the best way to solve problems, allowing customers to achieve the outcomes that create value both for them and the business

Product and Feature teams can look similar, but they have a very different relationship with leadership and create very different value for their customers. Cagan isn’t shy with his opinion: “the best product teams at the best companies are all about the empowered product team model.”

But then, along came the Lenny’s episode...

“People think that great leader's job is to hire people and just empower them to do a good job. Well, how do you know they're doing a good job if you're not in the details? And so I made sure I was in the details and we really drove the product.” said Chesky. Lenny mentioned a conversation with another CEO who described “this cycle that he sees a lot of founders go through where they initially run the show, they're in charge, they tell people what to build, and then over time they're encouraged to delegate and to empower and it leads to a bunch of optimization work and small thinking maybe.” Chesky agreed: “the CEO should be basically the chief product officer of a product or tech company. If the CEO is not the chief product officer then I don't know if they're a product or tech led company.“ Anything else leads to poor outcomes.

There was this other scenario where the less involved I was in the project, the more spin there was, the less clear the goals, the less advocacy the team had, the less resources, the fewer resources they had. And then therefore the slower they moved. And the slower they moved, the more they assumed it was because I was too involved. Because people assume that our natural equilibrium's to move fast so if we're moving slow, it's because of an over involvement in leadership and therefore I would get less involved. I would give teams more control. I would give them teams more empowerment. And the more I kept giving people what they asked for initially, they may have been happy, but the outcome of it was always, it seemed weirdly like they got less of what they wanted. They wanted to move faster so I'd empower them and move slower.

So what are we to believe? On one hand we have Marty Cagan and others who have strong evidence that empowered product teams focused on outcomes are the best. On the other, we have visionary product or engineering-led founder/CEOs who achieve great success with feature teams who amplify their vision via clear direction and deep personal involvement. Which is better? In my experience - and that includes working with both types of teams - they’re both viable options, depending on the stage of the company and the challenge at hand.

(Note; this only pertains to companies with a visionary product or engineering-led founder - if the company is led by, say, a GTM oriented founder CEO, then the answer is quite different. I’ll address this in a future article.)

Feature teams may be best for:

• Early-stage company with a small engineering team where the high-velocity that comes from laser-focus is essential
• Growth-stage companies with strong evidence of product-market fit, but that need to scale out to multiple teams to quickly close feature gaps

In other words, features teams may be best when you just need to get the s&$t done.

Product Teams may be best for:

• More mature companies that need to expand beyond their initial solution or use-case to drive growth via new products or capabilities
• Established solutions facing strong competitive pressure where product teams can take a broader look at the market and focus on ways to solve novel customer problems that create competitive separation

In other words, product teams may be best when “what got you here won’t get you there” (to borrow a phrase from the great book by by Marshall Goldsmith).

And frankly, in many companies (with the exception of very early stage startups) a combination of both may be ideal if the work to be done permits it. Some product and technical leaders thrive in an environment with more autonomy, but they need to be comfortable with it coming at the cost of having a lot more that needs to be figured out. If the thought of not knowing exactly what the next sprint might look like bothers you, a product team may not be a great fit. At the same time, some may thrive in an environment with far less ambiguity, even though that may come at the cost of less room for creativity. If your company is in a position where there is suitable work for both feature teams and product teams, use both. Perhaps a feature team can drive delivery of product enhancements and certain “check-box” features that are needed for competitive neutralization. A separate team can follow the empowered product team approach to drive innovation initiatives. An additional benefit of operating both models is that attracting and retaining great talent may be easier since you can match hires with the working mode that’s best for them.

One warning for the visionary product or engineering-led founder founder/CEO who chooses to exclusively leverage the feature team model is to not overlook the needs of the product managers in the org. The founder/CEO is likely not a PM expert who can mentor the team, hire the types of PMs who will thrive in this type of environment, establish processes that facilitate good flow within the teams, create visibility across the org into what the roadmap looks like, etc. Cagan said in his response to the podcast that one reason he assumed that empowering the teams didn’t yield the desired results at Airbnb is that “he [Chesky] 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.” While “the CEO should be basically the chief product officer” that doesn’t mean that he’ll be the right leader for a product team. And don’t forget that command and control takes significantly more time and effort - leaving a risk of gaps in other areas where the CEO’s involvement is critical (longterm strategy, GTM, IR and fundraising, etc.).

Do you use product teams? Feature teams? Both? I’d love to hear your thoughts on the pro’s and con’s of both approaches - as well as the potential of them coexisting within a single org.?Repost and share to broaden the conversation!