In later chapters, I explore each of the key roles on a team, but in this chapter, I explain the principles of a strong product team.
Product teams are sometimes referred to as a dedicated product team or as a durable product team, to emphasize that these are not created just to work on a single project or feature, or sometimes as a squad—derived from the military analogy and meant to emphasize that these are cross‐functional teams.
A product team is a group of people who bring together different specialized skills and responsibilities and feel real ownership for a product or at least a substantial piece of a larger product.
There are many ways to set up product teams (we'll discuss these later in the section People @ Scale). But in good product companies, you'll find that, despite the differences due to their unique products and circumstances, there are several very important similarities.
There are many benefits of product teams, but a big goal is captured best by a quote from John Doerr, the famous Silicon Valley venture capitalist: “We need teams of missionaries, not teams of mercenaries.”
Mercenaries build whatever they're told to build. Missionaries are true believers in the vision and are committed to solving problems for their customers. In a dedicated product team, the team acts and feels a lot like a startup within the larger company, and that's very much the intention.
We need teams of missionaries, not teams of mercenaries.
A typical product team is comprised of a product manager, a product designer, and somewhere between two and about 10 to 12 engineers.
Of course, if the product you're working on doesn't have a user‐facing experience—such as for a set of programmatic APIs—you probably don't need the product designer. But many product teams do need this person on board, and throughout this book, I'll generally assume your team does, too.
Teams might also have a few other members such as a product marketing manager, one or more test automation engineers, a user researcher, a data analyst, and, in larger product organizations, a delivery manager.
Don't worry if you don't yet know what some of these roles are—we'll soon explore each of them.
A big part of the concept of product teams is that they are there to solve hard problems for the business. They are given clear objectives, and they own delivering on those objectives.
They are empowered to figure out the best way to meet those objectives, and they are accountable for the results.
There's no rule that says all product teams in a company need to be the same size. It's true there is the notion of critical mass for a product team—usually one product manager, one designer, and two engineers. However, some teams might justify five engineers and two test automation engineers—others even more.
There is a practical upper bound on a team, which usually works out to be around 8–12 engineers. You've probably heard about the two‐pizza rule, which is intended to help keep teams in this range.
More important than the absolute size of the team is the balance of skills needed to ensure we build the right things, and build those things right.
Note that I haven't said anything yet about who works for whom.
A product team is not about reporting relationships—it has an intentionally flat organizational structure. Usually, everyone on a product team is an individual contributor, and there are no people managers.
The people on the team typically continue to report to their functional manager. For example, the engineers report to an engineering manager. Likewise, the designer usually reports to a head of design, and the product manager reports into a head of product. So, this is not about reporting relationships.
To be absolutely clear, the product manager is not the boss of anyone on the product team.
A product team is a set of highly skilled people who come together for an extended period of time to solve hard business problems.
The nature of the relationship is more about true collaboration. I don't mean collaboration as a buzzword, either. I literally mean product, design, and engineering working out solutions together. Much more on that to come, but at this point, it's important for you to understand that this is not a hierarchy.
I also haven't said anything yet about where the members of the team are physically located. While this isn't always possible, we try very hard to co‐locate this team.
Co‐location means that team members literally sit right next to one another. That doesn't mean in the same building or even the same floor. It means close enough to easily see each other's computer screens.
I know this sounds a bit old school, and the tools for remote collaboration are getting better all the time, but the best companies have learned the value of sitting together as a team.
If you've ever been a member of a co‐located product team, you likely already know what I mean. But, as you'll see from how we do our work on a product team, there is a special dynamic that occurs when the team sits together, eats lunch together, and builds personal relationships with one another.
I'm aware this can be a bit of an emotional topic. For personal reasons, quite a few people live somewhere other than where they work, and their livelihood depends on working effectively remotely.
I don't want to paint this as too black or white, but I also don't want to mislead you. All other things being equal, a co‐located team is going to substantially outperform a dispersed team. That's just the way it is.
This is also one of the reasons why we greatly prefer members of a product team to be actual employees and not contractors or agencies. It's much easier to be co‐located and to be a stable member of the team if the person is an employee.
Note that there is nothing wrong with a company having multiple locations, so long as we try hard to have co‐located teams in each location.
We'll talk later about what we do when not all the members are able to sit together.
Once you've got the basics of a product team, the next big question is this: What is the scope or charter of each team? That is, what is each team responsible for?
One dimension of this is the type of work to be done, and it's important that a product team has responsibility for all the work—all the projects, features, bug fixes, performance work, optimizations, and content changes—everything and anything for their product.
The other dimension is the scope of work to be done. In some types of companies, the product team is responsible for a complete product. But it's more common today that the product is the full customer experience (imagine a Facebook or a PayPal), and each team is responsible for some smaller but meaningful piece of that experience.
For example, you might be working on a team at eBay that's responsible for technology to detect and prevent fraud or tools and services for high‐volume sellers. Or, at Facebook, your team might be responsible for newsfeeds, an iOS native mobile app, or the capabilities required for a specific vertical market.
This is an easy topic for a small startup, as you typically just have one or a small number of teams, which makes it relatively easy to split things up.
But as a company grows, the number of teams expands from a handful to 20, 50, or more teams in large product companies. The coordination gets harder (much more on that when we get to the section on Product @ Scale), but the concept is highly scalable and, in fact, is one of the keys to scalability.
There are lots of useful ways to slice up the pie. Sometimes we have each team focus on a different type of user or customer. Sometimes each team is responsible for a different type of device. Sometimes we break things up by workflow or customer journey.
Sometimes, actually very often, we are largely defining the teams based on the architecture. This is pretty common because the architecture drives the technology stack, which often requires different types of engineering expertise.
In any case, what's critically important is alignment between product management and engineering. This is why the head of product and the head of engineering normally get together to define the size and scope of the teams.
I will tell you there's never a perfect way to carve up the pie. Realize that, when you optimize for one thing, it comes at the expense of something else. So, decide what's most important to you and go with that.
I've mentioned a few times already that these teams need to be durable, but I haven't said whether this means for a few months or several years.
The bottom line is that we try hard to keep teams together and fairly stable.
While things do come up, and people change jobs and teams, once the members of a team get to know one another, and learn how to work well together, it's honestly a beautiful and powerful thing, and we try hard not to mess up that dynamic.
Another reason that durability is important is that it can take some time to gain enough expertise in an area to innovate. If people are moving from team to team all the time, it's hard for them to get that expertise and to feel the necessary sense of ownership over their product and missionary‐like passion.
And to be clear, a product team is not something we create just to deliver a specific project. It's nearly impossible to have a team of missionaries when they're pulled together for a project that lasts only a few months and is then disbanded.
If we want teams to feel empowered and have missionary‐like passion for solving customer problems, we need to give them a significant degree of autonomy. Obviously, this doesn't mean they can go off and work on whatever looks fun, but it does mean that they are able to try to solve the problems they are assigned in the best way they see fit.
They are able to try to solve the problems they are assigned in the best way they see fit.
It also means we try to minimize dependencies between teams. Notice that I said “minimize” and not “eliminate.” At scale, it's just not possible to eliminate all dependencies, but we can work hard to continuously minimize them.
Product companies moved to this model several years ago, and it's now one of the pillars of modern, strong product organizations. There are several reasons why this model has been so effective.
First, collaboration is built on relationships, and product teams—especially co‐located teams—are designed to nurture these relationships.
Second, to innovate you need expertise, and the durable nature of product teams lets people go deep enough to gain that expertise.
Third, instead of just building what others determine might be valuable, in the product team model the full team understands—needs to understand—the business objectives and context. And most important, the full team feels ownership and responsibility for the outcome.
Instead of the old project‐oriented model, which is all about getting something pushed through the process and out the door, in the dedicated team model, the team is not off the hook just because something launches. They don't rest until and unless it's working for the users and for the business.
Hopefully you're already a member of a strong, dedicated product team, and now you just have a better appreciation for the intention of this model.
On the other hand, if your company is not yet set up around dedicated product teams, this is probably the most important thing for you to fix. Everything else depends on this.
You don't have to move the whole organization there at once—you can start a team as a pilot. But one way or another, it's essential that you create or join a durable product team.
I want to be clear as to why you'll see so many principles called out in this book.
When I coach product managers, I always try my best to explain the underlying principles of why we need to work the way we do.
I find that when a person reaches the point that they have a solid understanding of the principles, they develop a good mental model for when each technique is useful and appropriate, and when it is not. Further, as new techniques emerge, they are able to quickly assess the potential value of the technique, and when and where it is best utilized.
I have found over the years that while the techniques change fairly constantly, the underlying principles endure. So, while it may be tempting to jump right to the techniques, I hope you will first consider the principles, and work to develop a deeper understanding of how to build great products.