Product Management in Practice by Matt Lemay
My rating: 4 of 5 stars

The practice of product management

• 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.
• Find ways to align, motivate, and inspire your team that do not require formal organisational authority.
• Be proactive about seeking out ways that you can help contribute to the success of your product and your team.
• Be a connector between teams and roles.
• Get out ahead of potential miscommunications and misalignments, no matter how inconsequential they might seem in the moment.
• Don’t get too hung up on the “typical profile” of a successful product manager. Successful product managers can come from anywhere.
• Don’t let insecurity turn you into the caricature of a bad product manager! Resist the urge to defensively show off your knowledge or skills.

The core connective skills of product management

• Embrace the uniqueness of the product manager role.
• Pursue clarity over comfort to build your communication skills.
• Seek out opportunities to solve organisational 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 organisational 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 organisation 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.

Showing up curious

• Reach to people before you need them and say, “I’m curious to learn more about the work that you do.”
• Be just as vigilant about getting to know people outside of your immediate team, and take the time to understand their goals and motivations before you need something from them.
• Cultivate a “growth mindset” and open yourself up to learning from people whose skills and knowledge exceed your own.
• Resist the urge to avoid situations that test the limits of your abilities or knowledge.
• Embrace “the gift of being wrong” by choosing the plan that best meets your organization’s goals, even if it is not your plan.
• Shake up the work that people are doing and cross-pollinate knowledge and skills to keep your team curious and actively learning.
• Model the value of curiosity for your team and organisation.
• Avoid saying “I’m too busy to deal with that right now” and other things that might implicitly discourage your team from asking open and curious questions that don’t have an immediate transactional value.
• Encourage your colleagues to learn from one another, and pair up folks who want to learn about one another’s skills.
• Organise “demo days” and other opportunities for product teams to share and discuss their work with the organization at large.

The worst thing about “Best Practices”

• Approach best practices as a place to start, not a prescriptive one-size-fits-all solution.
• Ask yourself how a particular best practice might help your team deliver user value, instead of just how it will change the way you work.
• If you’re curious about how a particular company approaches product management, try to find some people who have actually worked there and ask them.
• When you are bringing a best practice from one organization into another organisation, acknowledge and appreciate that every organization is different.
• Take the time to truly understand the goals and needs of your organization before rushing to implement any specific practices.
• Use a “slow and steady” approach to implementing best practices, so that you can test and measure the impact of every incremental change.
• Avoid the temptation to solve the problems that seem the most familiar to you, as opposed to the problems that are having the most impact on your users.
• Utilise the “organisational halo” effect of best practices to get buy-in toward trying new things, but be prepared to continuously adjust course based on what is working and what is not working.

The art of egregious overcommunication

• Err on the side of overcommunication. When you aren’t sure whether something is worth mentioning, mention it.
• Don’t be afraid to ask “the obvious.” In fact, the more obvious something seems, the more insistent you should be about making sure everybody is in fact on the same page.
• Create a document like “Good Product Manager, Bad Product Manager” that clearly lays out the behavioral expectations for product managers in your organisation.
• Avoid the temptation of being a “meeting-hater.” Don’t apologise when you’re asking for somebody, but make sure that their time is well spent.
• Ask your teammates about the most valuable and well-run meetings they’ve ever attended, and work with them to set a clear vision for what a “good” meeting should look like in your organisation.
• Make sure that people are given a chance to voice their opinions in meetings by using “disagree and commit” or any other approach that achieves similar goals within your organisation.
  • The goal of a meeting should not be to get consensus, but rather to get commitment
  • Encourage people to share dissenting and complicating information that might prove critical in deciding upon a path forward.
  • Avoid consensus-driven compromise solutions that placate meeting participants but fail to meet underlying goals.
  • Force a clear decision, and create shared accountability around that decision.
  • Allow participants to pick their battles by committing quickly to low-stakes decisions that are often prone to disagreement (i.e., “What’s for lunch?”)
  • Interpret silence as disagreement, ask for affirmative commitment
  • Don’t completely misinterpret the entire point of this and say, “Well, it doesn’t matter if you agree because we’re doing disagree and commit!”
