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, but more likely just for you, and how the organization trusts 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. But without putting in the work to obtain actual knowledge, unnecessary failures will litter your path.
Remember that in your role as “key influencer,” the ability to bring both zeal and knowledge to bear on your audience is critical.
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.
- 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 many orders more important for enterprise software companies, which tend to be bigger and older.
- 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.
- 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. This is recognition of the largest opportunities comes from.
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.
As we’ve discussed, it is often very difficult for startups to crack the enterprise software space. As a result, you may find yourself doing enterprise product management within your own enterprise–one of hundreds or thousands or even hundreds of thousands of employees who contribute to 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 do?
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, 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 in your own office.
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 organization 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, who 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.
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 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, the trust of customers and the trust of your sales and marketing teams (although you may also win the trust of other groups as well, and that is a good thing).
Product knowledge does not mean being a walking encyclopedia for 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!
That having been said, however, 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 case 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. A huge part of how they learn to trust you with their perspective is learning to rely on your ability to contextualize it and help them understand how to correctly answer product questions or combat misinformation in the marketplace. 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.
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 probably won’t be 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, and 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, and 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 do. 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.
In this chapter, we’ve explained three kinds of knowledge: organizational knowledge, product knowledge, and industry knowledge that provide the rough schema for the rest of the book. There are many other categories of knowledge that will help you in your role as a Product Manager, but these three are common to every successful enterprise Product Manager we’ve ever seen. There certainly are other critical types of knowledge to acquire as a Product Manager, but if you’re working on these three, you’re off to a great start.
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 be deep-dives into each area individually.