Product Management in Practice: A Real-World Guide to the Key Connective Role of the 21st Century

Matt LeMay’s Product Management in Practice offers an invaluable and refreshingly honest look at the day-to-day realities of product management. Unlike many theoretical guides, this book dives deep into the ambiguity, contradictions, and compromises that define the role, moving beyond buzzwords and frameworks. LeMay, an experienced product management coach and consultant, shares practical strategies and real-world stories that illuminate the connective nature of product management, emphasizing the critical “soft skills” often overlooked in a profession frequently obsessed with technical acumen. This summary will break down every important idea, example, and insight from the book in clear, accessible language, ensuring you grasp the full scope of LeMay’s wisdom for navigating this challenging but rewarding career.

Introduction: Why I Wrote This Book: My First Day as a Product Manager

The introduction immediately sets the stage for the book’s practical, no-nonsense approach. LeMay recounts his own first day as a product manager, armed with theoretical knowledge but utterly unprepared for the messy reality. His boss’s curt “You’re smart, figure it out” became a foundational lesson: guidance would be hard to come by. This personal anecdote highlights the core disconnect between product management in theory (building products people love, triangulating business goals with user needs, playing chess) and product management in practice (fighting for incremental improvements, pushing for clarity on ill-defined goals, playing a hundred simultaneous games of checkers).

LeMay clarifies that this book is not a step-by-step guide to success or a list of guaranteed frameworks. Instead, it’s a “real-world guide” to the ambiguity, contradictions, and grudging compromises inherent in the role. He defines “product management” broadly to encompass a “nexus of product and product-adjacent connective roles,” recognizing that titles like product manager, product owner, or even business analyst can mean different things across organizations. The book emphasizes “practice”—like a yoga or meditation practice—something built with time and experience, not just instructions. It is designed for anyone making connections between people and roles, including startup founders, software developers, and product managers at any level. The book uses “users” instead of “customers” for simplicity, acknowledges the omission of detailed tool guides, and integrates stories from working PMs, templates for actionable advice, and “Your Checklist” summaries at the end of each chapter.

Chapter 1. The Practice of Product Management

This chapter delves into the fundamental nature of product management, addressing the gap between common perceptions and daily realities. Pradeep GanapathyRaj, Director of Product Management at Yammer, highlights three key responsibilities: bringing out the best in your team, working with external stakeholders, and dealing with ambiguity. He stresses that “the skill of actually figuring out what you need is probably as important as what you do after you figure it out.”

LeMay elaborates on what a product manager actually does all day:

• Lots of responsibility but little authority: Product managers are ultimately responsible for product success or failure, regardless of organizational support. They must lead through influence, not authority, requiring a different skill set than direct management.
• If it needs to get done, it’s part of your job: Successful product managers rarely say, “that’s not my job.” This means doing whatever needs to get done for the team’s success, even if it’s outside the job description. It often requires asking for support and guidance from people outside the immediate team.
• You are in the middle: A core function is translating between stakeholders and users, understanding their communication styles, sensitivities, and unspoken meanings. Even in “data-driven” organizations, product managers navigate tangled webs of resentment and conflict.

LeMay also defines what product management is not:

• You are not the boss: The “mini-CEO” analogy is misleading; true success comes from the trust and hard work of the team, which is squandered by acting like a boss.
• You are not actually building the product yourself: The role is connective and facilitative, not about hands-on building. Micromanaging technical or design decisions is often counterproductive and infuriating to the team.
• You can’t wait around until somebody tells you what to do: Product managers rarely receive clear instructions. They must be proactive in figuring out what to do, who to talk to, and resolving communication disconnects.

The chapter then profiles great product managers as adaptable, problem-solving connectors who can come from diverse backgrounds (music, politics, theater). They are the “information brokers” who intuitively understand how information flows in an organization. Conversely, bad product managers fall into consistent archetypes driven by insecurity:

• The Jargon Jockey: Uses complex terminology to prove importance, often obscuring real issues.
• The Steve Jobs Acolyte: Focuses on “visionary” ideas, devaluing user input and common sense.
• The Hero Product Manager: Believes they alone can save the company, often blames external factors for failures.
• The Product Martyr: Overworks and blames themselves publicly, but covertly resents the burden. This creates a “toxic” team dynamic where external requests are seen as unreasonable impositions. The story of M.G., a product leader at a nonprofit, illustrates how a lack of clear organizational goals can turn product owners into Product Martyrs, measuring success by effort and ownership rather than impact. M.G. learned that bringing product owners together to define shared goals melted away competition and defensiveness.
• The Nostalgic Engineer: Longs for their past technical role, devaluing current “non-building” tasks.

LeMay concludes that product management is a brutal trigger for insecurity. The value a product manager creates is largely “manifest in the work of their team.” The best product managers inspire trust and excitement in their teams.

Chapter 2. The CORE Connective Skills of Product Management

This chapter introduces LeMay’s central framework for product management skills, challenging the prevalent “hybrid” model. The common UX/Tech/Business Venn diagram, while acknowledging the connective nature, fails to provide actionable guidance for how to create alignment between these areas. It describes what a PM interacts with, not how they act. LeMay argues that the variability of the PM role across organizations (e.g., a PM at a large enterprise might focus on P&L, while a startup PM focuses on design/dev) makes this model insufficient for defining universal PM skills.

LeMay proposes the CORE skills of product management: Communication, Organization, Research, and Execution. These are the connective skills that transcend organizational variations and are crucial for success. Each skill has a guiding principle:

Communication: “Clarity over comfort”

This is the most important skill. Great PMs actively enjoy creating alignment and understanding across roles. Clarity means actively addressing inconsistencies and potential misunderstandings, even if it feels uncomfortable. Ignoring discomfort can lead to “cataclysmic” consequences, as silence can be misinterpreted as agreement. Chapter 5 will delve into specific strategies for achieving this.

Organization: “Change the rules, don’t break the rules”

This involves operationalizing and scaling interactions beyond one-on-one communication. Product managers who lack organization become bottlenecks, with their teams dependent on constant intervention. Effective organizers create systems where team members know what to work on and why without asking the PM directly. They don’t just solve problems but ask, “how can I make sure this doesn’t happen again?” The principle “change the rules, don’t break the rules” encourages PMs to collaboratively evolve organizational processes if they aren’t serving the team’s goals, rather than making ad-hoc exceptions.

Research: “Live in your user’s reality”

Research, defined as critical thinking, involves seeking out and synthesizing multiple perspectives beyond internal assumptions. Great PMs constantly look for new ideas, confounding variables, and challenging perspectives. Those lacking research skills lead teams down predetermined paths without questioning them. The guiding principle means truly understanding users’ needs, priorities, and realities, including those not directly related to the product. It’s about asking “What might this product mean to our users?” rather than focusing on feature parity with competitors.

