3 types of knowledge a product manager should seek
The most successful product managers quickly develop three domains of knowledge: organizational, product, and industry.
"Pool of Knowledge" sculpture by Stacey Spiegel (source: Ian Muttoo on Flickr)
Anywhere you go, successful product managers are relentless in their pursuit of knowledge, although the kinds of knowledge that matter—and how to obtain that knowledge—vary. We recommend thinking about your research and expertise as an enterprise product manager as falling into three distinct categories: organizational knowledge, product knowledge, and industry knowledge.
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, whereas 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?
Learn faster. Dig deeper. See farther.
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 an 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 important, 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 important, 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 might 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 (we hope!). 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:
- Organizational knowledge
-
This refers to understanding how your company really works. Because 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 that you 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.
- Product knowledge
-
Product knowledge means knowing the ins and outs of your 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 that we know enough to be able to empathize with users to help create solutions to their problems. If we don’t understand the product, it’s difficult to empathize with end users who do.
- Industry knowledge
-
This 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 dive deep into what each type of knowledge really means 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 might be one of hundreds or thousands or even hundreds of thousands of employees who contribute to your company’s success, each in their 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 generation and product marketing, in many cases); often, you can add accounting and finance as well, not to mention the international teams that frequently operate more or less independently from their counterparts at headquarters.
Do you 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 is asked 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 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 be 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 difficult to be truly successful as a product manager without a deep knowledge of the product itself.
There are primarily two nonobvious reasons to pursue product knowledge. The first of these is empathy.
Let’s look again at the example we just presented 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 can 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 might not have all of the answers. We frequently have customers teach us a thing or two about our own products!
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 difficult 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 data points goes a long way toward building trust among those teams, especially as it relates to combating misinformation with accurate product information. Without product knowledge, you might not be able to answer the questions “Can our product do that, too?” or “How should I interrogate 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 can 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
Although organizational knowledge and product knowledge are tremendously valuable, we have to admit that if we 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 multifaceted 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 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, you need look only 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, and so on 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 on which five of those features the company should focus.
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 need to make some cuts, and there might 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 might find this easier than someone who has been a product manager previously but in a very different space.) In not available, which covers industry knowledge, we 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 might 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 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 might 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 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. Although 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, communication might 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, in this section, we give you some guidance to help you to 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.
Suppose that you want to get your sales and development teams to buy into the vision that you’re 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 difficult 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 of achieving it. You might even call out specific competitors and explain why your vision will put them in their graves.
If you’re 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 can 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, and so on.
Note that it’s the same core message in both cases, but the way you convey the message might 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 it’s 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 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 begin 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 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, and perspectives. In fact, the scope of your customer communications is so broad that we cannot cover all of the possible situations in which you might 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:
- Become 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 might be targeted at a specific industry such as financial services, which makes this a bit easier (although every industry has subindustries within it), but if you make general-purpose software, familiarizing yourself with each industry’s market drivers, challenges, and 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 might 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 might 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 might 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 can 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 might not have been your fault.
- Be honest and forthright about your product’s limitations
-
This one might 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 in 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 will have booked the sale long before that happens. If nobody else is going to do it, you need to be responsible for the long-term relationship. Being clear and straightforward about what you produce adds to your credibility and sets the stage for your customers to be successful with your product.
Summary
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 into which we sell. 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 explore each area individually.