Product Management in Practice

The Practice of Product Management

Most descriptions of product management draw a Venn diagram: business, technology, and user experience, with the PM sitting in the overlap. That diagram describes what a PM touches, never how a PM should act inside the overlap, and it's the "how" that actually determines whether a PM is any good.

Two popular alternate framings make this worse. The "mini-CEO" framing tells PMs they own the outcome the way a founder owns a company, which quietly gives them permission to dictate rather than collaborate. The "product visionary" framing tells PMs their job is having the big idea, which quietly devalues the unglamorous daily work of shipping one.

The better frame: product management is a practice, in the same sense that yoga or meditation is a practice. Nobody arrives at a finished state of enlightened prioritization. You show up, you work the fundamentals again, today's session doesn't carry over automatically from yesterday's.

That reframing changes what failure means. A bad sprint isn't proof you're bad at the job, it's data for tomorrow's practice.

A product leader at a nonprofit, referred to in the book as M.G., inherited a team where product owners had no shared definition of success. Without one, people quietly filled the gap themselves, measuring their own worth by how hard they worked rather than by what actually moved the mission forward.

LeMay calls this pattern the "Product Martyr": someone who has learned to equate long hours and visible effort with doing the job well, because nobody ever gave them a real target to aim at instead. M.G. fixed it not by working owners harder but by bringing them together to define shared goals they could actually be measured against.

The chapter-specific lesson: if a team you're joining seems to run on individual heroics rather than shared direction, don't start by praising the hardest workers. Start by asking whether anyone can state, in one sentence, what "good" looks like this quarter. If they can't, that's the problem to fix first, before touching a single roadmap item.

The CORE Skills of Product Management

If the Venn diagram is the wrong tool for describing what a PM does, LeMay's replacement is CORE: Communication, Organization, Research, Execution. Each comes with a short, repeatable motto meant to be recalled mid-meeting, not just read once in a book.

Communication: clarity over comfort

The instinct in most workplace conversations is to soften a hard message so nobody feels bad in the moment. LeMay argues this trades a small, contained discomfort now for a larger, compounding confusion later. Saying "I don't think this will work, and here's specifically why" is harder in the room and cheaper for the team than a vague, encouraging response that leaves the real disagreement unspoken.

Organization: change the rules, don't break the rules

Every team runs on some process, whether anyone named it or not. A good PM notices when a process has stopped serving its purpose and changes it openly, with the team's buy-in, rather than quietly ignoring it because a deadline is close. Breaking a rule without changing it teaches the team that rules are optional when inconvenient, which erodes trust in every other process too.

Research: live in your user's reality

This isn't a mandate to run more surveys. It's a discipline of testing your own assumptions against how people actually behave, not how you'd expect a "rational" user to behave. A PM who can describe a user's day in specific, textured detail is doing research even without a formal study; a PM running perfectly designed studies but unable to describe that day is not.

Execution: no work beneath, no work above

A PM who refuses to write meeting notes because "that's not strategic" is making the same mistake as a PM who refuses to make a hard prioritization call because "that's the team's decision." Both are avoiding the actual, current need of the moment in favor of a version of the job they'd find more comfortable or more flattering.

The four skills aren't a checklist to rank yourself against individually, they're mutually dependent. Sharp research findings that never get communicated clearly change nothing. Confident execution without organization burns out the people who have to clean up after it.

The framework's real use is diagnostic: when something on a team is going wrong, naming which of the four is actually missing usually points straight at the fix. For a PM evaluating their own growth, or a hiring manager evaluating a candidate, CORE is a far more honest rubric than years of experience or a specific tool stack.

Showing Up Curious

New PMs, especially ones without a technical or specialist background, tend to develop a habit of nodding along in meetings with engineers, data scientists, or designers rather than asking what feels like an obvious question. The fear is specific: asking something "basic" will confirm the room's worst suspicion, that this PM doesn't actually belong here.

LeMay argues this fear gets the risk backwards. Silence doesn't protect credibility, it slowly erodes it, because the PM ends up making decisions without understanding the thing they're deciding about, and that gap eventually shows. The people whose respect a PM is trying to protect can usually tell when questions have stopped, and they read it as disengagement, not competence.

As a new PM at Bitly, LeMay describes being intimidated by a data scientist colleague whose work he didn't fully understand, and avoiding the "obvious" questions for weeks rather than risk looking unprepared. He eventually sent a short, low-stakes email: he was curious to learn more about what she was working on.