• Create and protect space for informal communication in your organisation, like team lunches and coffee breaks.
• Acknowledge that distributed and remote work is simply not the same thing as colocated work, and cannot be transformed into an exact proxy for colocated work through tools and technologies.
• Remember that people have different communication styles. Don’t write somebody off as a “bad communicator” or assume that they have bad intentions if they are not as open and extensive a communicator as you are.
• Avoid starting sentences with phrases like “It would be great if…” or “Do you think it might be possible to…” that deflect responsibility. If you are asking for something, ask for it—and be clear about why you are asking for it.
• Level up tactical conversations about things like design choices or development timelines to strategic conversations about goals and user needs.

Working with senior stakeholders

• When working with senior stakeholders, don’t set out to “win.” Help empower them to make great decisions, and demonstrate that you can be a valuable and supportive thought partner.
• Push upward for clarity around company strategy and vision, no matter how challenging it is. In the absence of this clarity, you cannot succeed.
• Don’t try to “protect” your team from senior stakeholders by talking about how ignorant, arrogant, or out of touch these senior stakeholders are. Instead, bring your concerns directly to these senior stakeholders and help walk them through making the trade-offs that will best serve your company’s overall goals.
• Never surprise a senior stakeholder with a big idea in an important meeting. Socialise ideas slowly and deliberately in one-on-one meetings.
• Don’t let company politics drown out the needs of your user. Let user needs guide your decision-making, and bring the user’s perspective to life in meetings with senior leaders.
• Make sure that business goals and user needs are not seen as at odds with each other, but are instead aligned with each other, both for specific product initiatives and within the organization’s overall vision and strategy.
• When senior stakeholders ask you questions like, “Can this be done by Tuesday?” take their questions at face value. Let them participate in making tactical trade-offs, rather than rushing to make yourself the Product Martyr.
• When confronted with a swoop-and-poop, don’t try to litigate the details of past conversations. Look for opportunities to diagnose and address the underlying issues so that that the swooper/pooper does not feel out of the loop moving forward.
• 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.

Talking to users

• Talk to your users!
• Accept and acknowledge that talking to users is a real skill that takes time to develop.
• Remember that talking to users and working with stakeholders are different things, and require different approaches.
• 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.”
• If there are user researchers in your organisation, reach out to them and ask for their help walking you through the tools and approaches that they use.
• When talking to users about their experiences, ask about specific instances rather than broad generalisations.
• Don’t ask users to do your job for you! Do everything you can to understand their needs, and then think about the specific products and features that might best address those needs.
• Use “leveling up” questions and prompts to get to core goals and motivations without an accusatory “why.”
• 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.

Data

• Recognise that a data-driven approach still means that you will have to set priorities and make decisions.
• Avoid using the word data to generalise specific information. Say what that information is and how it was gathered.
• Rather than hiding or erasing the assumptions that go into working with data, document those assumptions so that you and your team can address them together.
• Have a clear and strong point of view about what metrics matter and why.
• As a thought exercise, ask yourself to decide on the “One Metric That Matters.” If you’re having trouble focusing in, go back to your high-level goals and see if you can make them more specific and actionable.
• 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.”
• Rather than being accountable for a number hitting a target, seek to be accountable for knowing why that number is moving toward or away from that target and having a plan for addressing whatever underlying issues are within your control.
• Resist the siren call of scores and numbers that purport to tell you “everything that you need to know” about anything. Take the time to understand how these quantitative proxies are developed, and do the work of figuring out what specific questions they can and cannot answer based on your goals and priorities.
• No matter how complex the data systems you’re working with, resist the pull of jargon. Keep conversations about technical decisions rooted in high-level goals that can be understood by everyone in the organization to make as much room as possible for collaboration.

Realistic roadmaps and painless prioritisation