Execution: “No work beneath, no work above”

Product managers are responsible for getting things done, even if it means doing tasks outside their job description. Execution-minded PMs inspire their teams and provide critical support. PMs who lack execution skills get “bogged down in theoretical underpinnings,” valuing thinking over doing, which devalues their team’s contributions. The principle “no work beneath, no work above” means being willing to take on low-status work (e.g., coffee runs) and stepping into high-level, critical conversations for the sake of organizational goals, not personal glory (e.g., leading a negotiation despite not being a “VP”).

LeMay then tackles the common question about “hard skills” (e.g., coding, statistical analysis). He argues that while some technical knowledge can be helpful, the emphasis on hard skills in hiring PMs is often misguided. He debunks myths:

• Hard skills are not necessary to win respect from technical folks: Respect comes from genuine interest and effective collaboration, not “playing developer.”
• Hard skills are not necessary to challenge technical folks: If a team is lying about timelines, there’s a deeper trust problem. Good PMs inspire teams to work efficiently without needing to catch them in technical lies.
• Hard skills are not necessary to stay interested and engaged: Knowledge and interest are different. The best PMs are curious about all their colleagues’ work.
• Hard skills are sometimes necessary for minor changes: Acknowledges that PMs at small companies might do minor code changes, but the key is openness and curiosity to learn, not pre-existing expertise.

The chapter concludes by asserting that the CORE skills model changes the conversation about product management from a “hybrid” of other roles to a unique and valuable discipline focused on connecting and aligning.

Chapter 3. Showing Up Curious

This chapter focuses on curiosity as the most important mindset for a successful product manager. LeMay opens with a personal anecdote about his early intimidation by data scientists and his reluctance to ask “obvious” questions. He realized his assumptions about their disinterest led to a self-created disconnect. His simple email, “I’m curious to learn a little bit more about what you’re working on,” broke the ice and revealed mutual alienation.

LeMay stresses the power of “I’m curious to learn more about the work that you do” as the most powerful sentence a PM can use. This simple gesture of curiosity can achieve three critical things:

• Learn “hard skills” contextually: Asking experts about their work is more effective than trying to learn skills from books. It ensures learning about skills relevant to the organization now and strengthens bonds with technical colleagues. This applies to non-technical specialized skills like compliance as well.
• Build bridges before you need something: Relationships built without an immediate transactional need are invaluable when support is genuinely required.
• Expand your network of influence: Reaching out to colleagues beyond the immediate team builds a far-reaching network that can lead to unexpected insights.

The story of Amelia S., a product manager at an enterprise media company, reinforces this. She found that large companies have a “veneer of formality” but are often messy, like startups. She built trust by starting from a place of “openness” and curiosity (“I’m new; I don’t know anything. Tell me your problems and we’ll figure something out”), making human connections through informal conversations (coffee, drinks). She discovered that the “real action” happened through backchannels, not just formal meetings, and that understanding the organizational knowledge and history held by folks in editorial, design, and engineering was crucial.

LeMay then discusses cultivating a growth mindset, as described by Carol Dweck. A growth mindset sees failures as learning opportunities, while a fixed mindset views them as reflections of intrinsic worth. Overachievers, like many PMs, often operate in a fixed mindset, avoiding areas where they struggle. As a PM, a fixed mindset is detrimental because new things constantly need to be learned. LeMay contrasts two PMs facing a compliance setback: the fixed-mindset PM blames “jerks in compliance,” crushing team morale, while the growth-mindset PM seeks to understand why the product was rejected, finding a specific issue and a solution, leading to a successful launch and team learning. A.G., a product manager, shares a similar experience where assuming her content VP was “smart and had the best intentions” despite a frustrating decision led her to uncover critical vendor relationship complexities she hadn’t considered. She emphasizes that other parts of the business optimize for different things and that a PM’s job is to figure this out, asking “What are your goals?” and “What are you optimizing for?”

The chapter also highlights the gift of being wrong. LeMay shares a powerful anecdote where a senior leader praised him for changing his advocated path in a meeting after being convinced by others’ arguments. This demonstrated a willingness to prioritize the best idea for the company over personal ego or “product visionary” status. Being wrong is a gift when you understand why and prioritize collective goals.

Finally, LeMay discusses spreading curiosity. Good PMs are curious, but great PMs make it a core team value. This is done by:

• Modeling it relentlessly: Avoid “I’m too busy,” and encourage questions, even trivial-seeming ones. Value time spent learning from colleagues.
• Cross-pollinating knowledge: Encourage designers and developers to learn from each other (e.g., “cross-functional pairing days”).
• Organizing “demo days”: Presenting work to the broader organization encourages harder work, collaboration, and anticipation of questions from colleagues, fostering a sense of shared interest.

Chapter 4. The Worst Thing About “Best Practices”

This chapter challenges the widespread obsession with “best practices” in product management, arguing that a rigid focus on them can be counterproductive. LeMay notes that PMs often ask, “How does Facebook do product management?” or “What are the things we can do to make sure we’re running product like a best-in-class organization?” He warns that the unspoken addendum is often, “because we want to do exactly the same thing.”

He identifies three insidious dangers of this thinking:

• Leads to an incurious mindset: Reducing PM to repeatable practices ignores messy human complexity. Anything not conforming to the “best practice” becomes a threat, making PMs incurious about their colleagues and even their own product.
• Often focuses on operational stories, not user value: Best practice narratives often end with happy, efficient teams, but not necessarily happy users. This shifts goalposts from “delivering user value” to “doing product management like Company X.”
• Magical thinking leads to sadness and disappointment: Initial optimism gives way to fatalism when best practices clash with existing organizational habits. Questions like “Whose fault is this?” arise, leading to unhelpful conclusions that an organization’s unique traits are impediments, rather than guides for change.

LeMay advises: Don’t Believe the Hype. He suggests a simple exercise: list what you’ve heard about Company X’s PM prowess, then spend five minutes using their product and list obvious problems. This highlights that “best-in-class” companies have their own internal struggles, resource constraints, and political realities. Most published case studies are “largely recruiting propaganda,” so talking to working PMs in your network provides more realistic insights.

He also warns against the “But This Worked at the Last Place!” syndrome. PMs often bring “best practices” from previous organizations, expecting similar results. However, past successes were likely due to specific organizational contexts and involved much trial and error. Implementing too many changes at once, or failing to understand the new organization’s unique needs, can lead to quick loss of team trust. The worst PMs blame their colleagues when their adopted “best practices” fail. Ashley S., a Director of Product Management, shares her experience learning this lesson. Initially eager to implement everything she’d seen work at her last company, she was advised to “start small, see what works, and then go from there.” She learned to identify communication problems and introduce changes slowly, constantly refining based on what worked. She emphasizes that “it’s always a process to get to your process.”

