Mike Lyons argues that product teams—long-lived, cross-functional groups that own a piece of the product and are accountable for outcomes—outperform siloed organizations where designers, engineers, and QA hand off work like an assembly line. A durable core squad works best at 8 to 10 people, with an extended team for sales, support, and marketing.
Now I know we talked about this a bit when we were covering the difference between projects and products, but it's important to understand that there's a difference between a product team and a project team. Come on, come on, we're a team, we're in this together. See, product teams, they're sometimes called durable teams, they are not created just to work on a single project or even a single feature. Sometimes you might also hear them referred to as a squad. Spotify will do that. And it kind of comes from a military analogy, but it's meant to emphasize that they're cross-functional teams that stay together for a long period of time. They're a group of people who bring together different specialized skills and, and responsibilities, and they actually feel real ownership for the product, or at least a substantial piece of the larger product. But before we look at why this works, we kind of have to look at the alternative for a minute, the, the functional silo team. Now, in a siloed organization, you've got a department of designers, a department of developers, and maybe a QA or testing department, and each group has its own boss, its own goals, its own way of doing things, and its own reward system. And work moves like an assembly line. Design finishes the mockup and then throws it over the wall to engineering, and then the engineering team, they get to work, and once they're ready, they throw it over the wall to QA, like to testers. And then once testing approves everything, then they hand the whole thing over to an entirely other team, the operations team, operations group who's going to deploy it. You know, so you've got these like assembly line step-by-step approaches, these, these different departments, and just lots of problems with that. One of the main problems is no one particular team owns the outcome, and each team is sort of— each person on the team even, they're rewarded for like how they perform within that part of the process. Again, not necessarily tied to the outcome that the business is trying to reach. Now compare that to a cross-functional team where the designer, the developer, the tester, and the deployment people, they're all sitting next to each other working on the same goal. They're on the same team. They're rewarded for the same thing, and that's, that's the outcome delivered to the customer. There's no kind of wall to throw things over. There's no meetings that need to be scheduled, and everyone's focused on the same goal. And, and of course, like I said, rewarded when they meet it. Some of the benefits of having a cross-functional team with end-to-end ownership of the product: it creates a shared ownership model for speed, and value delivery. And this is— it's way better. I've worked in so many of these environments. It's way better to have cross-functional, durable teams. Durability is about keeping the team together long enough to build expertise and passion. And if you pull people off every few months, well, they never really get deep enough to innovate or feel ownership. I mean, just think about it. Maybe you work in one of these traditional functional silo worlds. You're, you're kind of optimizing for resource utilization. I gotta keep everyone busy. But not in the cross-functional model. We're optimized for value delivery, you know, like are we getting the right product to the customer? That's what we're focused on. And you want the right mix of skills and people to cover the whole product space. If it's too small, you're kind of missing expertise. If it's too big, then you lose focus and speed. The sweet spot is usually around 8 people, maybe 10. Maybe you've heard the term "two pizza rule." You know, if you can't feed the team with two pizzas, it's too big. It was popularized by Amazon, but Generally speaking, that's about right in my experience. Don't let the small team size fool you into thinking that you're on an island. While the core squad is small and fast, a successful team, look, it requires a whole product mindset. So we want to include folks from sales and customer support, marketing into the process to ensure end-to-end accountability. You kind of think of it like this. There's a core team and an extended team. The core team builds and ships, but the extended team ensures that the product actually has a home in the market. I'll tell you something even more important than that. It's that strong teams, well, they need to get clear objectives from the business, and then they own those objectives, and they're empowered to figure out how to meet them. There's no kind of micromanagement, no waiting for permission at every step. The team's accountable for results, not just output. If you want a team that moves fast and innovates, well, you have to trust them to make decisions. Otherwise, you just kind of building a glorified assembly line. Autonomy means that teams can try to solve problems the way that they think is best. You still need alignment and coordination, but the team, they should have the freedom to own their work end to end. So a strong product team is dedicated, durable, with the right mix of skills, and they're empowered to own outcomes and given the autonomy to solve problems their way. And that's the foundation for building products that actually work.