That single message became, by his own account, the piece of advice from the book he's repeated most often since. Curiosity, asked plainly and without pretending to already understand, tends to read as confidence rather than weakness, because it signals the PM is more interested in getting the answer right than in managing how they're perceived while getting there.

This connects to Carol Dweck's growth-versus-fixed mindset research: a PM operating from a fixed mindset treats not knowing as a threat to their identity as competent, so they avoid situations that might expose it. A PM operating from a growth mindset treats not knowing as simply the current state, temporary and fixable by asking.

The chapter-specific lesson: the next time a term, system, or decision in a meeting isn't fully clear, the move that builds the most trust with a specialist colleague isn't researching it silently afterward, it's asking them directly, phrased as genuine curiosity rather than a test they might fail.

The Art of Egregious Overcommunication

The single most common way PM work quietly breaks down isn't a bad decision, it's an assumption that a decision, once made, doesn't need repeating. LeMay's argument: you should communicate a decision, a plan, or a piece of context roughly twice as often as feels necessary, because "everyone already knows this" is almost never actually true across a full team.

The instinct to under-communicate usually comes from a reasonable place: nobody wants to seem condescending by repeating something obvious. But the cost of one person missing a decision they were never told about, twice, in two different meetings, is far higher than the cost of one extra recap message.

This is where "disagree and commit," borrowed from Intel's engineering culture, becomes a practical tool rather than a slogan. The real discipline isn't the commitment part, it's making sure disagreement gets voiced clearly and specifically before the decision locks in. A team where people nod in the room and grumble afterward hasn't actually disagreed and committed, it's just deferred the disagreement to a worse moment, usually mid-execution when it's more expensive to resolve.

• Write decisions down somewhere durable, not just stating them once in a meeting that half the team missed.
• Restate the reasoning behind a call, not just the call itself, so people who weren't in the room can evaluate it rather than just comply with it.
• Explicitly name disagreement when it exists, rather than letting silence in a meeting stand in for consensus that was never actually reached.

The chapter-specific lesson: after a decision gets made, the PM's job isn't finished, it has barely started. Write the decision and its reasoning down somewhere the whole team can find later, say it out loud again in the next relevant meeting, and treat any lingering silence from a stakeholder as a signal to ask directly whether they actually agree, not as agreement itself.

Working with Senior Stakeholders (or, Throwing the Poker Game)

Working with senior stakeholders is often framed as a persuasion problem: get the executive to agree with your plan. LeMay reframes it as a sequencing problem instead. The mistake most new PMs make isn't having a weak argument, it's presenting a strong argument to a whole room of stakeholders at once, before any of them have had a private chance to react.

LeMay illustrates the failure mode with a specific story: he pitched a "creative" roadmap idea, one a senior stakeholder had actually asked for, directly to a mixed group of stakeholders without first checking in with each of them individually. The meeting turned into what he calls a bloodbath.

Stakeholders who might have supported the idea one-on-one instead dug into defensive positions in front of their peers, because nobody wants to be seen changing their mind live in a group. Out of that experience comes the chapter's central metaphor: "throwing the poker game."

In poker, a strong player sometimes deliberately loses a hand they could have won, because keeping a weaker opponent at the table, feeling capable, is worth more over the whole game than one satisfying win. Applied to stakeholder management: let a senior stakeholder win a specific, visible point, even one that costs little, if it preserves the trust that gets the actually important outcome across the finish line.

This is not the same as being a pushover. The PM still steers toward the real goal, and still says the hard thing when it matters, this is where Chapter 4's clarity-over-comfort principle applies directly. What changes is sequencing and venue: walk each senior stakeholder through a significant idea individually, before any group reveal, so their first reaction happens somewhere changing their mind doesn't cost them anything socially.

The chapter-specific lesson: before a big group pitch to senior stakeholders, map out who in the room is likely to react badly in public even if they'd be fine with the idea privately, and have that conversation with them alone first. The group meeting should confirm a decision, not test it for the first time.

Talking to Users (or, "What's a Poker Game?")

The poker metaphor from the previous chapter returns here applied to users instead of executives, and the chapter's title is a small joke about that: users, unlike senior stakeholders, have no poker game to throw, no political position to protect, which is exactly why what they say can't be taken at face value the same way a stakeholder's request can't be taken as their real underlying goal.

