by Marty Cagan
The other path is to move into functional management of the product managers (the most common title is director of product management) where some number of product managers (usually somewhere between 3 and 10) report directly to you. The director of product management is really responsible for two things. The first is ensuring his or her product managers are all strong and capable. The second is product vision and strategy and connecting the dots between the product work of the many teams. This is also referred to as holistic view of product.
But lots of strong senior product managers are not sure about their preferred career path at this stage, and the GPM role is a great way to get a taste of both worlds.
The GPM is the actual product manager for one product team, but in addition, she is responsible for the development and coaching of a small number of additional product managers (typically, one to three others).
While the director of product management may have product managers who work across many different areas, the GPM model is designed to facilitate tightly coupled product teams.
This is easiest to explain with an example.
Let's say you're a growth stage marketplace company, and you have roughly 10 product teams. You may likely have those 10 teams split up into three types: a platform/common services group, and then a group for each side of the marketplace (e.g., buyers and sellers, riders and drivers, or hosts and guests).
There might be one VP product and three GPMs—one for each of the three groups, for example, a GPM of buyer side, a GPM of seller side, and a GPM of platform services.
So now let's drill in on the GPM for buyer side, and let's say there are three product teams comprising the buyer‐side experience. The GPM of buyer side would have one of those teams, and each of the other two teams would have a product manager that reports to the GPM.
We like this because the buyer side really needs to be one seamless solution, even though there may be multiple product teams working on different aspects of it. The GPM works very closely with the other PMs to ensure this.
This role is often called a player‐coach role because of this dynamic of leading your own team, in addition to being responsible for coaching and developing one to three other PMs.
This role is often called a player‐coach role because of this dynamic of leading your own team, in addition to being responsible for coaching and developing one to three other PMs.
Some GPMs go on to become a director or VP of product management, some go on to a principal product manager role, and some decide to stay on as a GPM because they love the blend of hands‐on working with their own product team, as well as the ability to influence other teams and other product managers through coaching.
CHAPTER 18
The Head of Technology Role
Even with the greatest product ideas, if you can't build and launch your product, it remains just an idea. So, your relationship with the engineering organization is all important.
In this chapter, I describe the leader of the engineering organization. I had the good fortune to collaborate on this chapter with one of Silicon Valley's most successful CTOs, Chuck Geiger.
I have often said that, if as product manager you have a good working relationship with your engineering counterpart, then this is a great job. If you don't, you're in for some very tough days. So, in the spirit of developing a better appreciation for what makes a great technology organization, we offer this summary.
First, let's be clear which organization we're referring to. This is the organization responsible for architecture, engineering, quality, site operations, site security, release management, and usually delivery management. This group is responsible for building and running the company's products and services.
The titles vary but often include VP engineering, or chief technology officer (CTO). In this chapter, we'll refer to the head of this organization as the CTO, but feel free to substitute the term your company uses.
Even with the greatest product ideas, if you can't build and launch your product, it remains just an idea.
There is one title, however, that is often a problem: the chief information officer (CIO). The CIO role is very different from the CTO role. In fact, if your technology organization reports to the CIO, that is a warning flag for many of the pathologies discussed in Chapter 6, “The Root Causes of Failed Product Efforts.”
The hallmark of a great CTO is a commitment to continually strive for technology as a strategic enabler for the business and the products. Removing technology as a barrier, as well as broadening the art of the possible for business and product leaders, is the overarching objective.
To that end, there are six major responsibilities of a CTO. We present them here in priority order and discuss how each is typically measured.
Organization
Build an excellent organization with a strong management team committed to developing the skills of your employees. We typically measure effectiveness here by looking at development plans for all the employees, the retention rate, and the evaluation of the managers and the overall product and technology organization by the rest of the company.
Leadership
Represent technology in the overall strategic direction and leadership of the company, working with other company executives to help inform direction, M&A activity, and build/buy/partner decisions.
Delivery
Make sure this organization can rapidly, reliably, and repeatedly deliver quality product to market. There are several measures of delivery, including the consistency and frequency of release vehicles, and the quality/reliability of the delivered/launched software. The main obstacle to rapid delivery is often technical debt, and it is the responsibility of the CTO to ensure that the company is keeping this at a manageable level and not allowing the problem to cripple the organization's ability to deliver and compete, which is discussed next.
Architecture
Make sure the company has an architecture capable of delivering the functionality, scalability, reliability, security and performance it needs to compete and thrive. In companies that have multiple product lines or vertical business units, the CTO needs to be the leader in a cohesive technology strategy looking at the sum, and not just the parts. The CTO is the orchestrator of a company‐wide technology strategy. The measures for architecture will vary based on your business, but in general, we look to ensure that the infrastructure is continuously monitored and advanced to keep pace with the growth of the business, and we measure outages that impact our customers that are due to infrastructure or architectural issues.
Discovery
Make sure that members of the senior engineering staff are participating actively and contributing significantly throughout product discovery. If your engineers and architects are only being used to write software, then you are only getting a fraction of the value from them you should be. We encourage you to keep an eye on the participation of the engineering organization in product discovery (both duration and coverage) and follow the frequency of innovations credited to the engineering participant.
Evangelism
The CTO will serve as the company spokesperson for the engineering organization, demonstrating leadership in the community with developers, partners, and customers. Leadership of this type can be measured by establishing a university relations/recruitment program and sponsoring or participating in several events per year in the developer community.
You may want to go to lunch with your engineering counterpart and discuss what they see as their biggest challenges and how you might be able to help from the product side. Anything you can do to help each other out will go a long way to creating a truly effective overall product organization, able to discover and deliver winning products.
CHAPTER 19
The Delivery Manager Role
In growth‐stage and enterprise companies, many product managers complain that they have to spend far too much of their time doing project management activities. As a result, they have almost no time to address their primary pro
duct responsibility: ensuring that the engineers have a product worth building.
Delivery managers are a special type of project manager whose mission is all about removing obstacles—also known as impediments—for the team. Sometimes, these obstacles involve other product teams, and sometimes they involve non‐product functions. In a single day, they might track down someone in marketing and press them for a decision or an approval, coordinate with the delivery manager on another team about prioritizing a key dependency, persuade a product designer to create some visual assets for one of the front‐end developers, and deal with a dozen other similar roadblocks.
These delivery managers are typically also the Scrum Masters for the team (if they have that role). They are all about helping the team to get stuff live faster, not by cracking the whip but by removing obstacles that get in the way.
In growth‐stage and enterprise companies, many product managers complain that they have to spend far too much of their time doing project management activities.
These people might have the title project manager—or sometimes program manager—but if that's the case, then we need to make sure these people have defined the job like I did here and not in the old program management sense.
If your company does not have delivery managers—by whatever title—then this work typically falls to the product manager and the engineering managers. Again, if your organization is small, then this is fine—and there are even advantages. But if your organization is larger—on the order of at least 5 to 10 product teams, then this role becomes increasingly important.
CHAPTER 20
Principles of Structuring Product Teams
One of the most difficult issues facing every product organization at scale is just how to split up your product across your many product teams.
The need to split up your product starts to show up with just a few product teams, but at scale—25, 50, more than 100 product teams—this becomes a very substantial factor in the company's ability to move quickly. It's also a significant factor in keeping teams feeling empowered and accountable for something meaningful, yet contributing to a bigger vision where the sum is greater than the parts.
If you are already at scale, then I'm certain you know what I'm talking about.
What makes this such a difficult topic is that there is no one right answer. There are many considerations and factors, and good product companies debate the alternatives and then make a decision.
One of the most difficult issues facing every product organization at scale is just how to split up your product across your many product teams.
I have personally worked with many product and technology organizations as they considered the options, and for many of those, I've been able to watch how things worked out over time.
I know that many people crave a recipe for structuring product teams, but I always explain to them that there is no recipe. Instead, there are some critical core principles, and the key is to understand those principles and then weigh the options for your particular circumstances.
Alignment with investment strategy It's remarkable to me how many companies I find in which the teams are simply reflections of their ongoing investments. They have certain teams because they have always had those teams. But, of course, we need to be investing in our future as well. We can phase out products that no longer carry their own weight, and we can often reduce the investments in our cash‐cow products so that we can invest more in future sources of revenue and growth. There are any number of ways to think about spreading out your investments over time and risk. Some people like the three horizons model, while others take more of a portfolio management approach. The point here is that you need to have an investment strategy, and your team structure should be a reflection of that.
Minimize Dependencies A big goal is to minimize dependencies. This helps teams move faster and feel much more autonomous. While we can never entirely eliminate dependencies, we can work to reduce and minimize them. Also note that dependencies change over time, so track them continuously and always ask yourself how they can be reduced.
Ownership and Autonomy Remember that one of the most important traits of product teams is that we want teams of missionaries and not teams of mercenaries. This leads directly to the concepts of ownership and autonomy. A team should feel empowered, yet accountable for some significant part of the product offering. This is harder than it sounds because large systems don't always slice up so cleanly. Some level of interdependencies will always chip away at the sense of ownership. But we work hard to try to maximize this.
Maximize Leverage As organizations grow, we often find common needs and the increased importance of shared services. We do this for speed and reliability. We don't want every team reinventing the wheel. Realize, however, that creating shared services also creates dependencies and can impinge on autonomy.
Product Vision and Strategy The product vision describes where we as an organization are trying to go, and the product strategy describes the major milestones to get there. Many larger and older organizations no longer have a relevant vision and strategy, but this is key. Once you have your vision and strategy, ensure you have structured the teams to be well positioned to deliver on them.
Team Size This is a very practical principle. The minimum size for a product team is usually two engineers and a product manager, and if the team is responsible for user‐facing technology, then a product designer is needed, too. Fewer than that is considered below critical mass for a product team. On the other end, it's really difficult for one product manager and product designer to keep more than about 10–12 engineers busy with good stuff to build. Also, in case it's not clear, it's important that each product team have one, and only one, product manager.
Alignment with Architecture In practice, for many organizations the primary principle for structuring the product teams is the architecture. Many will start with the product vision, come up with an architectural approach to deliver on that vision, and then design the teams around that architecture.
That may sound backward to you, but in truth there are some really good reasons for this. Architectures drive technologies, which drive skill sets. While we'd love for every team to be a full stack team that can work on any layer of the architecture, in practice that's often not an option. Different engineers are trained in different technologies. Some want to specialize (and, in fact, have in many cases spent many years specializing), and some are years away from having the necessary skills. Architecture does not change quickly.
It's usually easy to see when a company has not paid attention to the architecture when they assemble their teams—it shows up a few different ways. First, the teams feel like they are constantly fighting the architecture. Second, interdependencies between teams seem disproportionate. Third, and really because of the first two, things move slowly, and teams don't feel very empowered.
For larger companies, especially, it's typical to have one or more teams that provide common services to the other product teams. We often label these teams common services, core services, or platform teams, but they primarily reflect the architecture. This is very high‐high leverage, which is why so many companies have these types of teams at scale. However, it is also a difficult type of team to staff because these teams are dependencies (by design) of all the other teams, as they are there to enable the other teams. Be sure to staff these common services teams with strong and highly technical product managers (often called platform product managers).
Alignment with User or Customer Aligning with the user and customer has very real benefits for the product and for the team. If, for example, your company provides a two‐sided marketplace with buyers on one side and sellers on the other, there are real advantages to having some teams focus on buyers and others focus on sellers. Each product team can go very deep with their type of customers rather than have them try to learn about all types of customers. Even in marketplace companies, however, they will invariably have some number of teams th
at provide the common foundation and shared services to all the teams. This is really a reflection of the architecture, so the point here is that it is perfectly fine—and usual—to have both types of teams.
Alignment with Business In larger companies, we often have multiple lines of business but a common foundation for our products. If the technology is truly independent across businesses, then we'd just treat them as essentially different companies as we structure product teams. However, mostly that's not the case. We have multiple lines of business, but all are built on a common and often integrated foundation. This is roughly similar to aligning by customer type, but there are important differences. Our business unit structure is an artificial construct. The different business units are often selling to the same actual customers. So, while there are advantages to aligning with business units, this usually comes after the other factors in priority.
Structure Is a Moving Target Realize that the optimal structure of the product organization is a moving target. The organization's needs should and will change over time. It's not like you'll need to reorganize every few months, but reviewing your team structure every year or so makes sense.
I often have to explain to companies that there is never a perfect way to structure a team—every attempt at structuring the product organization will be optimized for some things at the expense of others. So, as with most things in product and technology, it involves tradeoffs and choices. My hope is that these principles will help you as you guide your organization forward.