INSPIRED

by Marty Cagan

  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.

  Team Duration

  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.

  Team Autonomy

  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.

  Why It Works

  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.

  Principles and Techniques

  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.

  CHAPTER 10

  The Product Manager

  This book is about becoming an excellent product manager, and in this chapter, I want to be very explicit about what that really means.

  But first, it's time for a little dose of tough love.

  There are essentially three ways for a product manager to work, and I argue only one of them leads to success:

  The product manager can escalate every issue and decision up to the CEO. In this model, the product manager is really a backlog administrator. Lots of CEOs tell me this is the model they find themselves in, and it's not scaling. If you think the product manager job is what's described in a Certified Scrum Product Owner class, you almost certainly fall into this category.

  The product manager can call a meeting with all the stakeholders in the room and then let them fight it out. This is design by committee, and it rarely yields anything beyond mediocrity. In this model, very common in large companies, the product manager is really a roadmap administrator.

  The product manager can do his or her job.

  The honest truth is that the product manager needs to be among the strongest talent in the company.

  My intention in this book is to convince you of this third way of working. It will take me the entire book to describe how the strong product manager does his or her job, but let me just say for now that this is a very demanding job and requires a strong set of skills and strengths.

  The reason for calling this out so bluntly is that, in many companies, especially older, enterprise companies, the product manager role has a bad reputation. What too often happens is that the company takes people from other organizational roles—often project management or sometimes
