Sample Chapter

Chapter 3: Three Types of Knowledge for Product Managers to Seek

Congratulations on your hire or promotion into the role of Product Manager! If you’re like most new Product Managers, you’re full of energy and zeal, ready to conquer the world through sheer grit, determination, and lots of sugary treats or booze carts for your developers. (Blair prefers bourbon and gummy worms, while Ben goes for ice cream. To each PM, their own.) You’re instantly going to win over your colleagues and ship great product features with all of the passion you bring to your company. Right?

Well, sort of. Zeal is an important aspect of successful product management. When you’re communicating a vision and arguing to resource your roadmap in a particular way that supports that vision, passion is critical. This isn’t to say that you should be standing on (or throwing) chairs, or raising your voice, but believing in your own message and making it clear how much you care about it is key. When everyone in your organization can see how strongly you believe in whatever you’re trying to get built, it’s much easier for them to rally around you than if you make a emotionless but correct argument. One of our favorite quotes about a Product Manager from one of his colleagues was, “When I see how passionate [our Product Manager] is about our product and company, it makes me excited for our future.”

But the energy that you bring to your team as a new Product Manager isn’t enough. We have seen new Product Managers — new to the product management function, a company, or to an industry itself — who have overextended themselves on passion alone or lacked the concrete knowledge required to be truly effective, and more importantly, failed to develop either. The danger in this common scenario is that a Product Manager’s influence needs to be wielded selectively, and zeal without knowledge can lead to disaster; for your company, for you, and perhaps most importantly, for the trust others place in you.

Imagine that you, as a new Product Manager, are put on a highly visible project and told to make it go. You can rally the engineers and the sales reps with your passion, but how do you know that you’re solving the right problem in the right way? It is tempting to assume that your customers must be like you, or that you can guess the things that keep them up at night, or that you will be able to drive the project to success on the back of your own energy. You may be right some of the time. Remember that in your role as “key influencer,” the ability to bring both zeal and knowledge to bear on your audience is critical. But without putting in the work to obtain actual knowledge, unnecessary failures will litter your path.

So, what knowledge are we talking about? Glad you asked.

Three Categories of Knowledge

You’ve got zeal in spades (I hope–you’ll need it). So how should we think about acquiring the knowledge necessary to ship fantastic products and ensure that they solve actual customer problems?

We propose that you approach this question by dividing it into three categories.

  1. Organizational Knowledge refers to understanding how your company really works. Since we need to get the right people behind every major decision we’re pushing, we need to learn who those people are and about their motivations and incentives. Don’t assume you already know all of this already. This kind of institutional knowledge tends to be vastly more important for enterprise software companies, which tend to be bigger, older and perhaps more bureaucratic.
  2. Product Knowledge means knowing the ins and outs of our product: its limitations, its benefits, what users love about it, and what they hate about it. Techies tend to fetishize all the minute technical details of their products, and that’s not necessarily what we mean here – rather, it’s more important is that we know enough to be able to empathize with users in order to help create solutions to their problems. If we don’t understand the product, it’s hard to empathize with end users who do.
  3. Industry Knowledge is arguably the most important of these three areas of knowledge because it represents a deep and thorough understanding of customer problems that remain unsolved (or inadequately solved) in your market, or adjacent/similar markets, today. It’s through this domain that we recognize the largest market opportunities.

Over the next several chapters, we’re doing to dive deep into what each of these types of knowledge really mean for you as a Product Manager. For now, let’s just briefly explain each area of knowledge and discuss how we can obtain them.

Organizational Knowledge

As we’ve discussed, it is often very difficult for startups to crack the enterprise software space, meaning that the dominant enterprise software vendors tend to be large organizations. As a result, you may be one of hundreds or thousands or even hundreds of thousands of employees who contribute to your company’s success, each in his or her own way. It can seem like a maze of directory listings impossible to parse, even if you’ve been at the company for years–let alone if you’re a new employee. How does an individual navigate this landscape?

The simple answer is that an enterprise Product Manager does (almost) nothing alone.

Want to ship a feature? Great. At minimum, you’ll need to align engineering, operations, sales, support, design and marketing (both demand gen and product marketing, in many cases); often, you can add accounting and finance to boot, not to mention the international teams that frequently operate more or less independently from their counterparts at headquarters.

