I was a guest on Lenny’s Podcast which was so much fun. Check out the episode! This post will explore three popular models for product teams. Sprint, Story, and Backlog-Centric Team and Mission-Centric Engineer-Centric (with Rockstar PMs) Sprint, Story, and Backlog-Centric
I work for a large company. Number 2 is the most appealing and intuitively just seems right. And yet I don't see how it could work in a company with complex roadmaps and dependencies among teams.
a follow-up here could be to explore how this feels, is supported/managed from people outside the "team". Interactions will be different and most organizations are setup for one of these. Enabling a team thus impacts a lot of people "outside" the team.
My team's paradigm is 1, but I feel the disconnect between designers and builders impairs our results. Is there a way to move towards 2? What does it take?
In my experience #1 is not sustainable as it accumulates tech debt (and product debt).
#2 has probably the best potential for keeping tech / product debt in check as the whole team feels the pain of it and there’s a shared understanding of the source and the cost of the pain.
Awesome summary! I got a feeling that the Engineering-Centric category will get more popular in the recent climate of recession & layoffs. That is exactly the type which can look more 'lean and efficient' from the top. I'm not sure that's true most of the cases though, especially for more old-fashioned companies, just as you wrote down there - great for FAANG, risky for non-tech companies.
John, incredibly clear and succinct. Just sent this to our CTO and his VPs as we're undergoing a reshuffling of teams to better support our strategy. Gold. Thank you
My product team falls into the Team and Mission-Centric bucket. We've worked in other types of teams. From experience, the Team and Mission-Centric types are the most enjoyable to work with because of trust being built, friendships, passion for the mission, aligned principles and values, and of course, leaning into conflict. This type of team falls into an empowered team, and these outcomes are powerful and more profitable for everyone.
Could you give examples of companies that following these models ? For e.g I dont know any successful company that follows model 1. ditto for the 3rd model. But I could be wrong
For me model 2 is best every time even though I agree it’s variable to project and team. The con I believe is that great collaboration is difficult to facilitate because most don’t know: (a) at what points in process do I need a collaboration? (b) what exactly do we do while together/how do we make progress vs talking in circles? (c) whose responsibility is it to lead / answer a and b. And in figuring that out people may likely panic about progress and/or get offended about ownership. But it’s the best if you get someone comfortable to lead.
Once again, so terribly well put.
I suspect the first two may also reflect different stages in a product lifecycle. I think the last one is nonsense as a general approach.
I work for a large company. Number 2 is the most appealing and intuitively just seems right. And yet I don't see how it could work in a company with complex roadmaps and dependencies among teams.
a follow-up here could be to explore how this feels, is supported/managed from people outside the "team". Interactions will be different and most organizations are setup for one of these. Enabling a team thus impacts a lot of people "outside" the team.
This sythesizes what I have observed but failed to put to words myself. Completely spot on. Thanks!
My team's paradigm is 1, but I feel the disconnect between designers and builders impairs our results. Is there a way to move towards 2? What does it take?
You can add structure to 2. by using 1. with Team as customer. Or, add team goals to 1. by allocatong certain story points to Team.
In my experience #1 is not sustainable as it accumulates tech debt (and product debt).
#2 has probably the best potential for keeping tech / product debt in check as the whole team feels the pain of it and there’s a shared understanding of the source and the cost of the pain.
Awesome summary! I got a feeling that the Engineering-Centric category will get more popular in the recent climate of recession & layoffs. That is exactly the type which can look more 'lean and efficient' from the top. I'm not sure that's true most of the cases though, especially for more old-fashioned companies, just as you wrote down there - great for FAANG, risky for non-tech companies.
John, incredibly clear and succinct. Just sent this to our CTO and his VPs as we're undergoing a reshuffling of teams to better support our strategy. Gold. Thank you
My product team falls into the Team and Mission-Centric bucket. We've worked in other types of teams. From experience, the Team and Mission-Centric types are the most enjoyable to work with because of trust being built, friendships, passion for the mission, aligned principles and values, and of course, leaning into conflict. This type of team falls into an empowered team, and these outcomes are powerful and more profitable for everyone.
Great article.
Could you give examples of companies that following these models ? For e.g I dont know any successful company that follows model 1. ditto for the 3rd model. But I could be wrong
For me model 2 is best every time even though I agree it’s variable to project and team. The con I believe is that great collaboration is difficult to facilitate because most don’t know: (a) at what points in process do I need a collaboration? (b) what exactly do we do while together/how do we make progress vs talking in circles? (c) whose responsibility is it to lead / answer a and b. And in figuring that out people may likely panic about progress and/or get offended about ownership. But it’s the best if you get someone comfortable to lead.
Curious: where did images 2 & 3 come from?
This is a great complement to your "Journey to Product Teams" article from a few years back. Thank you!