The chapter emphasizes Goals First, Then Practices. Blindly implementing best practices without understanding the specific needs and goals of your organization risks poorly understood, resisted, and failed changes. LeMay uses the example of a yearly “product summit” for distributed teams: while a good idea in one context, it could be disastrous in another if underlying issues like goal misalignment or inter-office conflicts aren’t understood first. He provides a template for understanding challenges before suggesting solutions:

• My organization is facing the following challenge:
• This challenge is affecting our ability to deliver value to our users in these ways:
• I believe that this challenge is caused by the following current beliefs and practices:
  This structured thinking helps focus on the actual problem and reframe operational issues as questions of lost user value.

Finally, LeMay highlights The Best Thing About Best Practices: they often come with an “organizational halo” of authority, making it easier to get buy-in for trying new things. Suggesting “Objectives and Key Results (OKRs), just as they have done with great success at Google,” sounds more reasonable than proposing a novel goal-setting method. However, he reiterates that they are a “place to start, not a guarantee of success”, requiring continuous refinement against clear goals.

Chapter 5. The Art of Egregious Overcommunication

This chapter humorously, yet seriously, stresses the critical importance of overcommunication for product managers. LeMay argues that the biggest mistakes often involve failing to communicate things that seem either too politically dangerous or too inconsequential. He illustrates this with a scenario where a PM ignores a minor discrepancy between a developer’s detail and a senior stakeholder’s expectation, leading to a “bloodbath” at a demo. The potential downside of undercommunicating is “cavernous and terrifying,” while overcommunicating is, at worst, “a few eye-rolls.”

The chapter provides tactical guidance for egregious overcommunication:

Asking the Obvious

Drawing from Ben Horowitz’s “Good Product Manager, Bad Product Manager,” LeMay emphasizes the line: “Good product managers err on the side of clarity versus explaining the obvious. Bad product managers never explain the obvious.” Things that seem obvious are often the source of disastrous miscommunication because nobody wants to explicitly address them (fear of condescension, wasting time, or being wrong). While personally uncomfortable, asking the obvious has little downside for the team and can reveal critical underlying misalignments.

Meetings Are Good, If You Want It

PMs often apologize for scheduling meetings. LeMay argues that this creates a self-fulfilling prophecy where meetings are seen as a waste of time. Instead, PMs should avoid being “president of the meeting-haters club” and ensure everyone’s time is well spent. Work with the team to define what a “good” meeting looks like for them. Patrick Lencioni’s Death by Meeting is cited for its point that bad attitudes, not just procedural flaws, ruin meetings.

One Weird Trick for Better Meetings: Disagree and Commit

Pioneered by Intel, “disagree and commit” aims for commitment over consensus.

• Consensus often means unspoken disagreement, decisions avoided, or agreement born of fatigue.
• Commitment means explicit responsibility for a decision, even if initially disagreed with. This encourages sharing dissenting opinions because nobody wants to be accountable for a known-to-fail plan.

Tips for using “disagree and commit”:

• Introduce it beforehand: Frame it as a procedural experiment, not a personal criticism.
• Interpret silence as disagreement: Force explicit commitment from everyone in the room.
• Ask for affirmative commitment: Look participants in the eye and ask, “Are you committed to this approach?”
• Set clear goals, test, and learn: If commitment isn’t reached, establish success criteria and plan to revisit the decision later, ensuring a decision is still made (e.g., “Let’s try two-week development cycles for a month, then re-evaluate”).
• Don’t misinterpret: It’s not about forcing agreement, but about encouraging dissenting opinions to emerge before committing. J.A., a product management consultant, shares a story where “disagree and commit” during a discussion about handling after-hours client emails uncovered a more effective and universally preferred solution (replying the next morning to train clients) that wouldn’t have emerged otherwise.

Creating and Protecting Space for Informal Communication

Beyond formal meetings, crucial conversations happen in informal settings (coffee breaks, walks, “water cooler” moments). High-pressure organizations often implicitly discourage “non-heads-down work,” suppressing this vital “real talk.” A key PM role is to protect this space. LeMay cites his 3 PM coffee break ritual at a startup as highly impactful for fostering connections and broader perspectives. Tips include using natural breaks (meals, beverages), avoiding conventionally productive times, and not forcing it (model value, make it opt-in).

Working with Distributed Teams

Communication challenges are compounded for distributed teams. LeMay acknowledges that distributed work is not the same as colocated work and shouldn’t be treated as a “stand-in.” Strategies:

• Keep it brief and focused: Long meetings are particularly grueling for remote participants.
• Document everything: Crucial for ensuring decisions from informal in-person conversations reach remote colleagues.
• Pick up the phone: Provides immediacy and intimacy that video chat might lack.
• Make space for informal communication: Trial and error is needed to find what works (e.g., off-topic chat rooms, always-on video links like Tony Haile’s experience at Scroll, which fostered camaraderie and ease of communication).

Don’t Deflect, Be Direct

PMs, lacking direct authority, are tempted to couch requests in “nice” or ambiguous terms (“It would be great if…”). LeMay recounts his own experience with a manager’s vague late-night text. He learned that ambiguity is not nice; it’s a deflection of responsibility and a passive-aggressive attempt to get results without being the “bad guy.” Self-deprecation (e.g., “Here comes the PRODUCT MANAGER with another FUN DEADLINE!”) also backfires long-term, as it implies the work is meaningless and discourages alignment around purpose. PMs must be direct, clear about why they are asking for something, and take ownership of decisions.

Accounting for Different Communication Styles

PMs must recognize that not everyone shares their communication style. LeMay identifies patterns:

• Visual communicators: Need ideas sketched or prototyped to grasp concepts.
• Asynchronous communicators: Need time to think before speaking; give a heads-up before asking for immediate input.
• Confrontation-averse communicators: Say “yes” readily; need questions that don’t allow for simple yes/no answers to elicit genuine feedback.

Understanding individual styles allows for more empathetic and effective facilitation.

Egregious Overcommunication in Practice: Three Common Communication Scenarios

LeMay presents three common PM communication scenarios with analysis:

• Scenario One (Emergency Feature Request): Account Manager demands a feature in two weeks; Developer says six months. This is a classic misaligned incentives problem.
  • What to do: Don’t debate arbitrary timelines or play both sides. Dig deeper into the fundamental customer problem, enlisting both AM and Dev as partners to understand needs and explore solutions. A quick conversation might resolve it without a new feature.
  • Avoid: Arguing timelines, trying to agree with both, or simply refusing due to process (“Come back later”).