Have a critical customer escalation that you need resolved today? Okay. Who has the answer? The documentation team? Support? A partner? Where do you go to find immediate help?

A simple example from our own experience illustrates this last scenario. At Adobe, Ben frequently gets time-sensitive questions from sales or account teams. In many cases, he doesn’t know the answer to the question. And that’s okay! Rather than throw up his hands in frustration, and risk unnecessary delay or even losing a deal or customer, his knowledge of the organization is such that he invariably knows the right person, or at least the right team, to answer the question. Much more often than not, Ben is able to steer the request to the best possible respondent within a matter of minutes. It means more than merely knowing that there is a support team or a documentation team–it means knowing which member of those teams has the information we need, which members would be willing to get involved in the situation, and which members are good enough at communicating sometimes tricky answers to potentially introduce them to a customer directly.

In another example, a Product Manager that we know set out to improve the customer experience around implementing a particular software solution. The engineering team with which she was most closely aligned didn’t have any available resources to work on the problem. But by interviewing colleagues who had a bit more organizational knowledge, she learned of two engineering teams halfway around the world whose incentives and motivations happened to be perfectly aligned with what she was trying to do. These teams, which would have been completely invisible to someone without any organizational knowledge, turned out to a much better fit to work on the project than her own group of developers.

How does one obtain organizational knowledge? In many ways, this is the most difficult of the three types of knowledge that we will discuss, because it can simply take time. Not only does it require an understanding of the (often international and frequently poorly documented) organizational structure, but it also requires a sort of social graph: who works on what projects, who knows what information, etc. More subtly, it requires you to understand motivations and incentives: what does each individual (and team) want, and why? That can be almost impossible to learn without experience, plain and simple. Organizational knowledge is often a function of tenure. But there are some simple strategies for speeding up the process that we will suggest.

Product Knowledge

It should go without saying that it’s hard to be truly successful as a Product Manager without a deep knowledge of the product itself.

There are primarily two non-obvious reasons to pursue product knowledge. The first of these is empathy.

Think back to the example discussed above, in which a Product Manager was seeking to improve the implementation experience for a particular product. How much more powerful would her arguments and design influence be after she had actually implemented the product herself, and gone through the steps that she was trying to improve? How much easier would it be for engineers, sales reps, marketers, and others to trust a Product Manager who understood from personal experience what works and what doesn’t work for users?

Empathy may be the most important skill for a Product Manager to develop, because it is what makes the difference between thinking you solved a customer/user problem and actually solving that problem. Without it, you will find yourself skewing toward solving your own problem, not your customer’s problem. Among the very best ways to develop empathy is to put yourself in your customer’s shoes and evaluate your product, learning its benefits and shortcomings.

The second reason to pursue product knowledge is trust–specifically, earning the trust of customers and the trust of your development, sales and marketing teams (among many others).

Product knowledge does not mean being a walking encyclopedia of every minute detail of your product. We have always found customers and internal teams to be understanding of the fact that, especially in enterprise software, where extensive customization is so common that no two deployments behave exactly alike, Product Managers may not have all of the answers. We frequently have customers teach us a thing or two about our own products!

However, that having been said, both customers and internal teams need your help in order to use and sell your product, respectively. When customers see that you understand your product deeply, and can relate both general information and specific use cases that speak their language, they become much more willing and likely to open up and share with you their problems and concerns, which is perhaps the most important input you can receive as a Product Manager.

Similarly, internal teams provide you with market insight that can be hard or impossible to achieve any other way: trends they are seeing in the deals they are working on, or new competitors sprouting up in your space with compelling offerings. Your ability to contextualize these datapoints goes a long way towards building trust among those teams, especially as it relates to combating misinformation with accurate product information.Without product knowledge, you may not be able to answer the questions “Can our product do that, too?” or “How should I deposition what our competitor is claiming?” When you answer these questions accurately, based on your product knowledge, you begin to win the trust of groups that may become your best allies in creating winning products in the future.

Fortunately, product knowledge is the most practical of the types of knowledge discussed. You can obtain it in a number of ways, and (depending on the complexity of your product), often in a matter of weeks or months rather than years.

Industry Knowledge

While organizational knowledge and product knowledge are tremendously valuable, we have to admit that if you had to pick one type of knowledge to be successful in Product Management, we’d pick industry knowledge. Of the three types, it is most directly associated with the ability to deliver successful products that will grow your company’s revenue.