LeMay's core claim: users are reliable narrators of their own frustration and unreliable narrators of the solution to it. A user asked directly what they want will describe a fix shaped by whatever tools and mental models they already have, not necessarily the actual best fix, because designing the fix was never their job.

The chapter's clearest illustration is a measuring-cup redesign. Users asked directly said they wanted a "sturdy" cup with a "comfortable handle." Taken literally, that's a materials and ergonomics brief. But observing people actually measure ingredients revealed the real friction: standard cups require bending down or lifting the cup to eye level to read the markings while pouring.

The winning redesign, angled internal markings readable from directly above, solved a problem the stated feedback never once mentioned.

LeMay offers a concrete alternative to the reflexive follow-up question "why," which tends to put people on the spot and produce a rationalized answer rather than a true one.

• Leveling up: ask what the person was ultimately trying to accomplish, one level of abstraction above the specific request.
• Zooming in: ask them to walk through the actual last time they hit this problem, step by step, rather than describing it in general terms.

The chapter-specific lesson: when a user request lands in your backlog verbatim, "add a button here," "let me export to CSV," don't treat the literal ask as the spec. Ask what they were trying to accomplish when they wanted that button, or watch them hit the problem in real time if you can, before deciding what to build.

The Worst Thing About "Best Practices"

"Best practices" sound like free, de-risked wisdom: someone else already figured this out, so importing it should save time. LeMay's argument is that this framing hides the actual risk, which is that a practice's success was never really about the practice itself, it was about the specific context it grew out of, a context the new team almost never shares.

He tells this through a PM identified as Ashley S., a director of product management who had seen a particular process work well at a previous company and pushed hard to install the same process at her new one, quickly, confident it was simply a better way to work. It stalled.

The team resisted it, not out of resistance to change generally, but because the conditions that made it work before, a certain team size, a certain trust level, a certain kind of product, weren't present here.

The lesson she draws, and the one LeMay generalizes from it: "But this worked at the last place!" is not actually an argument for a practice, it's a claim that needs its own evidence. The real diligence isn't researching whether a practice is popular, it's researching why it worked where it worked, specifically, and then checking whether those specific conditions hold in the new context.

This reframes what "best practice" should really mean for a PM: not a universal, portable answer, but a hypothesis worth testing, informed by understanding the mechanism behind someone else's success rather than just copying its shape. A daily standup that worked at a twelve-person startup isn't automatically the right cadence at a two-hundred-person org, even though it's the exact same ritual on paper.

The chapter-specific lesson: the next time you're tempted to introduce a practice because "it worked at my last company," write down, specifically, why it worked there, what team size, what kind of product, what level of trust already existed, before proposing it here. If you can't name the mechanism, you don't actually know if you're importing wisdom or just nostalgia.

The Wonderful, Horrible Truth About Agile

Agile, as originally conceived, is a set of values: working software over comprehensive documentation, responding to change over following a plan, people and interactions over rigid process. LeMay's "wonderful" half of the title is that these values, taken seriously, genuinely do make teams more adaptive and more likely to ship things users actually want.

The "horrible" half is what happens once those values calcify into ritual. Standups become status-report theater rather than a tool for surfacing blockers. Story points become a number teams game to look productive rather than a rough planning aid. The ceremonies survive; the reason for them quietly disappears.

LeMay's diagnostic isn't "is your team doing Agile correctly," a question that tends to produce more process, not less. It's simpler and more uncomfortable: for any given ceremony, can anyone in the room say specifically what decision or behavior it changes? If a standup never surfaces a blocker that gets acted on, it isn't serving Agile's original purpose no matter how disciplined the team is about attending it.

This connects back to Chapter 2's "change the rules, don't break the rules" motto directly. A PM who notices a ceremony has stopped working has two bad options and one good one: keep running it out of habit, quietly stop attending or enforcing it, or bring the team into an open conversation about changing it. Only the third one is actually Agile in the sense the framework's authors meant.

The chapter-specific lesson: pick one recurring ceremony on your team and ask, honestly, what specific decision it changed in the last month. If the answer is "none," that's evidence that particular ritual has outlived its purpose and deserves an open conversation about changing it, not a quiet death by neglect.

The Infinite Time Suck of Documentation (and Yes, Roadmaps Are Documentation)

Documentation has a strange property: it's simultaneously chronically under-invested, nobody can find the decision that was made three months ago, and a place PMs can burn unlimited hours polishing something that will be stale within a week. LeMay's fix isn't "write more" or "write less," it's a change in what documentation is understood to be for.

