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

by Matt Lemay

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.

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

Is my team starting with the customer and business impact we seek to drive and then evaluating and prioritizing multiple ways to achieve that impact, as opposed to starting with features and...

Are my team’s strategic goals and objectives front and center during tactical conversations and activities (like spri...

Am I prioritizing my own time in a way that reflects the goals and p...

If I do not have the capacity to do the work that my team needs without burning myself out, am I communicati...

Generally speaking, soft skills are considered the squishy, subjective, interpersonal skills that are difficult to quantify or measure. “Hard skills,” on the other hand, are considered fixed, objective, and measurable.

In some contexts, hard skills are considered the absolute essentials to perform a job, whereas soft skills are considered a “nice to have.”

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 require nuance and craft, and soft skills like communication and time management can be learned, practiced, and evaluated.

When it comes to product management, though, the distinction between soft and hard skills can be particularly harmful. 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 would require them to do neither of these things.

For most software product managers, the particular “hard skills” that cause the most anxiety and consternation are technical skills. To this day, one of the most common questions I am asked by aspiring pr...

The day-to-day responsibilities [of a product manager], and technical bar, vary 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.

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 alienate them later by micromanaging implementation details.

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 get impactful 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 uninterested 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 technical 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 tasks that do require some specific knowledge of programming languages, version control systems, or database logic. 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 prod...

The challenge here is not to be an expert in technical concepts 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 unap...

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.

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.

Remember that being a great communicator doesn’t mean “using fancy words and talking in a way that seems to impress people.”

Recognize that creating clarity for yourself and your team will require navigating a lot of uncomfortable conversations. Learn to treat discomfort as a valuable signal of potential misalig...

Seek out opportunities to solve organizational problems on the systemic level rather ...

Don’t let the day-to-day demands 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 thin...

Remember that there is no work beneath you and no work above you. Be willing to do whatever it takes to help your te...

Prioritize all your efforts against the outcomes your team is respon...

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!” Tru...

When people ask me how product managers can earn the trust of developers, or data scientists, or compliance officers, or any other person with a specialized and distant-seeming expertise, my answer is: take a genuine interest in the work that they do. “I’m curious to learn more about the work that you do” is the most powerful sentence at your disposal as a product manager, whether it’s your first day or you’ve been working in the field for decades.

🙌🏾

A simple gesture of curiosity can have an enormous and immediate positive impact on your work as a product manager.

Understand “hard skills” contextually. No matter how much time you spend trying to learn “hard skills” such as data science or programming, you will never keep pace with the people whose actual job is to use those skills. You will learn more by asking those people about their work than you will by reading a book about data science or Python and then showing up to work trying to “talk the talk.” Learning about hard skills from the people tasked with applying those skills ensures that you will learn about the specific hard skills that are most important to your organization right now—and that you’re doing so in a way that directly strengthens your bond with technical folks.

Build bridges before you need something. If you only talk to people when you need something from them, nobody will be particularly happy to hear from you. Build relationships with people before you need something from them, and those relationships will be there for you when you need them.

Expand your network of trust. The people you reach out to each have their own networks of trust—people they talk with “off the record” and from whom they are willing to call in favors when needed. By reaching out to folks in your organization beyond the people you are working with every day, you’re building a far-reaching network that might lead you to places you never expected.

At a large company, it can take months to get people to open up and speak candidly about the challenges they’re facing. Building that kind of trust involves using a lot of classic product manager tricks: having coffee with people, getting drinks with them, getting to know their work and their problems. Starting from a place of openness: “I’m new; I don’t know anything. Tell me your problems and we’ll figure something out.” Nothing transactional, no quid pro quo, no “You’ll scratch my back....” No expectations. People appreciate that kind of candor.

In her pioneering work on learning and success, Stanford psychology professor and author Carol Dweck posits that people operate with either a “growth” or a “fixed” mindset. When operating with a growth mindset, people see failures and setbacks as learning opportunities. When operating with a fixed mindset, people see failures and setbacks as negative reflections of their intrinsic worth. People operating with a growth mindset are able to approach skills and subject matter that are new to them as an opportunity to, well, grow. People operating with a fixed mindset feel threatened by skills and subject matter that are new to them.

If you have spent most of your life being an overachiever, as many product managers have, it is quite likely that you are operating with a fixed mindset. Why? Because many overachievers find success not by growing their skills in areas where they struggle but rather by avoiding these areas altogether.

As a product manager, you likely cannot succeed if you are operating with a fixed mindset. There are simply too many new things that you will need to learn, and you will not even know what these things are until it is too late for you to give yourself an overachiever-y head start.

The first product manager is operating with a fixed mindset. He receives the letter and turns red with embarrassment and anger. He whispers furiously under his breath, “My team is going to hate me for this.” But he also knows that his team has been through this before and will probably be more than willing to lay the blame squarely on those jerks in compliance.

The second product manager is operating with a growth mindset. She receives the same letter and immediately sends an email to the compliance department. In a nicely worded message, this product manager explains that she wants to make sure that she understands why exactly the compliance department could not approve this product.

Truly cultivating a growth mindset means being open not just to the unknown but also to being flat-out wrong. The most rewarding compliment I ever received as a product manager immediately followed one of the most difficult and contentious meetings I’ve ever attended. “You know,” said a senior leader as we walked out of the conference room, “you walked into that meeting advocating for one path forward, and by the end of it, you were open to something totally different. I’m really impressed by how you let yourself be convinced by the other people in the room.”

Just a few years prior, this comment would have infuriated me. I had gone into a meeting with senior leaders to present my vision for the product, and by the end of the meeting, I was effectively advocating for someone else’s vision. In a very real sense, I abdicated any claim I might have had to being the company’s “product visionary.” But I also demonstrated to senior leadership that I was willing to go with the idea that seemed best for the company, even if it wasn’t my own. For one of the very first times in my career, I had accepted the gift of being wrong.

For being wrong to be a gift, you need to know exactly why you’re wrong—and choose to value the overall goals you are working toward above your own plan for achieving those goals. If somebody else suggests an approach that better reflects what you are collectively working toward, aligning with that plan gives you a chance to reinforce the entire group’s commitment to your shared goals.

So if curiosity is the single most important quality for product managers to demonstrate, what is the opposite of curiosity? The answer I keep coming back to is, quite simply, defensiveness. Given the ambiguous and connective nature of product management, it is easy to find yourself on the defensive—whether that means defending your team against executive interference, defending your decisions against probing questions, or defending yourself against the sneaking suspicion that nobody understands or appreciates all the hard work you’re doing. Perhaps the hardest single lesson I’ve learned in my product career is that literally every single attempt I’ve made to defend something has actually wound up harming that thing.

Provide options, not arguments. Getting into a yes–no battle of wills is a surefire path to a defensive position. But giving stakeholders multiple options gives you the opportunity to evaluate and explore several different pathways without feeling like you are in a position to “win” or “lose” an argument. There’s been a lot of talk about how saying no is key to product management, but the best product managers I work with never have to say no—they just provide a set of options and help their teams (and especially their team and company leadership) choose the best one according to their goals and objectives. If you feel compelled to do something out of anxiety or defensiveness, write it down and reapproach it the next day.

Say, “OK, great,” and then figure out the rest. Sometimes, staying off the defensive is as simple as getting in the habit of saying, “OK, great,” to nearly any defensiveness-inducing question or statement you receive…and then figuring out the rest. Those few moments between the word “great” and whatever words come next may very well defuse a tense situation and set you up for an easier path forward. I’ve found this strategy particularly helpful when navigating tense moments in large meetings.

Ask for help. One of the most profound and meaningful ways to stay off the defensive is to proactively ask for help from people around you. This approach can be particularly meaningful when you ask for help from somebody who has proven stubborn, combative, arrogant, or otherwise challenging to work with. I’ve been truly shocked at the extent to which I have been able to improve my relationship with such people simply by reaching out and asking them to share their expertise with me or help me work through a problem I’m struggling to solve. I often encourage product managers to start the week by listing the people they are most afraid will undermine or misunderstand their work, then reach out to those people and schedule one-on-one time for an open and curious conversation.

The challenge is to get to a place where you can recognize your own defensive reactions, acknowledge that they are unlikely to lead to better outcomes for yourself or your team, and bring yourself back to a place of openness and curiosity as best you can.

My product was failing. I was failing. I experienced sleepless nights, cried once in a bathroom, and once escaped to a church to cry...and I’m not even religious. I was crying not because my product had failed, but because I felt I had failed. My sense of self-worth and the value of my product were one and the same. I was conflating product failure with personal failure...and I was burning out. Even now, some of the products I work on see slower adoption and growth than I would like. But I no longer feel like I personally am a failure. To foster emotional distance, I am my product’s worst critic. I can list out in excruciating detail why every single product that I currently manage sucks. I can recognize that even the most successful products I work on are not perfect—and, more importantly, that they are not me. My products serve a purpose, and they succeed at certain things and fail at others. And that’s OK.

Asking Why Without Asking “Why” In your quest to work with and learn from the people around you, you are certain to find yourself in a few situations where you trigger other people’s insecurity and defensiveness.

In a very real sense, it is a product manager’s job to always understand “why.” But, as many product managers have learned the hard way, you are not likely to generate much goodwill by being the person who goes around asking everybody, “WHY ARE YOU DOING THAT?” More than once, I’ve asked an innocuous-seeming “Huh, why did you choose to work on that right now?” question only to be met with a frustrated, blustery response that I know will harm my long-term relationship with the person to whom I posed the question. And, perhaps even more frequently, I’ve responded to an innocuous-seeming “Huh, why did you choose to work on that right now?” with my own blustery and evasive response.

Spreading Curiosity Good product managers minimize defensiveness and cultivate curiosity. Great product managers turn curiosity into a core value for their team and their organization. Genuine curiosity can be contagious, and it naturally encourages people to collaborate more closely and better understand each other’s perspectives. In a curious organization, negotiations between stakeholders feel expansive rather than combative, and deep conversations about goals and outcomes feel like an important part of your work rather than an impediment to doing the “real” work. Curiosity makes everything seem more interesting and less transactional.

The first key to spreading curiosity is to model it yourself, relentlessly. “I’m too busy right now” is a very dangerous sentence for product managers. If your colleagues are taking the time to come to you with questions and thoughts, however trivial those questions and thoughts might seem, encourage that behavior.