Chapter 2. The CORE Connective Skills of Product Management
Given the ambiguity around the day-to-day responsibilities of product management, it can prove incredibly difficult to pin down the skills that product managers must use in their work. This often results in product management being described as a mish-mash of the skills used in other, easier-to-define roles. A little bit of coding, a pinch of business acumen, some user experience design, and—voilà!—you’re a product manager.
As we discuss in this chapter, the connective work of product management requires its own set of connective skills. Defining this set of skills helps carve out a place for product management as a unique and valuable role, and provides much-needed day-to-day guidance for how product managers can excel at their work.
The “Hybrid” Model: UX/Tech/Business
Insofar as there is a commonly accepted skill model for product managers, it is often positioned as a three-way Venn diagram (Figure 2-1) between “business,” “tech,” and “UX” (user experience):
Figure 2-1. The “hybrid” product management Venn diagram, from Martin Eriksson’s “What Exactly Is a Product Manager”
I have seen a number of variations on this—sometimes “UX” is replaced with “design” or “people.” Sometimes “business” is replaced with “statistics” or “finance.” I recently saw a job listing from a major bank that asked for candidates who are proficient in “business, technology, and human”—which in no way sounds like a job listing written by and for sentient robots.
When used well, this model speaks to the connective nature of the product management role. If you happen to be working with a team of designers and developers to build products that solve business needs, you might find yourself standing in the middle of this very diagram. But the skills required to be a designer, a developer, or a business leader are very different from the skills required to create alignment between designers, developers, and business leaders. Although this model helps describe the roles and subject matter knowledge that you are likely to encounter as a product manager, it does not provide much guidance as to what exactly you are supposed to do about it.
The UX/Tech/Business model is further complicated by the vast variability of the product manager role between organizations. At a large enterprise, a product manager might be accountable for a specific product’s profits and losses but rarely work directly with developers or designers. At a high-growth startup, a product manager might be working in close collaboration with developers and designers, but remain largely insulated from financial decision making. From company to company, the people you’re working with can vary enormously, but it is always your job to connect and align those people.
The CORE Skills of Product Management: Communication, Organization, Research, and Execution
For all the variability in the product manager role across organizations, the skills required to succeed as a product manager are often quite similar (Figure 2-2): a product manager must be able to effectively communicate between stakeholders and users, organize the product team for successful collaboration, research new ideas and perspectives, and execute whatever day-to-day tasks are required for their specific role and team. These CORE connective skills constitute a new skill model for product managers that better reflects the real-world work of product management across organizations and industries.
Figure 2-2. The CORE skills of product management
What follows is a breakdown of the CORE skills of product management, with a guiding principle for each skill that speaks to the real-world behaviors and decisions that put these skills into action.
Communication
“Clarity over comfort”
Communication is far and away the most important skill for a product manager to develop and nurture. If you cannot communicate effectively between your team, your stakeholders, and your users, you will not succeed as a product manager. Great product managers not only tolerate, but actively enjoy, the challenge of creating alignment and understanding between different roles and perspectives.
The guiding principle for communication is “clarity over comfort.” The choice between clarity and comfort is a real one, and one that we are often faced with at the most important moments of our career. For example, you might find yourself attending a meeting in which a senior stakeholder makes a passing reference to a product requirement that has never come up in a formal planning meeting. Not wanting to call out this inconsistency—and not wanting to create an uncomfortable situation—you might decide to let it pass, assuming that when the product is launched you will be able to declare anything not included in the formal spec as definitively “out of scope.” But from the senior stakeholder’s perspective, your silence might be interpreted as a tacit agreement that the product scope has officially changed. The consequences of this lack of clarity could be trivial—or cataclysmic.
It is no accident that uncomfortable moments like this are often the ones that prove most impactful. Discomfort is often the manifestation of a lack of clarity. It is a valuable signpost that people might not be on the same page, or that expectations have not been clearly set. As a product manager, you cannot fear discomfort—you must actively work through it to get clarity for yourself and your team. We will discuss specific strategies for achieving clarity over comfort in Chapter 5, The Art of Egregious Overcommunication.
Organization
“Change the rules, don’t break the rules”
Beyond using their own personal communication skills, product managers must organize their teams to work well together. This is not (just) a matter of being an expert in product development methodologies—though somebody who has successfully led a team using one of these methodologies likely knows a thing or two about organizing. If communication skills come down to managing one-on-one interactions, organization is about operationalizing and scaling those interactions.
Not all individuals who excel as individual communicators are naturally gifted organizers. Product managers who lack organization skills , no matter how knowledgeable and charismatic they are , often become a bottleneck for their teams. They run around giving directions, unblocking team members, and resolving conflicts, but their teams are incapable of functioning without the product manager’s direct and constant intervention. Product managers who lack organization skills are happy to hear questions like “what should we be working on right now?” because these questions put the product manager in the utterly indispensable role of guiding the team’s day-to-day priorities and decisions.
By contrast, product managers who excel at organization see the question “what should we be working on right now?” as a sign that something is broken. They strive to ensure that everybody on their team will always know what they should be working on and why, without having to ask that product manager personally. When something goes wrong, organization-minded product managers don’t just ask “how can I solve this problem right now?” but also “how can I make sure this doesn’t happen again?”
The guiding principle for organization is “change the rules, don’t break the rules.” If an organizational process or practice is not helping achieve your team’s goals, it is your responsibility to work with your team toward changing that process or practice. Instead of breaking the rules for “special cases,” reflect on why the rules cannot accommodate these cases. How might you collaboratively change those rules to better account for new situations and changing circumstances? Great product managers are not afraid to challenge procedural orthodoxies if it will help their team meet its goals. We’ll talk more about this in Chapter 10, The Wonderful, Horrible Truth About Agile.
Research
“Live in your user’s reality”
In her excellent book Just Enough Research (A Book Apart, 2013), Erika Hall says that “research is just another name for critical thinking.” Indeed, critical thinking is a crucial piece of a product manager’s job—but just sitting back and being really smart is not enough. For a product manager, research is about seeking out and synthesizing multiple perspectives and sources of information. If curiosity is the key mindset of the product manager, research is how that curiosity is actualized and extended beyond the walls of the organization.
In theory, product managers should know their market and know their user. In practice, this is far from a given and often requires asking difficult questions and challenging deeply held assumptions within an organization. Great product managers never take anything for granted and are constantly seeking out new ideas, confounding variables, and challenging perspectives.
Research is a critical tool for attaining the subject matter knowledge that might be necessary for a specific product management role. At a tech startup, some knowledge of user experience and technology can come in handy for meeting deadlines and making trade-offs. A product manager at a company that primarily sells physical goods might want to study up on manufacturing and supply chains. It is always good to know as much as you can about product’s competitive landscape—but that landscape is always changing, and at an ever-faster pace. What’s important is not that you already possess the relevant subject matter knowledge for your specific role, but rather that you are actively seeking out any and all knowledge and information that might help you and your team succeed.
Product managers who lack research skills tend to lead their team steadfastly down a predetermined path, without taking the time to ask why they are pursuing that path, or seeking out new information that might compel them to adjust course. These product managers might be able to hit their specific deadlines, but they are constantly playing catch-up with their market and their users.
The guiding principle for research is, “live in your user’s reality.” Every product has a user—whether it’s a consumer, another business, or an engineer utilizing an API. The things that matter to you, such as hitting project deadlines, managing the product backlog, or balancing the profit and loss statement, do not matter at all to them. Your users have their own set of priorities, needs, and concerns, the most critical of which might not seem directly related to their interactions with your product. The most successful product managers I’ve met give voice not only to their users’ immediate, transactional “pain points,” but also to their broader and more complex realities. When these product managers evaluate a competitor’s product, they ask, “What might this product mean to our users,” not “How can we achieve feature parity?” By taking an open and holistic view, these product managers are able to identify previously unexplored solutions to fast-changing user needs. We’ll talk more about this in Chapter 7, Talking to Users (Or, “What’s a Poker Game?”).
Execution
“No work beneath, no work above”
Product managers are, of course, still responsible for making sure that stuff gets done. This often means stepping up to do whatever work is needed for your team, even if that work is not technically part of your job description. Execution-minded product managers not only provide critical support for their teams, they inspire everybody on their team to step up and do whatever needs to be done.
Product managers who lack execution skills often become bogged down in the theoretical underpinnings of product management. They are more concerned with finding the “perfect” product management framework than they are with actually getting a product released. They value thinking over doing. And by approaching their work this way, they implicitly devalue the contributions of their teammates who are tasked with actually building their products.
The guiding principle for execution is “no work beneath, no work above.” Execution-minded product managers are willing to take on work that might be seen as low-status in their particular organization, and actively elevate that work by modeling its importance. An execution-minded product manager, for example, will happily go on an early-morning coffee run if that is an important step toward actually getting a product out the door. As Google Ventures’ Ken Norton says, “always bring the donuts.”
When I started working as a product manager, I was prepared to do my share of donut and coffee runs. What I was not expecting was how many times I would need to step into conversations that felt above my proverbial pay grade. During one particularly tumultuous moment early in my career, I was made “VP for a day” so that I could lead a mission-critical negotiation with a major platform partner. Embarrassingly, I was much more focused on the fact that I had not been given a real promotion than I was on successfully leading this important negotiation. An execution-minded product manager is willing to step into critical, high-level conversations for the sake of clarifying and achieving organizational goals, not for personal glory. We’ll discuss this more in Chapter 6, Working with Senior Stakeholders (Or, Throwing the Poker Game).
…But What About “Hard Skills”?
The skills I have outlined in this chapter could be described as “soft skills.” Generally speaking, soft skills are considered to be the squishy, subjective, “interpersonal” skills that are difficult to quantify or measure. “Hard skills,” on the other hand, are considered to be fixed, objective, and measurable. For example, communication and time management skills are often considered soft skills, whereas computer programming and statistical analysis are considered hard skills.
In some contexts, hard skills are considered the absolute essentials to perform a job, whereas soft skills are considered a “nice to have.” And for some roles, there is a bar of hard skills that must be met—after all, you wouldn’t hire a computer programmer who had never written a line of code, or a dentist who had never attended dental school. But the absolute distinction between “hard” and “soft” skills is often deployed in a way that feels reductive, imbalanced, and unfair to both types of skills. Hard skills like programming still require nuance and craft, and soft skills like communication and time management can still be learned, practiced, and evaluated.
When it comes to product management, though, the distinction between soft and hard skills is particularly insidious. To put it bluntly, far too many people and organizations hire product managers based on hard skills that have precious little to do with the day-to-day work that those product managers will be expected to perform. I’ve seen fantastic product managers fail job interviews because they couldn’t whiteboard an algorithm or solve a code challenge, even if their day-to-day work will require them to do neither of these things. To this day, one of the most common questions I am asked by aspiring product managers is, “just how technical do I have to be?”
In an article titled “Getting to Technical Enough as a Product Manager,” Lulu Cheng provides a swift and definitive take on this issue:
The day-to-day responsibilities [of a product manager], and technical bar, varies widely depending on the industry and size of the company, as well as the part of the product you work on. At the same time, the qualities that make someone a universally respected PM rarely have to do with technical expertise.
Indeed, if you are working on a highly technical product, having a basic knowledge of the systems with which you are working will soften the learning curve and give you a head start. But any assessment of the required hard skills for a specific product management role should begin with the work that a product manager will be expected to do day-to-day—which, in most cases, is much more connective than it is technical.
So why does this focus on hard skills persist? Here are a few myths I’ve encountered and would like to debunk:
- You need hard skills to win the respect of technical folks
-
The idea that technical folks can respect only somebody who shares their skill set is, frankly, insulting to technical folks. If anything, I’ve seen product managers who “play” developer initially win over their technical counterparts, only to annoy the living crap out of them later by micromanaging implementation details. As we discuss in Chapter 3, communication skills will help you learn hard skills in a way that respects the expertise of your colleagues and the specific context of your organization.
- You need hard skills to challenge technical folks
-
There is a kernel of truth here—if you have no idea how technical systems work, your developers could tell you that something relatively easy to build will take a million years. But if your team is flat-out lying to you about how long things will take, you have a more fundamental problem on your hands. Product managers with excellent execution skills inspire their teams to want to get stuff out the door quickly, and they don’t do it by playing “gotcha” with technical specificities.
- You need hard skills to stay interested and engaged with technical work
It is absolutely true that a product manager who is disinterested in the work of their colleagues is likely to fail. But knowledge and interest are two very different things, and I’ve found that many of the most technically knowledgeable product managers are also those least interested in learning new things and engaging deeply with the work of their colleagues. The best product managers, regardless of their hard skills, are able to take a genuine interest in the technical work of their colleagues and draw compelling connections between technical work, user needs, and business goals.
- You need hard skills to do things like query databases, write documentation, and push minor changes
-
In many cases, this is actually 100% true. In keeping with the idea that “if it needs to get done, it’s part of your job,” product managers often find themselves faced with technical tasks that do require some hard skills. For example, at a small company, a product manager might be asked to make minor code changes (such as updates to website copy) without enlisting the help of a developer. This will likely require the product manager to develop some basic familiarity with the programming language used by their team, as well as the tools that their team uses to deploy code.
The challenge here is not so much for a product manager to be “technical,” but rather to be comfortable exploring and learning about technical as well as nontechnical concepts. I have seen nontechnical product managers excel in highly technical organizations when they approach technical challenges with openness and curiosity, and I have seen nontechnical product managers falter in relatively nontechnical organizations because they see technical work as either uninteresting or unapproachable. The best product managers are just as curious about technical concepts as they are about nontechnical concepts. We discuss this in Chapter 3, Showing Up Curious.
Summary: Changing the Conversation About Product Management
Because product management is a relatively new discipline and because the role can vary so much from organization to organization, it is tempting to describe product management as a hybrid of other roles. Unfortunately, this approach often results in a mismatch between what makes a product manager look good on paper (e.g., “a designer who knows some code” or “a developer with an MBA”) and what makes a product manager successful in their day-to-day work. I hope that the CORE skills model will change the conversation about product management in theory to something that better aligns with the day-to-day work of product management in practice.
Your Checklist:
Embrace the uniqueness of the product manager role. Don’t try to be a designer, a developer, or a business analyst—and don’t confuse the skills needed to excel at those roles with the skills needed to excel at product management.
Pursue clarity over comfort to build your communication skills.
Seek out opportunities to solve organizational problems on the systemic level rather than the individual level. If the rules aren’t working, change them, don’t break them.
Don’t let the day-to-day organizational conflicts of your work pull you out of your user’s reality. Remember that what your company cares about and what your users care about are different things, and be a relentless advocate for the latter.
Remember that there is no work beneath you, and no work above you. Be willing to do whatever it takes to help your team and your organization succeed.
Even if you don’t self-identify as a “technical” person, avoid saying things like “I’m not a technical person, so I could never understand that!” Trust in your own ability to learn and grow.