business analysts—and they say, “We're moving to Agile and we don't need project managers or business analysts anymore, so we need you to be a product manager.”

  The honest truth is that the product manager needs to be among the strongest talent in the company. If the product manager doesn't have the technology sophistication, doesn't have the business savvy, doesn't have the credibility with the key executives, doesn't have the deep customer knowledge, doesn't have the passion for the product, or doesn't have the respect of their product team, then it's a sure recipe for failure.

  There are lots of ways to describe this particular role. Some people prefer to focus on the raw ingredients of what makes a strong product manager. Others tend to focus on the product manager's day‐to‐day activities and what they'll be spending their time doing.

  We'll cover all that, but to me what's most important to talk about is what product managers are responsible for contributing to their team. That's not so obvious for the product manager. It's not that unusual for people to question whether they even need a product manager. If they don't design and they don't code, why bother?

  This is a clear sign of a company that hasn't experienced strong product management.

  Key Responsibilities

  At one level, the responsibilities of the product manager are pretty straightforward. He or she is responsible for evaluating opportunities and determining what gets built and delivered to customers. We generally describe what needs to get built on the product backlog.

  When a product succeeds, it's because everyone on the team did what they needed to do. But when a product fails, it's the product manager's fault.

  Sounds simple enough. And the mechanics of that are not the hard part. What's hard is to make sure that what goes on the product backlog is worth building. And, today, on the best teams, the engineers and designers want to see some evidence that what you're asking to build is truly worth building.

  But if you want to know why the product manager role is considered so important today by CEOs and venture capitalists (VCs), it's this:

  Every business depends on customers. And what customers buy—or choose to use—is your product. The product is the result of what the product team builds, and the product manager is responsible for what the product team will build.

  So, this is why the product manager is the person we hold responsible and accountable for the success of the product.

  When a product succeeds, it's because everyone on the team did what they needed to do. But when a product fails, it's the product manager's fault.

  You can start to see why this role is a proving ground for future CEOs and why the best VCs only want to invest in a company that has one of these proven product people as one of the co‐founders.

  So, this chapter is really about what you need to do to succeed at this job. In that spirit, there are four key responsibilities of a strong product manager; four things that the rest of your team is counting on you to bring to the party:

  Deep Knowledge of the Customer

  First and foremost is deep knowledge of the actual users and customers. To make this explicit, you need to become an acknowledged expert on the customer: their issues, pains, desires, how they think—and for business products, how they work, and how they decide to buy.

  This is what informs so many of the decisions that must be made every day. Without this deep customer knowledge, you're just guessing. This requires both qualitative learning (to understand why our users and customers behave the way they do), and quantitative learning (to understand what they are doing), which is what we'll talk about next.

  It should go without saying as it's really table stakes for a product manager, but just to be clear, the product manager must also be an undisputed expert on your actual product.

  Deep Knowledge of the Data

  Today, product managers are expected to be comfortable with data and analytics. They are expected to have both quantitative skills as well as qualitative skills. The Internet enables unprecedented volume and timeliness of data.

  A big part of knowing your customer is understanding what they're doing with your product. Most product managers start their day with half an hour or so in the analytics tools, understanding what's been happening in the past 24 hours. They're looking at sales analytics and usage analytics. They're looking at the results of A/B tests.

  You might have a data analyst to help you with this, but the analysis of the data and understanding you get of your customer is not something you can delegate.

  Deep Knowledge of Your Business

  Successful products are not only loved by your customers, but they work for your business.

  The third critical contribution—and the one that is often considered the most difficult by many product managers—is a deep understanding of your business and how it works, and the role your product plays in your business. This is tougher than it sounds.

  Successful products are not only loved by your customers, but they work for your business.

  This means knowing who your various stakeholders are and especially learning the constraints they operate under. There are usually key stakeholders representing general management, sales, marketing, finance, legal, business development, and customer service. Your CEO is usually a very important stakeholder as well.

  Succeeding in the job of product means convincing each key stakeholder that you understand their constraints and that you are committed to only delivering solutions that you believe are consistent with those constraints.

  Deep Knowledge of Your Market and Industry

  The fourth critical contribution is deep knowledge of the market and industry in which you're competing. This includes not only your competitors but also key trends in technology, customer behaviors and expectations, following the relevant industry analysts, and understanding the role of social media for your market and customers.

  Most markets have more competitors today than ever before. Further, companies understand the value in making products that are sticky, and this means that it can be difficult for prospective customers to move from your competitor to you. This is one of the big reasons why it is not enough to have feature parity with a competitor. Rather, you need to be substantially better to motivate a user or customer to switch.

  Another reason to have a deep understanding of the competitive landscape is that your products will need to fit into a more general ecosystem of other products, and ideally your product is not only compatible with that ecosystem but adds significant value to it.

  Further, your industry is constantly moving, and we must create products for where the market will be tomorrow, not where it was yesterday.

  As an example, as of this writing, there is a major enabling technology trend sweeping through our industry, which is based on machine learning and other forms of artificial intelligence. I feel comfortable predicting that this will be a major technology trend for at least the next decade, and this is why you need to love technology‐powered products. What is possible is constantly changing. If you're not excited about learning these new technologies, and exploring with your engineers and designers how you can use these trends to deliver dramatically improved products and experiences to your customers, then you really need to consider whether this career is for you.

  To summarize, these are the four critical contributions you need to bring to your team: deep knowledge (1) of your customer, (2) of the data, (3) of your business and its stakeholders, and (4) of your market and industry.

  If you're a designer or engineer, and you've been asked to cover the product manager role as well, then this is what you need to sign up for. I warned you—it's a ton of work.

  One additional note: In some companies, there is so much in terms of industry and domain knowledge that the product manager may be supplemented with what are called domain experts or subject matter experts. Examples of domain experts can be found in companies that build tax software or create medical devices. In these cases, you can't expect the product m
anagers to have the necessary level of domain depth, in addition to everything else. But these cases are fairly rare. The normal case is that the product manager does need to have (or be able to learn) the necessary domain expertise.

  It normally takes about two to three months of dedicated work for a new product manager to get up to speed. This assumes you have a manager who can give you the help and access you need to gain this expertise, including lots of access to customers, access to data (and when necessary, training in the tools to access that data), access to key stakeholders, and time to learn your product and industry inside and out.

  Smart, Creative, and Persistent

  Now that we've seen what the product manager needs to contribute to the team, let's consider the kind of person who thrives in this environment.

  The successful product manager must be the very best versions of smart, creative, and persistent.

  The successful product manager must be the very best versions of smart, creative, and persistent.

  By smart, I don't just mean raw IQ. I especially mean intellectually curious, quickly learning and applying new technologies to solve problems for customers, to reach new audiences, or to enable new business models.

  By creative, I mean thinking outside the normal product box of features to solve business problems.

  By persistent, I mean pushing companies way beyond their comfort zone with compelling evidence, constant communication, and building bridges across functions in the face of stubborn resistance.