Industry knowledge breaks down into a few categories, but generally we mean having a subtle and multi-faceted understanding of the trends that drive buying decisions in the marketplace where you compete, the up-and-coming solutions to current (and future!) customer problems, and of how those customer problems vary by industry in your customer base.

In short: know the problems your customers are facing, and know why they are valuable problems to solve. Customer problems are the “currency” of product management. The better you understand them, the richer you are.

To illustrate the importance of market knowledge, one only needs to look as far as a product backlog. If you have one already, we’ll bet that it has far more on it than you can possibly solve with the time, engineering resources, marketing resources, etc. available to you. If you do not have one yet, imagine a list of 200 product features or process improvements, all of which are valuable. Now imagine being asked which five of those features the company should focus on.

If you understand what is driving purchase decisions, and what problems keep your customers’ C-suites up at night, prioritizing that backlog won’t be as much like picking which baby you love the most; you’ll have to make some cuts, and there may be some choices that are roughly equivalent, as well as some downrange trade-offs to consider, but it can be done. Without market knowledge, you may as well throw darts at a dartboard. (Just remember to keep the bourbon for after that meeting, please.)

Industry knowledge is what allows you, as a Product Manager, to write a Market Requirements Document (MRD), which sets the vision for your product, lays out the core tenets of the product strategy, and essentially answers the question: “What is the market in which we operate going to require of us in order for us to grow our business?”

Perhaps because it is the most strategic of the three types of knowledge discussed in this chapter, it can also be the most difficult and time-consuming to obtain for those who are new to the given market. (If you are moving into a product management role from within the same industry, you may find this easier than someone who has been a Product Manager previously, but in a very different space.) In the chapter on Industry Knowledge, we’ll talk about how you should get started on it, as well as several things that we wish we’d have known at the beginning.

You may have heard it said that product management is mostly a “soft skills” position. Among the many soft skills required, passion and knowledge are two of the most fundamental. Without both, a Product Manager will be hard pressed to influence the kind of change that he or she is uniquely positioned to enact. To some extent, passion is something that is impossible to teach. If you’re not excited about the business you are guiding, you may want to find a new business. You can, however, obtain knowledge.

It Starts With Communication

The product manager is ultimately responsible for bringing disparate teams together, getting them bought into his or her product vision, and keeping teams (and often customers) aligned both before and after the release of a product or feature. Ensuring that this process goes as smoothly as possible, often in large and complex organizations, requires great (not just good) communication. While there are many skills you will want to develop as a product manager, those related to communicating ideas will be among your most valuable; in fact, it may be the most important factor leading to success in enterprise product management. And because great communication can be a bit more challenging in this type of software company, we will give you some guidance to help you get started.

The term “communication” can mean all kinds of different things. We are not talking about communication narrowly, such as the ability to write a coherent email, or to execute a decent roadmap presentation to a customer, although those are both part of it. More broadly, we mean the ability to communicate difficult concepts clearly in different ways to different functional audiences (development teams, sales teams, marketing teams, customers, industry analysts, etc.) via different mediums.

Product management sits at the crossroads between a dozen different internal teams as well as customers, partners, and other external entities. Nobody is better positioned than you are to bring these teams together to achieve something great. But each of these groups (including product management itself!) has its own incentives, goals, hopes, fears, habits, traditions, and processes. This means that not every group responds to the same stimulus in the same way.

Let’s say you want to get your sales and development teams to buy into the vision you are setting for your product. The way most enterprise salespeople are compensated, they are typically focused on short-term bookings objectives, living quarter to quarter or year to year. (And, by the way, this is actually a good thing.) Your product vision matters to them primarily because it’s what gets prospects excited about their future relationship with your company; but how hard it will be to achieve that mission matters much less, provided you have something on the roadmap that they can talk about. Great engineers (the ones you really need to buy in to your vision) are, by necessity, more pragmatic thinkers who will immediately wonder how to get from point A to point Z in a reasonable timeframe. Your vision matters to them because it frames how they will solve problems along the way toward achieving that vision, and when they believe the vision is realistic, they will apply their understanding of it to every problem that they solve.

If you are communicating this vision to your sales team, you will often do it by talking about it in the broadest possible terms and pithy statements that sound amazing but leave the door open for them to explain it however they want. You will likely talk about how unique this vision is, and how your company is the only one capable for achieving it. You may even call out specific competitors and explain why your vision will put them in their graves.

