Product Management in Practice: A Practical, Tactical Guide for Your First Day and Every Day After

by Matt Lemay

I’ve started thinking about the ever-expanding list of “pro**** ******er” titles as Ambiguously Descriptive Product Roles (ADPRs), in the interest of having a banner concept to encompass the myriad job titles that likely won’t tell you all that much about your day-to-day activities and responsibilities. For ADPRs whose teams include other ADPRs, I find myself offering the following, similarly disappointing advice: “Sit down with your fellow ADPRs, figure out what needs to be done, and figure out how you’re going to do it together. Focus on your shared efforts, rather than trying to establish absolute nonoverlapping clarity around your titles.”

As an ADPR, you will likely never have absolute clarity about what exactly your job entails. Ask lots of questions, work closely with your team, and stay focused on doing the most impactful work you can.

🙌🏾

Long story short: every single product job on every single team at every single company is a little different. The sooner you truly embrace this, the sooner you can get to the hard work of doing your specific product job as best you, specifically, can.

Accept that being a product manager means that you are going to have to do lots of different things. Don’t become upset if your day-to-day work is not visionary and important seeming, so long as it is contributing to the goals of your team.

Be proactive about seeking out ways that you can help contribute to the success of your product and your team. Nobody is going to tell you exactly what to do all the time.

Get out ahead of potential miscommunications and misalignments, no matter how inconsequential th...

Don’t get too hung up on the “typical profile” of a successful product manager. Successful product ma...

Don’t let insecurity turn you into the caricature of a bad product manager! Resist the urge to defensively sh...

Measure your success by the impact you’re having on your business, your users, and your team—not h...

Stop looking for a single “correct” definition of any Ambiguously Descriptive Product Role (such as product manager, product owner, or program manager). Acknowledge the uniqueness of each product role on each team and ask a lot o...

If your team has multiple Ambiguously Descriptive Product Roles (say, a product manager and a product owner), work with your fellow ADPRs to align on your shared goals and figure out how ...

the connective work of product management requires its own set of 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.

Insofar as there is a commonly accepted visual representation of product management, it is a three-way Venn diagram (Figure 2-1) that positions product management at the intersection of business, tech, and UX (user experience).

I was working at a startup as a VP of product—basically the first real product person in the business. We were experimenting a lot with “How do we build cross-functional autonomous teams?” though we didn’t quite call it that at the time....I was thinking about, “What are the things that we need in our teams to be successful and build great products?” And the most important things are those three elements—some sense of the customer, the user experience, some sense of the business aspect. How do you make that valuable and capture that value, and how do you work with engineering to actually deliver that and make sure it’s something that’s feasible to build?

Indeed, you will rarely encounter a product manager whose work doesn’t involve some element of understanding their users and/or customers, some element of understanding their business, and some element of understanding whatever it is they need to understand to help their team actually deliver something that enhances the value exchange between the business and its customers. When I started out as a product manager, this visual helped me understand that I had a unique place in the world. Not as an engineer, a designer, or a business analyst, but as a different kind of person who connects and aligns these disparate roles to help my team succeed.

“Product is at the intersection of those three things, but that doesn’t mean we have to have all the answers or be experts in any one or all three of those.”

Indeed, the skills required to be a designer, a developer, or a business analyst can be very different from the skills required to create alignment among designers, developers, and business analysts. This Venn diagram can help describe where you are as a product manager, but—as with any single model or description—it can’t tell you everything about what you’re supposed to do there.

At a large, regulated enterprise, a product manager might spend most of their time connecting and aligning between lawyers and account managers. At a new startup, a product manager might spend most of their time connecting and aligning between the company’s founder and an external vendor who has been hired to build the initial version of the company’s product.

A product manager must be able to: Communicate with stakeholders Organize the product team for sustainable success Research the needs and goals of the product’s users Execute the day-to-day tasks required for the product team to meet its goals

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 that put these skills into action.

Communication Clarity over comfort.

Great product managers not only tolerate, but actively enjoy, the challenge of creating alignment and understanding between different people with different experiences and perspectives.

Discomfort is often the manifestation of a lack of clarity. It is a valuable signpost indicating that people are not 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.

I want to emphasize here that good communication does not mean “choosing fancy words and speaking in an impressive manner.” Many of the product managers I talk to—especially those who self-identify as introverts or who are working in a language that is not their first—fear that they are operating at an intrinsic disadvantage when it comes to developing communication skills.

Am I asking the necessary questions and facilitating the necessary conversations to make sure my team has clarity on what we are doing and why?

Am I proactively reaching out to other product teams and managers if I believe that coordination will help deliver better user and business outcomes?

Am I responding promptly and thoughtfully to stakeholders w...

When exploring potential solutions, am I consistently presenting multiple options and walking stakeholders thr...

Organization Make yourself obsolete.

Beyond using their own personal communication skills, product managers must organize their teams to work well together. If communication skills come down to managing personal 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 th...

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 them personally. When something goes wrong, organization-minded product managers don’t just ask,

The guiding principle for organization is “Make yourself obsolete.” Product managers who excel at organization work with their teams to organize people, processes, and tools into self-sustaining systems that do not require their moment-to-moment participation or oversight.

Here are a few questions you can ask yourself to evaluate your organization skills:

If I were to go on vacation for a month, would my team have the information and processes in place to prioritize and deliver without my day-to-day participation?

If I were to ask anybody on my team, “What are you working on and why?” would they all have immed...

If somebody on any other team wanted to know what my team was working on, would they be able to easily access that information in ...

If a particular process or system (or lack thereof) is not working for my team, am I proactively working with my team to change that process or system? Or, if we are not in a position to directly change that process or system, am I proactively working ...

Research Live in your user’s reality.

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 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 most successful product managers I’ve met understand not only how users interact with their product but also how the product fits into users’ broader reality. 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?”

Here are a few questions you can ask yourself to evaluate your research skills:

Is my team learning directly from our users/customers at least once a week? (This is Teresa Torres’s most excellent definition of continuous discovery.)

Is every product decision my team makes informed by both business ...

Is my team regularly using both our product and competing/adjacent products to better understand ou...

Do the user needs and goals articulated by my team actually reflect the needs and goals of our users, or just what the busines...

Execution All efforts in service of outcomes.

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 to achieve its goals, even if that work is not technically part of your job description. Execution-minded product managers start by understanding the business and user outcomes for which their teams are responsible, then ruthlessly prioritize their time, resources, and activities to deliver against those outcomes.

Because execution-minded product managers prioritize their efforts against goals and outcomes, they are willing to take on work that might not be seen as particularly heroic or high status. An execution-minded product manager, for example, will happily go on an early morning coffee run if that is an important step toward getting a product out the door.