• Scenario Two (Designer Presents Options): Designer asks, “which one do you like most?”
  • What to do: Demonstrate trust. Ask the designer which option best aligns with project goals. This prompts them to think about goals, or reveals unclear project goals. If multiple options are viable, discuss testing them. If only one option is presented, ask the designer to walk through how they arrived at it to uncover their understanding of goals.
  • Avoid: Picking a favorite based on personal preference, bringing it to a “design by committee,” or dismissively saying “I don’t care.”
• Scenario Three (Developer Protests Process): Developer says, “Sorry, I just don’t understand why you’re trying to force us to follow all this unnecessary process. Can you just let me do my job?”
  • What to do: Take feedback seriously, thank for candor. Ask them to repeat feedback in a team meeting to show you’re a facilitator, not an enforcer. This helps the team collectively identify and adopt best processes.
  • Avoid: Promising it will work, abandoning process entirely (leaving team disconnected from user/business impact), or blaming your boss (makes process meaningless).

The chapter concludes by reinforcing that effective communication, even when uncomfortable, is essential for PM success, allowing for greater team success and organizational clarity.

Chapter 6. Working with Senior Stakeholders (Or, Throwing the Poker Game)

This chapter addresses the high-stakes challenge of “managing up” to senior stakeholders. LeMay uses the analogy of “throwing the poker game”: “winning” often means helping someone else (the senior stakeholder) win, while ensuring that your business and users also succeed. Senior stakeholders inevitably “win” due to their authority, so the PM’s mission is to align their win with the organization’s greater good.

Managing Up for Clarity at All Costs

A product manager cannot succeed without clarity among senior leaders about company strategy and vision. This means the PM’s job is to push upward for clarity at all costs. If there’s no clarity (due to competing visions or simply no vision), the PM has “literally nothing to lose” by pushing for it. If senior leaders won’t commit to goals, the PM must do everything to get face-to-face time, help define the vision, and then let the leader take full credit. This is an application of the “no work beneath, no work above” principle. Ashley S., a product manager at an enterprise electronics company, describes how a top-down decision around a specific technology, based on sunk cost rather than user needs, led to a product failure. She learned the courage to push back on executive decisions, understanding that their questions aren’t personal and that PMs must unpack “why does this take so long?” without defensiveness, demonstrating trade-offs and ensuring leaders own the decisions.

“Our Boss Is an Idiot,” or, Congratulations—You’ve Ruined Your Team

LeMay warns against retreating into team cohesion at the expense of organizational alignment. When senior leadership sends an “unreasonable” request, PMs are tempted to blame the leaders to their team (“Can you believe how those idiots are jerking us around? NOT MY FAULT”). This ruins the team by making them see requests as arbitrary, fostering a “sticking it to the man” mentality, and positioning the PM as a protector rather than a connector. In the long term, this sets the team up for failure. Instead, PMs must manage up for clarity, explain trade-offs to leaders as partners, and take ownership of decisions to the team, explaining the why. Shaun R., a product manager, recounts how “protecting” his team from business goals for a Black Friday sales page led to building a user-centric product that missed key business metrics, resulting in defensive rethinking and low morale. He realized he had “insulated the team rather than trying to surface the underlying conflict.”

No Alarms and No Surprises

Nothing you tell a senior stakeholder in a “big” meeting should ever be a surprise. LeMay shares a cautionary tale: he presented a “creative” new roadmap idea, requested by one senior stakeholder, without getting buy-in from others beforehand. This led to a “bloodbath” in the meeting, demonstrating a betrayal of trust with other stakeholders and a lack of clear support from the initial requestor.

• Solution: Walk senior stakeholders individually through new ideas before group settings. This ensures they are invested, increasing the odds that your idea “wins” regardless of which senior stakeholder “wins” the current “poker hand.” Ellen C., a product management intern, made the mistake of a “big reveal” for a commenting system spec. She learned that a “big reveal” prevents critical feedback and that incremental buy-in from individual stakeholders is essential.

Staying User-Centric in a World of Company Politics

PM success ultimately hinges on user happiness, not just stakeholder happiness.

• Let users make the case for you: Use insights from user conversations to advocate for product ideas to stakeholders. If you don’t know why users need something, don’t advocate for it.
• Connect user needs and business goals: Don’t let user needs and business goals be seen as at odds. Clearly explain how a feature or product serves both (e.g., faster onboarding increases new users, which increases ad revenue).
• Flip the script: Ask senior leaders what they know about user needs. Invite them into collaborative discussions about solutions to user problems.
• Avoid “compromises” that negatively affect user experience: Sacrificing user experience for stakeholder placation often indicates misaligned internal politics and incentives. This is a moment to push for clarity upward. M.P., a product manager, shares a story where a site redesign was a “huge success” from a stakeholder perspective (balancing departmental prominence), but a “confusing mess” from a user perspective, with a buried search bar. He realized he had “completely forgotten to advocate for the user’s needs” by focusing solely on stakeholder happiness.

Tactical Trade-Offs, Not Emotional Manipulation

Avoid “Product Martyrdom” by playing up the effort involved in a task (“I’d have to work all weekend”). Instead, enlist senior stakeholders in decisions about tactical trade-offs (“To accomplish this, we can move this other deadline back. What’s most important?”). This shifts the conversation from personal sacrifice to strategic choices aligned with business goals. It also prevents PMs from over-promising and then demanding unreasonable efforts from their teams based on a misinterpretation of a senior leader’s question as a demand.

Throwing the Poker Game in Practice: Two Common Scenarios

LeMay provides two “swoop-and-poop” scenarios:

• Scenario One (Executive doesn’t like design): Executive says, “I don’t like the colors, and it doesn’t look anything like the product I signed off on!”
  • What’s really going on: The executive feels out of the loop, their authority threatened. It’s a communication problem, not primarily a design problem.
  • What to do: Apologize for the surprise. Ask what you can do to ensure they see works-in-progress on a timeline that makes sense for them (e.g., standing weekly meeting). Address the fundamental communication disconnect.
  • Avoid: Litigating past agreements, blaming them for not responding to emails, immediately changing colors, or getting into an opinion battle.
• Scenario Two (Executive wants a new feature): Executive says, “I know your team is working on something, but I’m excited about that other feature… can you find time?”
  • What’s really going on: Excitement, not sabotage. Opportunity to understand their priorities.
  • What to do: Have an open, transparent conversation about why this feature is exciting to them and why it wasn’t prioritized. Be open to it being more important. Discuss changing the rules (prioritization process) for future work, rather than just breaking them for this one instance.
  • Avoid: Immediately agreeing (undermines process), immediately saying no (misses understanding), or vaguely saying “maybe, we’ll see.”

