by Marty Cagan
Include your designer in as many customer and user interactions as possible. Learn about the users and customers together.
Fight your temptation to provide your designer with your own design ideas. Give your designer as much room as possible to solve the design challenges him or herself.
Encourage your designer to iterate early and often. The best way you can encourage this is to not get all nitpicky about design details with the very early iterations. More generally, encourage your designer to feel free not to just iterate on the particular design approach but to explore alternative solutions to the problem.
The bottom line is that you and your designer really are partners. You're there to discover the necessary product solutions together, and you each bring different and critical skills to the team.
CHAPTER 12
The Engineers
In this chapter, I describe the engineering role (also commonly known as developers or, in some circles, programmers). But as with the last chapter, I'm not trying to speak here to the engineers—I'm aiming this discussion at product managers who need to learn how to work effectively with engineers.
There's probably no more important relationship for a successful product manager than the one with your engineers.
If your relationship is strong, with mutual and sincere respect both ways, then the product manager job is great. If your relationship is not strong, your days as product manager will be brutal (and probably numbered). Therefore, this is a relationship worth taking very seriously and doing everything you can to nurture.
This strong relationship begins with you. You need to do your homework and bring to the team the knowledge and skills of good product management.
Engineers are typically smart and often skeptical by nature, so if you're bluffing, they likely won't be fooled. If you don't know something, it's much better to fess up and say you'll find out rather than try to bluster.
There's probably no more important relationship for a successful product manager than the one with your engineers.
It's also hugely important that you have an actual appreciation for the demands and complexities of the engineering job. If you were an engineer before or if you've studied computer science in school, you're probably in good shape. But if not, I want to strongly encourage you to take a class at a local community college or online education where you'll learn a programming language.
The purpose of developing this programming literacy is not so you start telling your engineers how to do their job but, rather, to significantly improve your ability to engage with and collaborate with your engineers. Less obviously, but at least as important, this knowledge will give you a much better appreciation for technology and the art of the possible.
It's also critical that you share very openly what you know about your customers—especially their pain—the data, and your business constraints. Your job is to bring this information to your team and then to discuss the various potential solutions to these problems.
There is nothing wrong with you bringing a strong point of view, but you must constantly demonstrate to your team that you're open minded, you know how to listen, and you want and need their help in coming up with the right product.
As a practical matter, you need to engage directly with your engineers every workday. There are typically two types of discussions going on each day. In the first type of discussion, you're soliciting their ideas and input for the items you're working on in discovery. In the second type of discussion, they're asking you clarifying questions on the items they're working on delivering to production.
Where a lot of product managers go sideways is in how they communicate with their engineers. Just as most product managers don't like it when an executive or stakeholder spells out exactly what they want you to build, engineers generally don't like it when you try to spell out how to build something. So, while it's good if you have a strong technology understanding, it's not good if you use that knowledge to try to do their jobs for them.
You want to give your engineers as much latitude as possible in coming up with the best solution. Remember, they are the ones who will be called in the middle of the night to fix issues if they arise.
One last thing to keep in mind: the morale of the engineers is very much a function of you as the product manager. It is your job to make sure they feel like missionaries and not mercenaries. You do this by involving them deeply in the customer pain you are trying to solve and in the business problems you face. Don't try to shelter them from this—instead, share these problems and challenges very openly with them. They will respect you more for it, and, in most cases, the developers will rise to the challenge.
The Tech Lead Role
There are, of course, many different types of engineers. Some focus on engineering the user experience (generally referred to as front‐end developers), and some focus on specific technologies (for example, database, search, machine learning).
Similarly, as with most other roles, there is a career progression for engineers. Many go on to become senior engineers, and some go from there to principal engineer or architect roles. Others move into more of an engineering leadership path, which generally starts with the tech lead role (aka dev lead, or lead engineer).
In general, from the product management perspective, any senior engineer is helpful because of the broad knowledge he or she brings that pertains to what is possible. However, a tech lead not only has this knowledge—and is responsible for helping to share this knowledge with the other engineers on the team—but the tech lead also has an explicit responsibility to help the product manager and product designer discover a strong solution.
Not every engineer or even senior engineer wants to participate in discovery activities, and this is fine. What's not okay is to have a team of engineers in which none of them wants to engage in discovery activities.
It is for this reason that the product manager and product designer work most closely with the tech lead. In some product teams, there may be more than one tech lead, which is all the better.
It's also worth pointing out that engineers often have different work styles, which is also true for many designers. The product manager needs to be sensitive to the best way to interact. For example, many product managers are happy to speak in front of a larger group, or even a group of senior executives, but many engineers or designers are not. It's important to be sensitive to this.
CHAPTER 13
Product Marketing Managers
Product marketing managers are a little different from the other members of the product team. This is not because they are any less important, but because the product marketing manager is usually not a full‐time, dedicated member of each product team.
Product marketing is most typically organized by customer‐facing product, by target market, or sometimes by go‐to‐market channel, especially for more established companies (e.g., enterprise, vertical, mid‐market). There are typically fewer product marketers than product teams, as such, they get spread across different product teams.
In the best tech product companies, product marketing plays an essential role in discovery, delivery, and, ultimately, go‐to‐market, which is why they are important members of the product team.
As you'll soon see, coming up with winning products is never easy. We need a product that our customers love, yet also works for our business. However, a very large component of what is meant by works for our business is that there is a real market there (large enough to sustain a business), we can successfully differentiate from the many competitors out there, we can cost‐effectively acquire and engage new customers, and we have the go‐to‐market channels and capabilities required to get our product into the hands of our customers.
Modern product marketing managers represent the market to the product team—the positioning, the messaging, and a winning go‐to‐market plan. They are deeply engaged with the sales channel and know their capabilities, limitations, and current competitive issues.
/> Product marketing is our critical partner in this.
Modern product marketing managers represent the market to the product team—the positioning, the messaging, and a winning go‐to‐market plan. They are deeply engaged with the sales channel and know their capabilities, limitations, and current competitive issues.
The nature of product marketing is a bit different, depending on the type of business you have and how your product gets to market. When you make products for businesses that are sold through either a direct sales force or a channel sales organization, it is a very significant and critical job to declare the positioning—by that we mean the market position the product must occupy, in addition to the messaging—digital/content assets, sales tools, and training that enable sales to effectively sell.
If your company has a sales organization, and you don't have a product marketing partner, then this responsibility likely falls on you as product manager. This can easily become a full‐time job. And given the cost of the sales organization, it's really not an option to ignore them. But, of course, if you're spending your day helping the sales organization, who is figuring out the product for these people to sell?
If your company sells directly to consumers, it becomes easy for the marketing teams to focus on clicks and brand at the expense of ensuring all the product work adds up to a successfully differentiated market position. This is important to the long‐term prospects of any company but also brings more meaning into all the work the product team does.
It is very much in your best interest to make sure you have a product marketing manager to work with, and it's absolutely worth your time to make sure you understand the market—and your product marketing colleague understands the product—well enough for each of you to be successful.
There are many important interactions throughout discovery and delivery, so it's worth making a special effort to develop and maintain a strong working relationship with your product marketing colleague. For example, ensuring the product team is getting good signal from a broad enough representation of the market. It also becomes important in the messaging and deciding on the go‐to‐market plan based on these early product signals.
Note here that I am talking about the modern definition of the product marketing role. I am not describing the old model wherein product marketing was responsible for defining the product, and product management was primarily responsible for working with engineering to deliver that product.
Having a strong product marketing partner does not diminish in any sense the product manager's responsibility for delivering a successful product. The best product marketing manager and product manager relationships understand their respective roles but realize they are essential to each other's success.
CHAPTER 14
The Supporting Roles
So far, we've talked about your role as product manager, and we've also talked about the designers, engineers, and product marketing managers you'll be working with very closely every day.
But there are other people in supporting roles you'll also work with. These people will probably not be dedicated solely to your team, as they are typically assigned to a small number of other product teams.
Now, you might not have any of the people I'm about to describe available to you. It really depends on the size and type of organization you work at. If you're at a small startup, you very probably will have none of these roles, and you will need to cover these activities yourself. But if you're at a company that has some or all of these roles, I want you to know why they exist and, most important, how to make the best use of these people.
User Researchers
As you'll soon see when we talk about how we do product discovery, we are continuously doing two kinds of rapid learning and experimentation. One kind of learning is qualitative, and the other is quantitative.
Especially with the qualitative learning, some of our research is generative, which is understanding the problems we need to solve; and some of our research is evaluative, which is assessing how well our solutions solve the problem.
User researchers are trained in this range of qualitative techniques (and some of them are also trained on the quantitative techniques as well). They can help you find the right type of users, craft the right types of tests, and learn the most from each user or customer interaction.
The key to tapping into the real value that these user researchers can provide is to keep in mind that the learning must be shared learning. You need to witness the insights first hand. More on this when we talk about the principles of product discovery, but while I want you to appreciate what user research can help you with, I don't want you to think you can delegate to them to do the learning and then send you a report.
If your company does not have user researchers, then your product designer will typically pick up these responsibilities for your team.
Data Analysts
Similarly, for quantitative learning, data analysts help teams collect the right sort of analytics, manage data privacy constraints, analyze the data, plan live‐data tests, and understand and interpret the results.
Sometimes, data analysts go by the name business intelligence (BI) analysts, and they're experts in the types of data that your business collects and reports. It is well worth making friends with your data analyst. So much of product work today is data driven, and these people can be real gold mines for you and your organization.
In some companies, especially those with a lot of data—such as larger consumer companies—this may be a full‐time role dedicated to a specific product team. In this case, the data analyst would be sitting and working alongside the product manager and product designer.
Data analysts help teams collect the right sort of analytics, manage data privacy constraints, analyze the data, plan live‐data tests, and understand and interpret the results.
If your company does not have any data analysts, then responsibility for this typically falls on the product manager. If this is the case, you'll probably need to plan to spend significant time diving deep into the data to understand your situation and make good decisions.
Test Automation Engineers
Test automation engineers write automated tests for your product. They have largely replaced the old‐style manual quality assurance (QA) people.
Now, it's very possible that your engineers are responsible both for writing software and for writing these automated tests. If that's the case, then you probably won't have many test automation engineers. But most companies have a blended approach in which the engineers write some of the automated tests (e.g., the unit level tests), and the test automation engineers write the higher‐level automated tests.
Whichever model your company has is typically up to the engineering leadership, which is fine. However, what's not okay is if your company doesn't have test engineers, and your engineers don't do the testing either, and they are looking to you as product manager to do the quality testing.
While it's true as product manager you want to make sure things are generally as you expect before things go live (acceptance testing), that's a far cry from being able to release with confidence. The level of test automation necessary to release with confidence is significant and a big job. It's not unusual in complex products to have multiple test engineers dedicated to each product team.
CHAPTER 15
Profile: Jane Manning of Google
I'm sure you have heard of Google's AdWords, and you may have also heard that this product is what fuels the Google empire. To be specific, as of this writing, AdWords is currently 16 years old, and in the most recent year alone, it generated well over $60B in revenue.
Yes, that's B as in billions.
What I'm guessing most of you don't know, however, is just how this industry‐defining product came to be. And especially how close this product came to never happening at all.
The year was 2000, and the hardest part about the AdWords project was simply getting an agreement to work on it. The core idea h
ad support from Larry Page, but the idea immediately encountered some pretty strong resistance from both the ad sales team and the engineering team.
Jane Manning was a young engineering manager asked to serve as product manager for this effort to try to get it off the dime.
The new sales team, under Omid Kordestani, was off to a strong start selling keywords to large brands and placing the results at the top of the search results. These results were highlighted as an ad but still very prominent—much in the style that had been done in search results at other companies, including at Netscape where Omid came from. Sales was nervous that this idea of a self‐service advertising platform would diminish the value of what the sales team was trying to sell (known as cannibalization).
And the engineers, who had been working so hard to provide highly relevant search results, were understandably very worried that users would be confused and frustrated by ads getting in the way of their search results.
Jane sat down with each of these people to get a deeper understanding of their concerns. Some were just plain uncomfortable with advertising. Others were worried about cannibalization. And yet others were concerned about potential user unhappiness.
Once Jane understood the constraints and concerns, she had the information she needed to advocate for a solution that she believed would address the issues, yet enable countless small businesses to get a much more effective advertising solution. Jane also was able to persuade one of Google's earliest and most respected engineers, Georges Harik, of the idea's potential, and he helped to bring along other engineers.