[Quotes] Product Management in Practice by Matt LeMay

One thing I realized throughout these years is that my interest in reading about topics that don’t have a direct relation to what I’m doing at that point in time has eventually served me at another point in time.

This is one case in point wherein I saw someone recommending a good product management book and it piqued my interest so decided to read it. It’s an easy and practical read where I learned more about product management, what a product manager does, and the important skills that a product manager needs to have.

I’m not a product manager but it’s a career path that I could potentially explore in the future. Why not?

Here are some quotes I highlighted from Product Management in Practice by Matt LeMay as I read it:

“Aside from a very generous assessment of my intelligence at the time, my boss gave me the greatest gift a new product manager can receive: a grim but resolute understanding that guidance would be very, very hard to come by. For all the books that I had read and all the methodologies that I had studied, the only thing I was left with when I sat back down at my desk was, “What the hell am I supposed to do every day?” If there was no roadmap, how was I supposed to manage the roadmap? If there was no product development process, how was I supposed to oversee the product development process?”

“I recently asked Pradeep Ganapathy Raj, director of product management at Yammer, what he wished that every new product management hire understood about their responsibilities. Here are his answers:
Bringing out the best in the people on your team
Working with people outside of your immediate team, who are not directly incentivized to work with you
Dealing with ambiguity

On his third point, he added: “The skill of actually figuring out what you need is probably as important as what you do after you figure it out.”

“Although many people are drawn to product management by the promise of “building products that people love,” the day-to-day practice of product management involves much less actual building than it does supporting, facilitating, and communicating.”

“At a small startup, you might find a product manager cobbling together product mock-ups, scheduling check-in points with contract developers, and conducting informal interviews with potential users. At a medium-sized technology company, you might find a product manager running planning meetings with a team of designers and developers, negotiating product roadmaps with senior executives, and working with their colleagues in sales and customer service to understand and prioritize user needs. At a large enterprise organization, you might find a product manager rewriting feature requests as “user stories,” requesting specific data from their colleagues who work in analytics or insights, and attending a whole lot of meetings.”

“Taking a genuine interest in the work of your colleagues is one of the most important things you can do as a product manager. But product management often poses a particular challenge to those who come from the “never mind, I’ll just go do it myself” school of problem-solving. If you, like me, are the kind of person who absolutely hated “group projects” in school and sought to take on as much work as possible for yourself, product management is likely to teach you difficult-yet-important lessons about trust, collaboration, and delegating.”

“you will have your work cut out for you figuring out what you should do, who you should talk to, and discovering the “unknown unknowns” that are unique to your product and team.”

“Generally speaking, the “classic” profile for a product manager is either a technical person with some business savvy, or a business-savvy person who will not annoy the hell out of developers.”

“Product management can be a brutal and relentless trigger for insecurity, and insecurity can bring out the worst in all of us.

Because product management is a connective and facilitative role, the actual value product managers bring to the table can be very difficult to quantify. Your developer wrote 10,000 lines of code. Your designer created a tactile, visual universe that wowed everybody in the room. Your CEO is the visionary who led the team to success. Just what did you do, exactly?”

“For product managers, the value you create will be largely manifest in the work of your team. The best product managers I’ve met are those whose teams use phrases like “I would trust that person with my life” and, “That person makes me feel excited to show up for work in the morning.” If you’re starting to feel insecure about your work, talk to your team and see what you can do to better contribute to their success. But don’t let insecurity turn you into a bad product manager”

“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.”

“Great product managers not only tolerate, but actively enjoy, the challenge of creating alignment and understanding between different roles and perspectives.”

“As a product manager, you cannot fear discomfort—you must actively work through it to get clarity for yourself and your team.”

“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.”

“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.”

“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.”

“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.”

“if your first impulse upon walking into a room is to defensively compare your own perceived intelligence to that of the people around you, you are probably not going to succeed as a product manager.”

“Communication is your job, and you can’t expect everyone else to be good at it. My two favorite questions are: “What are your goals?” and “What are you optimizing for?” I use them often and with great sincerity, and my product manager life (and non–product manager life!) are much better off because of it.”

“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-seeming those questions and thoughts might seem, encourage that behavior. Similarly, if you’re interested in something that a colleague is doing, don’t feel bad about asking for some of that person’s time—be confident in the knowledge that time spent learning from your colleagues is time well spent.”

“It’s not about changing everything all at once, and it’s not about forcing a team to work in a certain framework or adopt a certain set of rituals. It’s about really just iterating on your process constantly. When it doesn’t work, you figure out why it doesn’t work, and you try something else. It’s always a process to get to your process.”

“everybody’s communication style is different. The more you can take the time to learn about the specific people on your team and appreciate their individual communication styles, the better you can facilitate communication for your team and your organization.”

“One of the things that I feel has contributed the most to my career as a product manager is having the courage to push back, and to have challenging conversations. We are trained to follow the chain of command, so this can be very difficult when you’re in a room full of executives. You have to first understand that their questions and criticisms are not personal. I’ve seen that in some junior product managers—they interpret questions and criticisms from senior leaders as personal attacks. You need to remove yourself emotionally. You need to have the courage to say, “Can I push back on this? Can we talk about why you’re making this assumption?”

“Don’t be afraid to push for this clarity, and don’t forget to keep your user at the center of the conversation.”

“If a senior stakeholder suddenly wants your team to work on something different, find out why. There might have been an important high-level conversation of which you were not aware.”

“Don’t try to impress users with your knowledge or expertise. Create as much space as you can for them to explain their reality to you, even if it feels like “playing dumb.”

“Let your users lead you to what they think is important, rather than making that assumption for them with lots of detailed “zooming in” questions.”

“our first product management principle “clarity over comfort” can offer crucial guidance. Clarity does not mean presenting a single absolute, uncomplicated point of view. It means being clear and transparent about the limitations and assumptions at play in any conclusions you draw, and any datasets from which you draw those conclusions. Doing this is, at times, very uncomfortable, especially when you are presenting your conclusions to people who are hoping that a data-driven approach will remove all uncertainty and risk. But choosing not to document your assumptions does not mean that you are not making any assumptions. Instead, it means that you are failing to draw attention to the specific assumptions that informed your decision-making, and in turn depriving your organization of an opportunity to address those assumptions.”

“in some cases, the assumptions you’re making might be so deeply held that you yourself are not aware of them, even if you set about to think them through carefully. This is one of the many reasons why it is so important for you to open up a conversation about assumptions with your colleagues. It is inevitable that there are some important assumptions that you will not identify—but your colleagues might.”

“build a formal template for every data-driven decision that provides an opportunity to document goals, assumptions, and questions. Here is a rough template you can start with and customize for the particular needs of your organization:
The decision I’m trying to make or problem I’m trying to solve:

The data I’m using to make this decision:

Why I believe that this data will help me make this decision:

What I believe the data is telling me:

What assumptions are present in my interpretation of this data:

How we might test those assumptions:

The next steps I intend to take:”

“Think through how you will measure a product’s success before you launch it, to avoid having to go back and add instrumentation after a product is already released.
Be just as curious and active about understanding metrics moving “the right way” as you are about metrics moving “the wrong way.”

“Product idea:

Suggested by:

Which of our users (current or prospective) this is for:

How this idea will improve their experience:

How this idea will help our business:

How we will measure success:”

“In Agile parlance, a finite amount of time devoted to learning, researching, and/or experimenting (as opposed to building or coding) is often called a “spike.”

“The resulting Agile Manifesto reads, in its entirety, as follows:
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.”

Read: August 2021