Treated as an archive, documentation optimizes for completeness and permanence, and PMs sink real time trying to make a document exhaustive and future-proof. Treated instead as a communication tool aimed at a specific audience with a specific need right now, the same effort produces something shorter and more useful, because it was never trying to be the permanent record in the first place.

The chapter's title makes an argument some PMs resist: a roadmap is documentation, subject to the exact same discipline. A roadmap presented as a fixed set of promised dates functions like an over-engineered archival document, precise-looking, expensive to maintain, and quietly dishonest about how much actually changes between now and the dates on it.

A roadmap presented instead as a living statement of current direction and confidence level, explicitly expected to shift, does the communication job a roadmap actually exists to do.

LeMay's practical fix is naming, for any document before writing it, exactly who will read it and what decision or action it needs to support. A one-page directional roadmap for company-wide visibility and a detailed sprint-level plan for an engineering team are different documents with different honesty requirements, and treating them as the same artifact is where the infinite time gets lost.

The chapter-specific lesson: before writing or updating any roadmap or spec, write down the actual question it needs to answer for its specific reader, executives deciding budget, engineers deciding sequencing, sales deciding what to promise, and cut anything that doesn't serve that one question.

Vision, Mission, Objectives, Strategy, and Other Fancy Words

Strategy vocabulary suffers from a specific problem: everyone uses the terms, almost nobody uses them consistently, and the resulting confusion isn't harmless, it produces roadmaps built on objectives nobody agreed the strategy actually requires. LeMay's fix is a working set of distinctions a team can actually hold in their heads and use the same way.

• Vision: the long-term, largely aspirational picture of the world the product is trying to help create, deliberately distant enough that it won't change quarter to quarter.
• Mission: what the organization itself is actually doing, day to day, to move toward that vision.
• Strategy: the specific, current bet about how to win, the set of choices about where to focus and, just as importantly, what to deliberately not do.
• Objectives: the measurable near-term targets that tell you whether the strategy is actually working.

The chain matters more than any single definition: an objective without a strategy behind it is just a number a team is told to hit, disconnected from any actual reasoning about why hitting it matters. A strategy without a mission behind it is just a bet, with no larger context for whether it's the right bet to be making.

LeMay's point isn't that teams need to memorize the vocabulary, it's that teams need the chain to actually connect, so that when someone asks "why are we doing this," the honest answer traces upward through objective, to strategy, to mission, to vision, rather than stopping at "because it's on the roadmap."

A common failure mode: teams write an inspiring vision statement once, in an offsite, and never revisit it, while treating objectives as the only part of the chain that actually gets managed day to day. That produces objectives that technically get hit while the underlying strategic bet quietly goes untested.

The chapter-specific lesson: for any current objective on your roadmap, be able to state, in one sentence, the specific strategic bet it's testing, not just the number it's targeting. If you can't state that sentence, the objective isn't connected to a strategy yet, it's just a target, and it deserves that conversation before more work goes toward it.

"Data, Take the Wheel!"

Data is often invoked as a conversation-ender: "the data says," full stop, as if the number itself made the decision. LeMay's argument is that this framing is a category error. Data doesn't make decisions, it informs the humans who do, and every decision presented as purely data-driven actually rests on an assumption someone chose, usually silently, about what the data means and what it doesn't.

He illustrates this with a ride-sharing startup's international expansion decision. The team picked which European markets to enter based heavily on motorization rate, the share of the population that owns a car, treated as a proxy for how many potential drivers a market could supply. The number was real and the analysis behind it was careful.

What went unexamined was the assumption baked into using that one proxy at all: that driver supply, not rider demand, was the binding constraint on the business in every market being considered. In at least one market, that assumption turned out to be wrong.

LeMay's practical rule, deliberately blunt: stop using the word "data" as if it were a source in itself. Name the actual thing being cited, this specific survey of these specific users, this funnel metric measured over this specific date range, rather than the vague, authority-borrowing word "data." Naming the actual source forces the same sentence to also surface its limits: how many people, over what period, under what conditions.

This isn't an argument against using data, LeMay is a strong advocate for grounding decisions in evidence. It's an argument against letting "data-driven" function as a magic phrase that shuts down further questions, when the rigorous move is to keep asking what assumption the number depends on, especially the assumption that feels too obvious to need stating out loud.