The chapter concludes by emphasizing that managing senior stakeholders is a challenging, high-stakes, but ultimately critical part of the PM’s job. PMs must push for clarity and consistency in organizational goals, keeping the user at the center of all conversations.

Chapter 7. Talking to Users (Or, “What’s a Poker Game?”)

This chapter highlights the crucial, yet often misunderstood, skill of talking to users. LeMay uses a detailed analogy of a PM sitting in on a poker game. In the first scenario, the PM pretends to know poker to “sound smart” and asks general questions about an “ideal online poker app,” leading to superficial insights (“People need an online poker app to be exciting”). In the second, the PM humbly admits rustiness, prompting the hosts to explain their informal “house rules.” This “playing dumb” reveals a deep insight: players adapted the game to their social group’s particular needs, leading to fundamentally different, richer questions about informal rules and social dynamics.

Stakeholders and Users Are Different

The core lesson is that successful approaches for stakeholders are often the wrong ones for users.

• With stakeholders: You want investment, clear commitment, alignment of high-level goals with execution, and camaraderie.
• With users: You don’t want investment in a specific solution, clear commitment to use your product, or validation of your current direction. Your job is simply to learn as much as possible about their needs, their world, and their perspective. This often means “playing dumb” to create space for users to communicate in their own words.

Yes, You Need to Learn How to Talk to Users

LeMay laments that many PMs “dismiss or devalue” the work of user experience designers and researchers. This stems from insecurity (“owning” the user relationship as a source of authority) and the perception that user research tools accuse PMs of lacking user knowledge. He shares his own “fit” when a UX designer suggested user personas, only to later find them “tremendously useful” for focusing on actual users.

• Key takeaway: You can always learn more about your users. Read books, seek mentors, and practice new techniques. Be open and curious about how to learn from users, not just learning from them.

“Quick Wins” for Better User Research

LeMay offers practical tips for informal user research:

• Ask about specific instances, not generalizations: Instead of “What do you usually eat for lunch?”, ask “Walk me through the last meal you ate.” People are more candid about specific experiences than general preferences, especially with value-laden topics like music or food.
• Don’t get too excited if you hear what you thought you wanted to hear: Don’t jump in with “That’s exactly what we’ve been talking about!” This shuts down deeper understanding. Users might describe the same solution for entirely different, crucial reasons.
• Don’t ask users to do your job for you: Referencing the OXO measuring cup story, users asked for “sturdy” and “comfortable handles,” but observation revealed a need for “read from above” markings (as users squat to read traditional cups). Users are unaware of organizational intricacies or their own unmet needs. Understanding and articulating user needs is the PM’s job. Jonathan Bertfield’s story of a failed startup that only listened to “power users” (high-profile authors excited about a tool) illustrates this pitfall: they ignored “dissenting voices” from lower-profile authors who were their actual target market, leading to failure. The startup believed users would change their behavior, failing to recognize the deeper needs and constraints of their actual customers.

Leveling Up Versus Zooming In, or Another Way to “Why”

The word “why” can often put users on the defensive. LeMay suggests a framework for asking “why” without using the word, by considering whether your question intends to “zoom in” on details or “level up” to overall goals and experiences.

• Leveling up questions (e.g., “Tell me about the last time…”, “What was it like to…”, “How was the experience when you…”) aim for core user needs and motivations. This allows users to lead you to what’s important.
• Zooming in questions (e.g., “How many apples did you buy? What kind? What did you do with them?”) can lead to trivial details and miss the broader context. LeMay admits to this “novice user researcher” habit, realizing he was focused on sounding knowledgeable rather than learning what was truly significant to the user’s overall experience (e.g., why they shopped, not just about the apples).

The chapter concludes by emphasizing that learning to talk to users means unlearning behaviors successful with internal stakeholders and adopting an open, curious approach to understanding users’ realities.

Chapter 8. “Data, Take the Wheel!”

This chapter challenges the often-superficial embrace of “data-driven product management,” arguing that while data is useful, it cannot drive decisions on its own. LeMay notes the popularity of “data-driven” as a buzzword for PMs and hiring managers, but warns that it can encourage “endless busywork” and disconnect PMs from “living in their user’s reality.” When PMs are buried in spreadsheets, they lose touch with the messy complexity of real-world users. The focus is on high-level, toolset-agnostic approaches to using data effectively without abdicating responsibility.

The Trouble with the “D” Word

The word “data” itself is problematic because it’s used broadly to describe anything from objective information to filtered conclusions or visualizations, often wielding “authority without specificity.” LeMay suggests a counterintuitive rule: don’t use the word “data.” Instead, describe the specific information being discussed (e.g., “The email survey we conducted shows…” instead of “Our data shows…”). This invites more meaningful conversations about what information was gathered, how, and how it’s interpreted, distinguishing information from assumption.

Don’t Hide Your Assumptions—Document Them!

All data-driven decisions involve assumptions (e.g., representativeness, importance of outliers). The most meaningful step a PM can take is to be completely upfront and transparent about these assumptions, even presenting data that contradicts decisions. This aligns with “clarity over comfort.” Clarity doesn’t mean presenting a single, uncomplicated view; it means being clear about limitations and assumptions. Failing to document assumptions deprives the organization of addressing them.

LeMay illustrates with an example: a ride-sharing startup expanding to Europe, choosing markets based solely on “motorization rates” (a higher rate assumed to indicate more potential drivers). This hid the assumption that supply was more important than demand, and neglected other factors like regulation or competition. To combat this, he provides a formal template for data-driven decisions:

• 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:
  This template forces reflection and allows colleagues to participate constructively, making assumptions discussable and testable.

Focusing on Metrics That Matter

PMs must have a strong point of view about which metrics matter and why. He cites “One Metric That Matters” (from Lean Analytics) as a valuable thought exercise. Without connecting metrics to underlying goals, all metrics become “vanity metrics” (e.g., increased page views for a search product might be bad if the goal is quick information retrieval). A strong point of view can also reveal what should be measured but isn’t. Shaun R., a product manager, shares a story where he had a strong intuition that improving a “clunky” user interface would reduce training time and increase product affinity, but lacked “incontrovertible signal.” He learned to start with a conjecture and establish a feedback loop to test intuition, rather than waiting for existing data.

“Up and to the Right” Is a Signal, Not a Strategy

Positive trends (“up and to the right”) are signals, not strategies. If you don’t understand why numbers are going well, you can’t build on momentum or react if trends reverse. Quantitative data needs to be supplemented with qualitative data (e.g., talking to new users to understand what drew them to the product). Without deeper understanding, even “important” metrics can be vanity metrics.