If communicating that same vision to the development team, you will likely boil it down to specifics: how we are going to achieve the vision, and when we are hoping to reach checkpoints along the path. Your development team probably doesn’t care that much about the competitive landscape (nor should they; it can benefit them very little), or why your company is uniquely positioned to make this vision reality. They care that it is the right thing to do, that it solves an interesting problem, and that it makes sense.

The way you have these conversations (and others like these) will often be completely different, and what resonates with your sales reps may be sanskrit to your engineers (and vice versa). The questions you get from each group will also reflect that group’s experience, knowledge, goals, biases, preferences, etc.

Note that it’s the same core message in both cases, but the way you convey the message may be wildly different from one audience to the next. But, of course, you cannot succeed without these (and other) groups being aligned and bought in. And is primarily up to product management (with the help of other groups, like product marketing) to create that alignment. Thus, you need to become great at tailoring the message to the audience.

Throughout this book, we’re going to return to best practices for communicating with different teams throughout your organization: Development, Marketing, Sales, Leadership and more, because communication is such a vital skill to any successful Product Manager. But let’s start off with some quick tips for the group that matters most: customers.

Communication isn’t just for internal teams! As a product manager, you should be spending a considerable amount of time speaking directly with customers (and when we say “customer,” we will include prospects and former customers in this group as well). Communicating with them is different for obvious reasons: they aren’t part of your company and have their own very different incentives, motivations, etc. In fact, the scope of your customer communications is so broad that we cannot cover all of the possible situations where you may be “in front of” customers needing to figure out the right way to speak and listen. But here are some general guidelines to frame how you approach these interactions.

  • Get comfortable with different industries. One of the best things you can do when speaking with a customer is convey at least a basic understanding of the challenges facing them in their industry. Your software may be targeted at a specific industry, such as financial services, which makes this a bit easier (although every industry has sub-industries within it), but if you make general purpose software, familiarizing yourself with each industry’s market drivers, challenges, key use cases will help customers trust that you have their needs in mind as you are designing and shipping software. It also helps them grasp the value of what you may be sharing with them. Making a publisher think about how to apply a story you tell about an ecommerce brand only creates a barrier to value recognition. You don’t need to be a true thought leader in any one industry, but speaking the language will go a long way toward building trust.
  • You will overestimate how much your customer understands your company. Remember that most software companies look healthy from the outside. They tell stories of amazing things that their customers are doing, and publish press releases when software ships. From where you sit, you may see nothing but dysfunction and decay, but your customers cannot see “how the sausage gets made” unless you tell them. Even when you are feeling discouraged and desperate, convey optimism and confidence in your communications with customers.
  • Never blame another internal team. Along those same lines, there may be times when something goes wrong (a product bug, a missed ship date, an unexpected limitation, etc.) and you are tempted to lay it out for the customer the way you see it. Transparency is good — in fact, it may be one of the best things you can do in your interactions with customers — but blaming another internal team for whatever is frustrating the customer is not. It suggests to the customer that your company is not united and snipes at one another rather than coming together to do what is best for your clients. Even when another person or team really is at fault, presenting a united front to the customer means either refusing to assign blame or creatively “hoarding blame” for something that may not have been your fault.
  • Be honest and forthright about your product’s limitations. This one may sound counterintuitive; we want the customer to buy the product, don’t we? Then why would we talk about limitations? Enterprise customers want a partner whom they can trust. Salespeople have an obvious agenda, which is to sell software. You have an opportunity to represent yourself as someone who is open, who isn’t coin-operated, and who is looking out for the customer’s long-term best interest. The thing to remember here is that your customer is likely to find out your product’s limitations anyway; an immature (but common) approach to sales would be for the rep to say that he or she will have gotten the booking done long before that happens. If nobody else is going to do it, you have to be responsible for the long-term relationship. Being clear and straightforward about what you product doesn’t do adds to your credibility and sets the stage for your customers to be successful with your product.


All good Product Managers bring enthusiasm into their roles, but the most successful ones are those who manage to quickly develop three domains of knowledge: Organizational, Product and Industry. These three domains encompass a wide range of understanding about the companies we work in, the products we build and sell, and the industries we sell into. Some of these are easier to develop, and more critical to success, than others – but it is at the confluence of all three that true Product success lies. The next several chapters will explore each area individually.