The chapter-specific lesson: the next time a decision gets justified with "the data shows," ask the follow-up question out loud in the room: what would have to be true about this data, or the world it was collected from, for this conclusion to be wrong? If nobody can answer that, the data hasn't been interrogated yet, it's just been cited.

Prioritization: Where It All Comes Together

Prioritization is where every other chapter's skill either shows up or its absence gets exposed. Weak curiosity means missing which problems actually matter to users. Weak communication means a prioritization call, once made, doesn't stick. Weak stakeholder management means a well-reasoned priority gets overridden by whoever complained loudest. Weak data discipline means the inputs to the decision were never trustworthy in the first place.

LeMay's core claim about prioritization frameworks themselves, RICE, value-versus-effort matrices, weighted scoring models, is that none of them is a silver bullet, and treating one as an oracle whose output should be followed mechanically misses what the framework is actually for.

The real value of running a structured prioritization exercise isn't the resulting score, it's the forced conversation the scoring process requires: naming what "impact" even means for this decision, surfacing a disagreement about effort that was previously implicit, making a team's competing priorities visible to each other instead of each person silently ranking things differently in their own head.

A team that fills out a scoring spreadsheet alone and reports the ranking afterward hasn't actually run a prioritization process in the sense that matters, they've generated a number that looks objective while skipping the conversation that would have made the number meaningful. A team that argues through the same spreadsheet together gets the real benefit even if they end up adjusting the score based on judgment afterward.

This is also where "disagree and commit" earns its keep most visibly. Prioritization decisions are exactly the kind stakeholders are most likely to quietly resent if they didn't get a real hearing, so voicing disagreement clearly during the process, and then genuinely committing once the call is made, is what keeps a decision from being silently re-litigated every week afterward.

The chapter-specific lesson: the next time you run a prioritization exercise, treat the resulting ranking as a starting point for a conversation with stakeholders about what's underneath the numbers, not as a final answer to hand them. If nobody learns anything new about how their colleagues see the tradeoffs, the exercise hasn't done its job yet.

Try This at Home: The Trials and Tribulations of Remote Work

Every CORE skill from Chapter 2 gets harder, not easier, when a team is remote or hybrid, and this chapter, new to the second edition, is built around why. In an office, a huge amount of communication, organization, and curiosity happens by accident: the hallway comment, the overheard conversation, the quick shoulder-tap question. Remote work doesn't remove the need for those moments, it removes the default mechanism that used to produce them for free.

The chapter's core argument is that remote teams don't need less structure than co-located ones, they need more deliberate structure specifically to replace what accidental proximity used to provide. A curious question that used to happen by walking past someone's desk now has to be a scheduled, intentional check-in, or it simply stops happening.

This connects directly to Chapter 4's overcommunication principle, and remote work is where that principle stops being optional advice and becomes close to survival. A decision made in a video call that half the team didn't attend, and that never gets written down anywhere durable, effectively didn't happen for everyone who missed it.

LeMay also addresses a specific remote-work trap: mistaking synchronous availability, being visibly online and quick to respond, for actual productivity or trust. A team that measures engagement by response speed on chat is optimizing for the wrong signal, and tends to produce exhausted PMs who feel obligated to perform busyness rather than do the harder work of clear async communication.

The chapter-specific lesson: audit which parts of your current process silently depend on people being in the same physical space, whiteboard sessions, hallway check-ins, reading a room's body language during a pitch, and design a deliberate, scheduled replacement for each one rather than assuming remote tools will fill the gap on their own.

A Manager Among Product Managers (The Product Leadership Chapter)

Managing PMs carries the exact same trap Chapter 1 warned individual PMs about, just one level up. A product leader who treats their job as being the final decision-maker on every roadmap call is doing to their PMs what the mini-CEO framing does to a PM's relationship with their own team: substituting authority for coaching, and quietly teaching the people underneath them to stop exercising judgment.

LeMay's alternative: a product leader's real job is coaching the CORE skills into the PMs on their team, not reviewing and correcting every deliverable those PMs produce. A leader who reads every roadmap slide personally and fixes the wording is optimizing for this quarter's roadmap looking polished. A leader who instead asks a PM, before a big stakeholder meeting, how they'd handle pushback, is investing in a PM who can handle the next ten meetings alone.