• Give up on being the person who “owns” the roadmap. Instead, look to facilitate the way that your entire organisation uses roadmaps.
• Don’t make assumptions about how your organisation uses roadmaps. Ask lots of questions, and create a clear and well-documented understanding of how roadmaps are to be used within your organisation.
• Open up the roadmap. It should be a conversation starter and a tool for alignment, not something to be closely guarded and manipulated under cover of darkness.
• Give your colleagues the opportunity to suggest ideas for the product roadmap, but don’t let it turn into a free-for-all.
  • 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
• Advocate just as fiercely for ideas that are not your own, if not more so. Don’t get hung up on wanting to be the “idea person.”
• Don’t spend so long on product specifications that you close off avenues for true collaboration.
• If you are using a formal practice for writing product and feature specifications such as “user stories,” remember that a formally correct spec is not necessarily a good spec.
• Make sure that everything on your roadmap is tied back to a “why” so that if that “why” changes, you can adjust the roadmap accordingly.
• Be prepared for short-term prioritisation to be much more challenging than creating a long-term roadmap.
• Dealing with emergencies
  • What is the issue?
  • Who reported this issue?
  • How many users is it affecting?
  • Is there revenue directly tied to this issue?
  • If so, how much?
  • What would happen if this issue were not addressed in the next two weeks?
  • What would happen if this issue were not addressed in the next six months?
  • Who is the contact person for further discussing/resolving this issue?
• Do everything in your power to make sure that the goals against which you are prioritising are clear, well understood and actionable.
• If you can, take your goals for a “test drive” with the senior leaders who are setting the company vision and strategy. See if the goals can serve as a stand-in for their vision, and change your goals if they aren’t giving you the guidance you need.
• If your team is excited to build something new and shiny, don’t reflexively shoot it down for “not meeting our goals.” Find out why your team is so excited, and see what you can do to direct that excitement toward whatever solution will deliver the most value to your users and your business.
• Remember that learning, testing, and experimenting is still valuable work, and should be treated as such. Prioritise tasks like creating prototypes and researching implementation approaches alongside the work of actually building your product.

Agile

• Avoid ambiguous and misleading jargon around Agile—say exactly what you intend to do and why you intend to do it.
• Understand the core values and principles of Agile before evaluating any specific practices or frameworks. If you just start implementing process without purpose, then you have no way to evaluate whether the process is working or not.
• Socialise a North Star vision around Agile values and principles, so that everybody on your team knows why they are “doing Agile” in the first place.
• Start with an off-the-shelf Agile methodology so that you have an impartial “referee” to resolve any specific questions about whether you’re “doing it right”—and then be fearless about changing that methodology if it is not helping you reach your North Star vision.
• Create and protect time for your team to evaluate Agile practices against the goals you’ve set. Document process changes along with their intended goals, so that there is clarity around what people are doing and why.
• Don’t let the operational details of doing Agile distract you from higher-level organisational goals. Remember that if you are executing against a product roadmap that delivers no value to your users or your business, it doesn’t matter how Agile your execution is—your product is still going to fail.
• Don’t let user-centric Agile rituals serve as a stand-in for actually talking to your users.
• Communicate the goals and rhythms of your Agile practices to people outside of your immediate team, so that they know what to expect and how to work with you.
• Understand that “no process” is still a process, and take the time to really understand how your organization is currently building products.
• If you feel that your organization is becoming too zealous about Agile, feel free to print out a whole bunch of blog posts by people who actually wrote the Agile Manifesto, describing how Agile zealotry and ornamentation have derailed the movement they started.

Day to day

• Be wary of your organisation and team falling into autopilot. Actively bring new ideas and challenging perspectives to your team at all times.
• Use time-boxed prototypes to explore alternate product directions, even when there is no immediate or obvious pressure to change course.
• Remember that a good product organisation is not one free of conflict, but rather one in which conflict is handled openly and without personal attacks.
• Try to bring the energy and enthusiasm from your best and most exciting moments as a product manager to every day of your work.
• If you begin to feel like you are the only person keeping your team or your organisation from falling apart, take a step back. Make a list of the things you can’t control, delegate impactful work to your colleagues, and make sure you are protecting your team’s most valued routines and rituals.
• Understand that the connectedness of your role carries great responsibility, but also great opportunity. Do everything in your power to protect and embody the very best things about your team and your organisation.