From “Accountability” to Action

Holding PMs directly accountable for specific quantitative numbers can backfire, leading to disengagement if targets seem out of reach or guaranteed. Instead, PMs should seek accountability for:

• Knowing which metrics matter and why.
• Having clear targets.
• Knowing what’s going on with these metrics right now.
• Identifying underlying issues.
• Determining which issues are within your team’s control.
• Having an action plan for addressing these issues.
  This shifts accountability from an uncontrollable number to actionable steps within the PM’s control.

Acknowledging the Limitations of Obfuscating Quantitative Proxies

LeMay introduces Obfuscating Quantitative Proxies (OQPs): single-dimensional numerical answers to broader qualitative questions that obscure complexity (e.g., Net Promoter Score). Signs of an OQP: captures complex trends in a single number, disguises raw data collection methods, presented as universally applicable.

• OQPs differ from “One Metric That Matters,” which focuses efforts on specific goals. OQPs offer the fantasy of not having to focus.
• Behind every OQP are assumptions and limitations. While they can summarize trends (e.g., NPS for likelihood to recommend trends over time), they lose detail and complexity.
• He provides a template for assessing OQPs: What does it represent? What raw info? How was it generated? What can it not answer? How might we answer those questions? How can we use it for our specific goals?

Keeping It Accessible

PMs must break down technical data challenges into easy-to-understand, goal-oriented concepts. This is especially crucial with data scientists, who often prioritize technical metrics. Michael Dewar is quoted on how PMs who don’t recast tactical data science decisions into accessible terms leave design to “the vagaries of the data scientists.” Janet Brunckhorst, a principal product manager, shares how her team built an app for physical therapy by translating complex algorithms into a “fun and accessible game” with the client using index cards and real-world scenarios. This made technical decisions collaborative and rooted in the client’s subject matter expertise, leading to a “really great product.”

The chapter concludes that while data is a critical tool, it requires thoughtful and thorough use, as it won’t do the PM’s job for them.

Chapter 9. Realistic Roadmaps and Painless Prioritization

This chapter tackles the often-thorny topics of roadmaps and prioritization, emphasizing their role as tools for connection and alignment, not fragmentation or competition.

It’s Not the Roadmap, It’s How You Use the Roadmap

LeMay admits his own misinterpretation of the advice that roadmaps are “strategic communication documents” rather than ironclad plans. This led to problems when stakeholders assumed the roadmap was a firm promise. The key is to have an explicit and shared organizational understanding of what a roadmap means and how it’s used.

• Guiding questions for clarity: How far into the future? Short-term vs. long-term distinction? Who has access? How often reviewed/changed? Criteria for inclusion? What can be reasonably expected from a feature listed three months vs. two years out?
  Josh W., a product executive, shares how he introduced roadmaps to an ad tech company that had none. He recognized the danger of sales teams seeing it as a “set of promises.” His solution: a presentation on “thinking like a product person” to the sales team, labeling the first roadmap “VERSION 0” to emphasize it was a work-in-progress, and holding the head of sales accountable for its correct communication. Regular quarterly retrospectives on both the roadmap and how it was used helped the organization understand its value and refine its purpose.

“The Product Manager Owns the Roadmap!”

LeMay challenges the notion that the PM “owns” the roadmap, calling it a “glittering prize” that often becomes a “focal point for disagreement” and “perceived slights.” Everyone has ideas and wants to get them built. Attempting to be the “true keeper of the organization’s product vision” by excluding others (e.g., other PMs) leads to a “great big mess” when product interdependencies arise. A PM’s job is to open the roadmap to a shared, company-wide discussion, making it a tool for collaboration focused on high-level goals. The rule is to ask, “What steps do I need to take that will make me more comfortable sharing this roadmap with the entire organization?”

Structure and Facilitate Ideas for the Roadmap, Don’t Own Them

PMs often want to be the “idea person,” but every organization has plenty of ideas. The PM’s challenge is to establish criteria to consistently evaluate ideas against user needs and business goals. LeMay admits his early “product idea dump” failed because it devalued ideas and lacked structure for evaluation.

• Solution: Provide templates that structure ideas. A simple template includes: Product idea, Suggested by, Which users it’s for, How it improves their experience, How it helps business, How success will be measured.
  This filters ideas, ensuring they’re tied to goals, and prevents “half-baked ideas.” It’s a win-win: PMs don’t have to be the “idea person,” and the best, most aligned ideas get built, with existing “evangelists” (the suggestors).

Your Product Spec Is Not Your Product

Product specifications (product specs) are strategic documents, but they are not the product itself. Spending too much time on extensive, beautiful specs can create a “false sense of certainty” and hinder collaboration, as users don’t benefit from the spec, only the released product.

• Approach: Treat product specs as conversation starters, not hard-and-fast plans. Include questions in the spec to communicate that the team are “co-creators” and “trusted partners.”
• User stories: While helpful for focusing on user needs (“as a [role], I want [feature] so that [reason]”), they can shift the goalpost from writing a useful spec to writing a formally correct one, assuming prioritization and research have already occurred. Always tie back to clear goals. Jonathan Bertfield, an executive producer, shares how his focus on writing an “excruciatingly detailed” product spec for 4 months, without talking to customers, led to an overly complex product that failed. He realized “writing stuff down is very much a double-edged sword” and that too much detail removes PMs from the actual work and learning.

Wait, You Mean We Actually Have to Build This Now?

Short-term prioritization is often a greater pain point than long-term roadmaps because it involves fixed capacity and more “super-important” things than time/resources. It’s where organizational goals are truly tested.

• Key: Prioritization is easy or difficult based on how clear, well-understood, and actionable your goals are. The most important work happens before the formal meeting, by defining goals.
• LeMay contrasts a PM who avoids “goals stuff” and lets the prioritization meeting be chaotic with one who proactively clarifies goals with their manager.
• Janet Brunckhorst, a principal product manager, explains how a simple impact-versus-effort matrix helped a remote team prioritize effectively. By first discussing core user needs, then plotting ideas based on developer effort and user impact, they collaboratively chose a solution that delivered the most user value while making best use of developer time, leading to high team engagement.

SMART Goals, CLEAR Goals, OKRs, and so on

Numerous frameworks exist for organizational goals:

• SMART goals (Specific, Measurable, Achievable, Relevant, Time-bound)
• CLEAR goals (Collaborative, Limited, Emotional, Appreciable, Refinable)
• Objectives and Key Results (OKRs): LeMay favors OKRs for combining a qualitative rallying cry (objective) with quantitative measures (key results). He recommends Christina Wodtke’s Radical Focus for understanding OKR pitfalls.
• Caveat: PMs should start small and simple with OKRs, reframing their own team’s goals first, before attempting to scale to the whole organization.