This distinction matters most in moments of pressure, when it's genuinely faster for an experienced leader to just make the call themselves. LeMay's argument is that the short-term speed gain from doing that repeatedly costs a team its own judgment over time, the same way a parent who ties a child's shoes every morning ends up with a child who never quite learns to do it themselves.

Concretely, this chapter reframes what a good one-on-one with a PM looks like: less status-reporting on what shipped, more working through how the PM is applying CORE skills to their actual current problems, so the leader is coaching the muscle, not auditing the output.

The chapter-specific lesson: for a PM stepping into any leadership responsibility over other PMs, even informally mentoring a newer teammate, the test isn't whether you'd have made the same call they made. It's whether you can point to a specific way you helped them get better at making that kind of call themselves, next time, without you.

In Good Times and Bad

The book's closing real chapter is about what happens to everything covered so far when conditions get genuinely hard: layoffs, missed targets, a company under real pressure. LeMay's argument is direct: this is exactly the moment the CORE skills matter most, and exactly the moment teams are most tempted to abandon them.

Under pressure, the instinct is to retreat toward command-and-control: less time for curious questions because there's no time to spare, less overcommunication because everyone's stretched thin already, less patience for the slower, more collaborative version of stakeholder management from Chapter 5.

LeMay's point is that this retreat is exactly backwards. A team that stops overcommunicating during a crisis produces more confusion, not less, at precisely the moment confusion is most expensive. A leader who stops asking curious questions and starts issuing directives loses the ground-level information that a good decision under pressure actually needs most.

He's also direct about the limits of what a PM's own discipline can fix: no amount of clarity-over-comfort communication or careful prioritization can substitute for a company's actual business health, or protect a PM from a layoff decided well above their level.

This chapter isn't a promise that practicing the book's principles insulates anyone from bad outcomes. It's a case that abandoning them under pressure makes bad outcomes worse, and that holding onto them, even imperfectly, gives a team its best chance at getting through a hard period without also losing trust in each other.

The chapter-specific lesson: in your next genuinely stressful week, whatever specific practice from this book you're most tempted to skip because there's "no time," a curious check-in, writing the decision down, walking a stakeholder through an idea individually, treat that instinct to skip it as a signal of exactly which practice matters most right now.

The Entire Book in One Framework

Every chapter in this book is really one argument told from a different angle: product management is not a set of deliverables to produce, it's a set of relationships to tend, with users, with engineers and designers, with senior stakeholders, with the PMs you might one day lead, and CORE (Communication, Organization, Research, Execution) is the recurring toolkit for tending all of them well.

Curiosity is Research applied to colleagues. Overcommunication and throwing the poker game are Communication applied to teams and to power. Agile done honestly and documentation done honestly are Organization refusing to calcify into ritual. Data discipline and prioritization are Research and Organization meeting under pressure to actually decide something.

Product management was never really a job title describing what you're allowed to touch. It's a practice describing how you show up, today, to the ambiguous, unglamorous, relationship-shaped work of getting a team to build the right thing together, and the practice doesn't get easier with seniority, it just gets more consequential.

10 Most Important Takeaways

• Product management is a practice, not a fixed job description; you don't graduate from it, you keep returning to it.
• The four connective skills that actually matter are Communication, Organization, Research, and Execution, not any specific tool or technical background.
• Clarity over comfort: the harder, more specific thing to say is almost always cheaper than the vague, comfortable version.
• Asking the "obvious" question builds trust with specialists faster than staying silent to protect your credibility ever does.
• Communicate decisions roughly twice as often as feels necessary; "everyone already knows" is almost never fully true.
• Disagree and commit: real alignment requires disagreement to be voiced clearly before a decision, not suppressed to preserve the appearance of consensus.
• Let stakeholders win the visible, low-cost battles so you can steer toward the outcome that actually matters, and test big ideas one-on-one before any group reveal.
• Users are reliable about their frustration and unreliable about the fix; watch behavior and ask what they were ultimately trying to accomplish, don't just transcribe the request.
• No "data-driven" decision is free of assumptions; name the specific source and the assumption behind it, not the vague, authority-borrowing word "data" itself.
• A prioritization framework's real value is the conversation it forces between people who see the tradeoffs differently, not the score it spits out at the end.

The single deepest idea in the book: the skills that make someone good at product management are the same skills that make someone good at working with other people honestly under uncertainty. That's why the job resists being reduced to a checklist, and why getting better at it looks less like acquiring new tools and more like getting more disciplined about telling the truth, asking real questions, and following through on decisions once they're made.