Taking Your Goals for a Test Drive

Regardless of the framework, PMs should “test drive” their goals by trying to prioritize potential product ideas against them with senior leaders. This improves goal clarity, connects leaders to product decisions, gives the team more flexibility, and opens a channel for constructive communication. Blair Reeves, a senior product manager, describes how his team struggled post-acquisition because they waited for higher-level strategic decisions instead of proactively ensuring senior leaders had the on-the-ground product knowledge needed to make informed choices. This led to a “shallow” product integration and a missed opportunity.

Making Room for Old Stuff and (Truly) New Stuff

Prioritization should balance “shiny and new” ideas with existing needs.

• Don’t dismiss new ideas: Understand why the team is excited about new technology or features. Can that excitement be directed toward delivering value for users (e.g., improving an existing product)?
• Protect time for learning/experimenting: Don’t just prioritize building. Make time for “spikes” (Agile term) for research, prototyping, and experimentation, even if they don’t result in immediate product output. J.D., a product manager, shares how a two-week prototype to test an open-source geolocation solution for a new feature ended up invalidating the entire feature idea, saving six months of development time by revealing it wasn’t actually valuable to users.

But This Is an Emergency!

All organizations face “emergency” feature requests. Instead of breaking rules, PMs should set up an official process and/or template for handling them. A template can ask: What is the issue? Who reported it? How many users affected? Revenue tied to it? What happens if not addressed in 2 weeks/6 months? Contact person? The mere presence of such a template often significantly reduces the volume of emergency requests, as it forces the requester to think through the actual impact.

Prioritization in Practice: Same Features, Different Goals

LeMay provides a scenario for an ad-supported video startup with five potential features. He illustrates how a vague mission statement (“completely transform the way people consume video”) makes prioritization impossible. But by sitting down with the founder and developing clear, OKR-style goals (e.g., “increase weekly app downloads by 50%,” “increase average connected video platforms per user”), the prioritization becomes much clearer, even if some stakeholders are initially “annoyed.” Different OKRs would lead to different prioritization choices. The decisions are only as good as the goals that guided them.

The chapter concludes that roadmaps and prioritization, while seemingly high-status PM tasks, are best approached as opportunities to connect and align, not to guard or manipulate.

Chapter 10. The Wonderful, Horrible Truth About Agile

This chapter is aimed at PMs who might jump straight to this topic, acknowledging that Agile can feel like the sum total of their job. LeMay states that Agile doesn’t eliminate human complexity and requires constant reflection and refinement. The core principle for this chapter is “Change the rules, don’t break the rules.”

Debunking Three Common Myths About Agile

• Agile is a rigid and prescriptive methodology: Myth. Agile is a movement based on shared values. Many “Agile” implementations run counter to these values.
• Agile is a way to do more work, faster: Myth. Agile is about working differently, not just more or faster. It often requires slowing down to reflect.
• Agile is only for software development teams: Myth. Agile emerged from software development but its principles are broadly applicable. Disconnecting Agile teams from the broader organization actually runs counter to its values.

Turning to the Agile Manifesto

The Agile movement began in 2001 with 17 developers seeking alternatives to “heavyweight software development processes.” The Agile Manifesto values:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan
  The key is “while there is value in the items on the right, we value the items on the left more.” Agile is about designing practices aligned with these values, embracing human complexity. LeMay notes the irony that the Manifesto came after popular methodologies like Scrum and XP, highlighting their shared core values.

From Manifesto to Monster

Andy Hunt, a signer of the Agile Manifesto, critiques “The Failure of Agile,” arguing that the movement has “lost its way,” becoming “sloganized” and “jingoist.” “Flaccid agile” involves half-hearted practice. Agile zealots follow rules without remembering the aim. The irony is that Agile methods themselves have not been agile. Hunt attributes this to Agile asking practitioners to “think,” which is “a hard sell” compared to simply following rules for comfort and safety. This ties back to “clarity over comfort”—Agile is not about comfort.

Using Alistair Cockburn’s “Heart of Agile” to Bridge Values and Practices

Alistair Cockburn, another Agile Manifesto signer, distilled Agile into four actions at the “Heart of Agile”:

• Collaborate
• Deliver
• Reflect
• Improve
  These provide a simple, plainspoken yardstick to measure Agile success, bridging values and practices. LeMay emphasizes that Agile contains its own “blueprint for success”: if you truly reflect and improve, you will get better. The biggest mistake is an all-or-nothing approach where frameworks fail and are then abandoned.

Four Steps to Future-Proof Agile

These steps lead to successful Agile adoptions:

1. Begin with a “North Star”: Use the Agile Manifesto, “Heart of Agile,” or similar to define why changes are being made (values, principles, outcomes). This helps evaluate if specific practices help achieve goals. A visual reminder helps.
2. Pick an off-the-shelf Agile methodology: Start with something existing (Scrum, XP). This provides a “referee” for initial confusion and makes it easier to identify what’s working/not.
3. Regularly evaluate the specifics against your North Star: Don’t skip retrospectives (often seen as a “waste of time” not “producing software”). This short-term optimization has long-term ramifications. Reflection helps ask, “Are our meetings helping us collaborate?”
4. Work with your team to change the specifics accordingly: If practices aren’t working, go “off-manual.” This requires accountability and “changing the rules, not breaking the rules,” moving beyond the comfort of “doing it by the book.” LeMay provides a template for documenting process changes: Agile practice used, intended effect toward North Star, actual effect, proposed change, hoped effect of change, and success metrics for the change. This helps track and clarify what’s working.
   These steps form a continuous loop of adjustment. Noah Harlan, founder of Two Bulls, describes their transition from Waterfall (fixed, but prone to external changes) to Agile. Waterfall provided initial “seductive certainty” for clients but became adversarial. Agile, though requiring different initial client conversations (“we’ll track velocity, show work every two weeks, you can change features”), leads to better products, closer collaboration, and genuine alignment, as both team and client refine based on reality.

A Few General Caveats About Agile

LeMay, a “firm believer” in Agile’s values, also acknowledges its limitations:

• Agile does not always explicitly address the “why”: It guides how to work, but not necessarily why to build a particular product. PMs must ensure the process builds the right things.
• Agile rituals can become a false stand-in for user centricity: Writing user stories (as in Chapter 9) can create a “false sense of user-centricity” if teams don’t actually talk to users. PMs must ensure these rituals genuinely lead to user interaction.
• Agile needs to extend beyond your product team: The entire organization needs to understand why the team uses Agile and its implications for overall rhythms/deadlines. Collaboration must extend beyond the immediate team to avoid insulation.

The chapter concludes that successful Agile implementation relies on the CORE skills (communication, organization, research, execution). “No process” is still a process, and PMs must understand how their organization currently builds products before attempting changes.

Chapter 11. In Good Times and Bad

This chapter sets a realistic expectation for product managers: meteoric success is exceptionally rare. With millions of apps and most smartphone users engaging with only five non-preinstalled apps, great product managers work on products that fail all the time. Even established products face challenges like risk aversion and bureaucracy. Product management is hard, but its “practice” can make everybody’s job easier by turning “insidious tension and misalignment into opportunities for learning, sharing, and collaborating.”

The Soothing Lull of an Organization on Autopilot

Periods of “autopilot mode” occur when external conditions are favorable, numbers are good, or accountability is low. This seems good but carries substantial risk:

• Danger: “The way things are” becomes the only path. New ideas are dismissed, teams become insular, and critical opportunities are missed.
• PM’s role: Actively seek out challenging ideas and alternate explanations. Talk to users who abandoned the product, explore competitors, bring challenging questions to the team (“What if our direction is wrong?”). Model openness and curiosity.
• Action: Channel these challenges into time-boxed prototypes that directly challenge fundamental product assumptions (e.g., “reinvent the product in one week”). This is favored over “hack days” that are seen as breaks from “real” work.

The Good Times Aren’t (Always) the Easy Times

True “good times” for a product management practice are characterized by:

• Conflicts discussed openly with minimal personal attacks: Healthy organizations address conflict directly, using it to make good decisions.
• Everybody feels invested in their work: Disinterest is more dangerous than healthy disagreement.
• People see new information (and new people!) as an opportunity, not a threat: No shying away from signals of being on the wrong path. New information, people, or ideas are seen as gifts.
  The truly good times are when new challenges are actively sought out and approached with openness, curiosity, and candor. These often coincide with high-stakes moments like product launches, where collaboration and connection shine. The challenge is to bring that same energy every day.

Carrying the Weight of the World

A mentor told LeMay a PM’s job is to “think about every single little thing that could possibly go wrong, before it goes wrong.” While this resonated with LeMay’s own tendency to carry the weight of the world, he warns that product management can be “a little bit too perfect” for such people. It can lead to feeling that every problem is yours to solve, making the job feel “relentlessly demanding and absolutely futile” during difficult times.
This leads to the Hero Product Manager/Product Martyr blur, where the PM feels they are the “only thing keeping this team (or this company) from completely falling apart.” This dangerous fallacy leads to tantrums, withholding information, and resentment.

Steps to avoid this trap:

• Make a list of things outside your control: A reminder that you can’t solve every problem (e.g., competitor launches, executive power struggles).
• Look for opportunities to delegate important things: Break the heroism cycle by delegating mission-critical tasks. This exposes colleagues to organizational friction, allowing for group problem-solving.
• Protect the routines and rituals that bring your team together: Team lunches, coffee breaks, brainstorming sessions are often the first to go during tough times. Your absence sends a dangerous message that time with the team is unimportant. Show up, be present, and model that connection is paramount.

The chapter concludes that the connective nature of the PM role carries both responsibility and great opportunity. By being in the middle, PMs have an outsized positive effect on colleagues, setting the tone for communication, listening, and respect. During crises, they can be the “fearless protector of the very best things about your team and your company.”

Chapter 12. Conclusion: Whatever It Takes

LeMay reflects on his initial misconception that the title “product manager” conferred power and control. He now understands that the title grants “nothing”—no formal authority, no intrinsic control, no ability to get things done without the help of others. Influence and trust must be earned “every minute, every day” within a role characterized by “irresolvable ambiguity and irreducible complexity.”

He emphasizes that PMs will make mistakes—”glaring, egregious, embarrassing mistakes”—with real repercussions. These humbling experiences, and the forgiveness shown by colleagues, lead to self-forgiveness.

The “true beauty of product management” lies in its demands:

• Demands learning how to be wrong, no matter how smart.
• Demands backing up words with actions, no matter how charismatic.
• Demands respecting and honoring peers, no matter how ambitious.
  Product management offers no “airtight job description or a veneer of formal authority to hide behind.” To succeed, one must become “a better communicator, a better colleague, and a better person.”

The chapter ends with an anecdote of a new PM frustrated by the “unexpected ambiguity” of his role (“I feel like every day I show up for work, this is a totally different job”). The smiles of experienced PMs, and eventually his own, signify the shared realization of the answer to “Just what am I supposed to do all day, anyhow?”: “whatever it takes.”

Key Takeaways

• Product management is a connective role, not a hybrid role: It’s about bridging gaps and facilitating alignment across diverse functions, not simply being a jack-of-all-trades.
• “Soft skills” are the “hard skills” of product management: Communication, Organization, Research, and Execution (CORE) are paramount, emphasizing clarity, collaboration, curiosity, and getting things done without ego.
• Embrace ambiguity and discomfort: The role is inherently uncertain. Lean into “clarity over comfort” and “the gift of being wrong” to uncover deeper insights and foster trust.
• Prioritize goals over practices: Best practices are a starting point, not a guaranteed solution. They must be tailored to your organization’s specific goals and refined through continuous reflection.
• Champion the user relentlessly: Live in your user’s reality, using data and direct interaction to truly understand their needs, and advocate for them even amidst internal politics.
• Delegate and empower, don’t hero or martyr: Avoid the trap of feeling solely responsible for all problems. Delegate, trust your team, and protect shared rituals to foster collective responsibility and well-being.

Next Actions:

• Identify one “obvious” unasked question: This week, in a meeting, ask a question that seems too simple but might uncover a critical misalignment.
• Schedule a “curiosity coffee”: Reach out to one person outside your immediate team or function with “I’m curious to learn more about the work that you do.”
• Draft a “goals-first” template: Use LeMay’s template for a recent decision or upcoming project to document assumptions and force clarity on the “why.”
• Challenge one “best practice”: Reflect on an Agile ritual or company process. Using the “reflect and improve” mindset, discuss with your team whether it genuinely serves its North Star goals, and propose a minor adjustment.

Reflection Prompts:

• What is one area where I tend to operate in a “fixed mindset,” and how could embracing a “growth mindset” fundamentally change my approach?
• How can I better “throw the poker game” with a senior stakeholder to ensure that both their goals and my user’s needs are met?
• Am I truly “living in my user’s reality,” or am I letting internal assumptions or data proxies obscure their true needs? What’s one specific action I can take to get closer to my users this week?