The Product Casebook · Nº 33
A field course for the mid-career professional
Every profession has a center of gravity. Law orbits precedent and risk allocation; engineering orbits correctness; medicine orbits diagnosis. Product management orbits a question that sounds simple and is not: of everything we could build, what should we build next — and how will we know it worked? This module establishes what the job is, what it is emphatically not, and the operating posture everything later in this course assumes.
Strip away the job-listing language and a PM owns three things: a defensible answer to which problem we solve next, a clear statement of what success looks like, and the connective tissue between customers, engineers, designers, executives, sales, and support — people who otherwise optimize locally and collide.
Notice what is missing: authority. Engineers do not report to you. Designers do not report to you. You usually control no budget. This is by design, not oversight. The role works through earned influence — being so demonstrably well-informed about the customer and the evidence that people choose to follow your reasoning. The day you say "because I said so," you have already lost.
Lawyers and consultants recognize this instantly: a litigator does not order a judge to rule favorably, and a consultant cannot command a client. Both win through preparation, framing, and the quality of the argument. Product is the same posture, applied daily, to an audience of your own colleagues.
The practical consequence: a huge fraction of PM craft is making your reasoning legible. Decisions written down. Evidence cited. Tradeoffs named. Not because process is virtuous, but because legibility is how influence compounds.
An output is a thing you shipped: the feature, the redesign, the integration. An outcome is what changed because you shipped it: more users activating, fewer churning, support tickets down, revenue up. Teams gravitate to outputs because outputs are controllable — you can promise a feature by March and deliver it. You cannot promise that churn drops.
But nobody buys outputs. A roadmap full of shipped features and unchanged metrics is a busy failure. The discipline of outcomes over outputs shows up everywhere downstream of here: roadmaps stated as metric movements rather than feature lists, success criteria written before the build starts, and the willingness to call a launched feature a miss when the needle doesn't move.
Taken fundamentalist, "outcomes only" stalls teams that genuinely can't measure yet — early products, long sales cycles, platform work. The mature version: state the intended outcome always, measure it when you can, and use explicit leading proxies when you can't. The sin isn't shipping outputs; it's never asking what they were for.
Two structural ideas shape how modern product teams run. The first is the product trio — PM, design lead, engineering lead — making discovery decisions together rather than the PM deciding alone and relaying instructions. The reason is error rates: a PM deciding solo silently embeds guesses about feasibility (engineering's domain) and usability (design's domain) into every call. The trio catches those guesses at the cheapest possible moment — before anything is built.
The second is dual-track development: discovery and delivery run in parallel, continuously. While engineers build this sprint's validated work, the trio is interviewing, prototyping, and testing next month's bets. Discovery is not a phase that ends; it is a standing process, like case intake at a firm that never stops accepting clients.
You can diagnose a product org's health by asking one question: when did this team last talk to a customer? Weeks-ago is healthy. Quarters-ago means the team is navigating by memory, and the roadmap is fiction with version numbers.
Three failure modes recur so reliably they deserve names.
Security engineers know the third trap as assuming the threat model instead of enumerating it; trial lawyers know it as falling in love with your theory of the case before depositions. Same antibody in all three fields: go look.
Discovery is the evidence-gathering arm of product work, and it is where most product failures are quietly authored — months before launch, in conversations that confirmed what the team already believed. This module covers the demand-side lens (Jobs to be Done), interview technique that survives human politeness (the Mom Test), and the synthesis structures that turn raw conversation into decisions (affinity mapping and the opportunity solution tree).
Jobs to be Done reframes the unit of analysis. Customers do not buy products because of who they are; they hire products to make progress in a circumstance. The canonical study: a fast-food chain trying to sell more milkshakes got nowhere segmenting by demographics — then noticed that roughly 40% of milkshakes sold in the early morning, to solo commuters who needed something one-handed, slow to consume, and filling for a boring drive. The milkshake's real competitors were bagels and bananas, not other milkshakes. Same product, totally different improvement agenda.
Jobs have three dimensions worth separating: functional (the practical task), emotional (how the customer wants to feel), and social (how they want to be perceived). B2B software is saturated with the last two — half of enterprise purchasing is "make me look competent to my boss" wearing a functional costume.
JTBD's failure mode is altitude. Abstract far enough and every product's job is "save time" or "feel confident" — true, and useless. A job statement is load-bearing only if it is specific enough to exclude things: it should make some features obviously wrong. If your job statement couldn't rule anything out, climb back down.
People lie in interviews — not maliciously, but socially. They want to be encouraging, they answer hypotheticals with aspiration, and they tell you they would "definitely use" something they will never open. The Mom Test (Rob Fitzpatrick) is a rule set that extracts truth even from someone motivated to flatter you, hence the name: questions so grounded that even your mother couldn't mislead you with kindness.
This is deposition craft. A litigator never asks "would you have stopped at the light?" — they ask what the witness did, in sequence, with times and names, and they let contradictions surface on their own. Open questions, no leading, follow the documents. If you have examined witnesses, you hold a rare discovery advantage: you already know that the question shapes the answer.
Eight interviews produce maybe four hundred discrete observations, and unstructured memory will keep the vivid ones, not the representative ones. Affinity mapping is the standard antidote: decompose every transcript into atomic notes — one observation each, tagged to its source — then cluster notes that seem to describe the same underlying thing, and only then name the clusters. The order is the whole method. Name the buckets first and you will sort the evidence into your priors; sort first and the themes name themselves, sometimes surprisingly.
Two habits raise synthesis from craft to evidence:
Eight interviews is not a sample; it is a source of hypotheses and a map of the language customers use. Qualitative work tells you what exists and why; it cannot tell you how much. Pair every "we heard this repeatedly" with a plan to count it — a survey, usage data, win/loss records — before betting a roadmap on it.
Teresa Torres's opportunity solution tree is a one-page map with four layers. At the root, the outcome you're driving (a metric, from your North Star tree — Module 06). Below it, opportunities: customer needs, pains, and desires surfaced by discovery, phrased in customer language. Below each opportunity, candidate solutions — plural, deliberately, because the first idea is rarely the best and a single-child solution node is a confession that you decided before you explored. At the leaves, experiments that test the riskiest assumption of a solution cheaply.
The tree's value is the connective tissue. Every feature idea must answer "which opportunity?" and every opportunity must answer "which outcome?" When an executive proposes a feature, you don't argue with it — you place it on the tree, which either reveals its logic or its absence. It converts "no" from confrontation into geometry.
The tree is also your best defense against discovery theater — teams that interview constantly but build whatever they already wanted. If months of interviews never change the tree's shape, the research is decoration.
Most product requests arrive as solutions wearing trench coats: "we need a dashboard," "customers want an API," "add SSO." The single highest-leverage habit in product work is refusing to accept a solution as a starting point — excavating the problem underneath, framing it testably, and then asking the question every framework downstream depends on: how much is solving this actually worth?
A problem statement is a short contract: who has the problem (a specific segment, not "users"), what happens and in what circumstance, what it costs them (time, money, risk, standing — quantified when possible), and how we'll know it's solved (observable, testable criteria). Four elements, a few sentences, no solution anywhere in it.
The no-solution rule is strict because embedded solutions foreclose the search. "Customers need a dashboard" permits exactly one answer. "Account admins can't tell which seats are unused, so renewal conversations stall for weeks" permits a dashboard — and also an email digest, an in-flow warning, a CSV export, or a change to the pricing model that makes the question moot. The cheapest of those might be a hundredth the cost of the dashboard.
Lawyers will recognize issue framing: the side that frames the question usually wins the argument, which is why so much appellate combat is over the question presented rather than the answer. Physicians will recognize the symptom/diagnosis line — prescribing for the presenting complaint without differential diagnosis is malpractice in both fields.
Five Whys is the simplest excavation tool: take the reported symptom, ask why it happens, then ask why that happens, until you hit something worth fixing. Sales says "we need feature parity with Competitor X." Why are we losing? Because prospects raise X's feature list in late-stage calls. Why does it land? Because our champion can't rebut it. Why not? Because we've never armed them with a counter-positioning story. The fix might be a battlecard and a positioning fix — weeks, not quarters of parity engineering.
The skill is choosing the floor to stop on. Go too shallow and you treat instances forever; too deep and you arrive at causes outside anyone's control. Stop where two things are true: you can act, and acting kills the class of problem, not just today's example.
Five Whys assumes a single causal chain. Real product problems are usually multi-causal — churn is onboarding and pricing and a competitor, in proportions that matter. Use Five Whys to generate candidate causes, then check each against data. A clean causal story arrived at in a conference room is a hypothesis, not a finding — and the most articulate person in the room is not therefore correct.
The nested trio: TAM (total addressable market — everyone who could conceivably buy), SAM (serviceable — the slice your product and channels can actually reach), SOM (obtainable — what you can realistically win, given competition and capacity). The trio's real job is forcing you to admit those are three different numbers, usually separated by orders of magnitude.
The method matters more than the acronym. Top-down sizing — "payments is a $2 trillion market; capture 0.5%" — is rhetorically impressive and analytically empty, because the percentage is a mood. Bottoms-up sizing builds from countable units: 12,000 mid-market firms in segment × 30% with the problem acutely × $15k realistic contract × 10% obtainable share over three years. Every factor is now a named, checkable assumption that someone can attack — which is precisely what makes the number credible when it survives.
This is damages-expert discipline: a damages model survives cross-examination only if each input traces to evidence, and one indefensible assumption taints the whole figure. Treat your sizing model as if opposing counsel gets to depose it — because in any serious roadmap review, someone effectively will.
Three roles hide inside the word "customer": the user (hands on the product daily), the buyer (controls budget), and the decision-maker (sometimes a third party — a CISO, a procurement committee). In consumer products they're usually one person. In B2B they almost never are, and they want different things: the user wants their Tuesday easier; the buyer wants a number on a slide; the security reviewer wants to say no safely. Products fail by delighting one constituency and starving another — beloved tools that can't pass procurement, and procurement-proof platforms users despise.
Segmentation has the same test as a job statement: does it change decisions? "SMB vs. enterprise" is useful if those groups need different things from you; decorative if it just shades a slide. The best segmentations cut by need or behavior (the job, the workflow, the trigger event) rather than by firmographics — company size correlates with needs but is rarely the need itself.
Personas — fictional composite characters with names and stock photos — were invented to build empathy, and they curdle into fiction fast: teams confidently citing "what Sarah wants" when Sarah is a collage from a 2022 offsite. A persona is only as good as the recency of the research behind it. If nobody can name the real interviews underneath, retire the character.
Prioritization frameworks exist because "what should we build next" is a fight, and unstructured fights are won by seniority and volume. A scoring system converts the fight into an argument about named assumptions — which is enormous progress, as long as nobody mistakes the score for the truth. This module covers the three workhorses and the judgment layer above them, including the most underrated PM skill: the well-delivered no.
RICE scores each candidate: Reach (users or events affected per quarter), Impact (how much it moves the target outcome per user — coarse scale: 3 massive, 2 high, 1 medium, 0.5 low), Confidence (how much evidence backs your Reach and Impact guesses — 100% / 80% / 50%, and below 50% means "go do discovery, not arithmetic"), divided by Effort in person-months. Multiply, divide, rank.
The naive reading is that the ranking is the deliverable. The grown-up reading: RICE is a machine for making people say their assumptions out loud in comparable units. "I think this reaches 4,000 users a quarter with high impact, and I'm 80% confident" is checkable. "This is obviously critical" is not. When two people disagree on a score, RICE tells you exactly which factor they disagree about — which converts a status contest into a research question.
Three standing failure modes. False precision: a RICE score of 847 vs. 812 is a coin flip wearing four significant figures — treat scores as bands, not ranks. Garbage in: confident-sounding Reach numbers invented in the meeting laundromat into objective-looking output. Incrementalism bias: RICE structurally favors measurable near-term wins over strategic bets whose reach is unknowable — score a platform migration honestly and it loses to every button-color fix forever. Strategy (Module 05) has to outrank the spreadsheet.
Cost of delay rotates the value question ninety degrees: not "how valuable is this feature?" but "what does each week of not having it cost?" Some work loses little by waiting; some bleeds — a compliance deadline with penalties, a feature gating a signed enterprise deal, a seasonal window that closes in October whether you ship or not. Static scoring treats all of these as equally patient. They are not.
WSJF (weighted shortest job first) operationalizes it: divide cost of delay by duration, do the highest ratio first. The intuition is queueing math, but the everyday version is familiar to anyone who has triaged anything: short urgent things before long patient things, and the expensive-to-delay before the cheap-to-delay.
Finance people will recognize the time value of money with shipped software as the asset; lawyers will recognize statute-of-limitations triage — the motion due Friday outranks the better-paying matter due next quarter, regardless of which client is larger. You have done cost-of-delay reasoning your whole career; this just names it.
The Kano model sorts features by how their presence and absence affect satisfaction, and the three main classes follow different physics. Basics: expected hygiene — login that works, data that doesn't vanish. Their presence earns zero credit; their absence is rage. Performance features: the more-is-better axis — speed, capacity, accuracy — where investment converts linearly into satisfaction and marketing copy. Delighters: unexpected gifts nobody would have asked for, whose absence costs nothing and whose presence creates disproportionate affection and word of mouth.
The model's teeth: these cannot be traded on one scale. No quantity of delight compensates for a broken basic — a wondrous AI feature in a product that loses data is a wondrous feature in a product nobody will use. And the categories decay downward: automatic save was a delighter once; it is a basic now. Whatever your competitors made standard last year stopped earning you credit this year.
Kano explains a pattern that confuses new PMs: why customers never mention the thing that will make them leave. Nobody requests "don't corrupt my files" — basics live below the level of speech until they fail. Surveys and feature-request lists systematically overweight performance features and underweight basics, because basics are invisible until broken. Audit them directly; don't wait to be told.
Every prioritization framework is ultimately machinery for the same output: saying no, repeatedly, to people you need, without spending the relationship. The craft has three parts.
Negotiators will recognize this as principled refusal — rejecting positions while honoring interests. The requester's interest (their deal, their customer, their metric) is legitimate; the position (build my feature now) is what's being declined. Address the interest and the position fight usually dissolves.
"Strategy" is the most abused word in business — most documents bearing the name are goals with adjectives. A real strategy is closer to a legal theory of the case or a clinical diagnosis: a falsifiable claim about what is actually going on, and a coherent response that concentrates force where it matters. This module gives you the test for telling them apart, and the two strategic choices — positioning and focus — that determine whether everything downstream compounds or cancels.
Richard Rumelt's kernel says a strategy has exactly three parts. A diagnosis: a claim about what is essentially going on — "we lose mid-market deals not on features but because evaluation takes three weeks and our competitor's takes one afternoon." A guiding policy: the chosen overall approach — "win on time-to-value; be the product a team can adopt without asking permission." And coherent actions: concrete, mutually reinforcing moves that execute the policy — self-serve onboarding, transparent pricing, a free tier sized to a single team, documentation as a first-class product.
The diagnosis is the part everyone skips and the part that does the work. It is a falsifiable claim — it could be wrong, which is exactly what makes it useful, because everything downstream inherits its testability. "Grow 40% this year" is not a strategy; it is an ambition. It diagnoses nothing, excludes nothing, and gives a team facing a tradeoff no guidance whatsoever.
This is theory-of-the-case discipline. A litigator doesn't walk into trial with "win big" — they commit to a theory ("this is a documents case about what the seller knew in March") that dictates which witnesses, which exhibits, which arguments, and crucially which otherwise-good material gets left out. Same with clinical diagnosis: treatment without diagnosis is quackery, however energetic.
The fastest audit of any strategy document: what does this forbid? Strategy is the allocation of insufficient resources — if you had enough to do everything, you wouldn't need one. So a real strategy names what you will not do: the segment you won't serve, the deal you'll walk from, the feature category you concede to competitors. "Be the best platform for everyone" forbids nothing and is therefore nothing.
This is also where strategy connects back to prioritization (Module 04): the guiding policy is what breaks RICE ties, overrules incrementalism, and tells the team facing two good options which one is on strategy. Without it, every prioritization meeting re-litigates direction from scratch, and the loudest recent anecdote wins.
Focus can curdle into blindness. The exclusions in a strategy were derived from a diagnosis, and diagnoses expire — markets shift, competitors move, the thing you correctly ignored in 2024 becomes the thing eating you in 2026. Treat the diagnosis like a scientific claim under standing review: schedule the re-examination (quarterly is typical), and name in advance what evidence would falsify it. Strategy should be stubborn; the diagnosis underneath it should not be.
Positioning (April Dunford's formulation) is the deliberate choice of the frame of reference in which your product is evaluated. The same product is a "lightweight CRM," a "shared inbox for sales teams," or a "pipeline tool for founders" — three frames, three competitor sets, three pricing norms, three different verdicts on the identical software. Customers cannot evaluate a product in a vacuum; they reach for the nearest category and judge you by its rules. Positioning is choosing which rules you'll be judged by, instead of letting the market choose lazily for you.
The method, compressed: start from your best customers (the ones who got it instantly and grew), identify what they treated as your true alternative (often a spreadsheet, an intern, or doing nothing — not a rival vendor), isolate the capabilities only you have against that alternative, map them to value the customer banks, and only then pick the market category that makes all of it obvious.
"We have no real competitors" is a sentence that should trigger alarm, not pride. It usually means no category, which means no budget line, no evaluation criteria, and no urgency — the customer's real competitor to you is doing nothing, and doing nothing is undefeated. Position against the status quo explicitly or it beats you silently.
The Lafley/Martin compression of strategy into two questions travels well to product: where to play — which segment, which geography, which problem space, which buyer — and how to win there — the specific advantage that beats the alternatives in that arena. Each answer constrains the other: a "how to win" that works for self-serve developers fails for procurement-led enterprise, and vice versa. Most incoherent roadmaps trace back to an unresolved where-to-play fight that nobody surfaced.
Keep the altitude layers distinct, because conflating them produces the worst documents in the genre: vision is the destination — the world several years out if you succeed. Strategy is the chosen route, including the routes rejected and why. The roadmap is the next stretch of road: sequenced bets, stated (per Module 01) as outcomes. Vision rarely changes; strategy changes when the diagnosis changes; the roadmap changes often and that's fine — it's the layer built to absorb new information without destabilizing the layers above.
Beware the strategy deck assembled from frameworks — twenty slides of 2×2s, SWOT quadrants, and category maps with no falsifiable diagnosis anywhere in them. Frameworks organize thinking; they do not perform it. If you removed every framework from the deck, a real strategy would still be there in three sentences. If nothing is left, nothing was there.
Metrics are how a product team knows whether anything it believes is true. They are also the easiest place in the discipline to fool yourself with rigor-flavored nonsense: dashboards of vanity numbers, A/B tests read like horoscopes, and targets that quietly corrupt the behavior they measure. This module builds the metric stack top-down — North Star, input tree, guardrails — then teaches the defensive reading skills that keep experiments honest.
A North Star metric is the one number that best proxies value delivered to customers — chosen so that moving it almost certainly means the business is healthier too. The classic illustrations: Airbnb's nights booked, Spotify's time listening, a B2B tool's "weekly teams completing the core workflow." The test is alignment: a North Star you could inflate while customers got less value (page views, time-on-site for a productivity tool) is a trap with a dashboard.
But a North Star alone is unactionable — it's too aggregate, moves too slowly, and no single team owns it. Hence the input tree: decompose the North Star into 3–5 driver metrics, each movable by a specific team on a sprint timescale. "Weekly active teams" decomposes into new-team activation rate, weekly feature-X usage per team, and resurrection of dormant teams. Now each team has a metric it can push this week, with an explicit causal claim connecting its work to the number the company steers by — and that causal claim is itself testable, which keeps the tree honest.
Security people: this is exactly your relationship between "breaches prevented" (unmeasurable directly, lagging, aggregate) and the controls dashboard you actually manage daily. Clinicians: outcome measures vs. process measures. Every field that manages toward a slow outcome builds this same two-layer structure.
Two distinctions organize the entire metrics conversation. First, leading vs. lagging: lagging indicators (revenue, churn, NPS) tell you what already happened — they're the scoreboard, trustworthy and useless for steering, because by the time churn moves the causes are a quarter old. Leading indicators (activation within 7 days, breadth of feature adoption, support-ticket velocity) move early enough to act on, at the price of being proxies whose link to outcomes is a hypothesis you must keep checking.
Second, vanity vs. load-bearing. The vanity test takes one sentence: if this number halved or doubled next month, what would we do differently? Cumulative signups, total downloads, lifetime registered users — these only go up, flatter every all-hands deck, and answer the test with silence. Load-bearing metrics are usually rates, ratios, and cohort comparisons: retention by signup month, activation rate, revenue per account. Cohorts especially — the question is rarely "how big is the number" and almost always "is it getting better for newer customers than it was for older ones."
The leading/lagging structure has a failure mode: teams optimize a leading proxy long after its link to the outcome has decayed. Activation correlated with retention in 2024; the product changed; it may not now. Every input metric on your tree carries an implicit causal claim with an expiration date — re-validate the correlations on a schedule, or you'll steer briskly toward a place that no longer exists.
An A/B test is the cleanest tool product has — randomization genuinely isolates cause — and it is still routinely misread. The defensive checklist:
The integrity move is pre-registration, and lawyers already know why it works: it's the discipline of committing to your theory before seeing how the evidence falls, because a story constructed after the fact can always be made to fit. Decide the primary metric, the sample size, and the ship/kill rule before launch, in writing.
Goodhart's law: when a measure becomes a target, it ceases to be a good measure. The metric was a proxy for something real; the moment incentives attach, people optimize the proxy directly, and the gap between proxy and reality becomes the easiest place to mine. Support teams told to maximize tickets-closed close tickets prematurely. Sales teams comped on logos sign customers who churn in month two. A team targeted on activation redefines activation.
Note what the law does not say: that targets are bad. It says targets are corrosive to their own instrumentation, so measurement needs maintenance. The standard defense is guardrail metrics — paired numbers chosen specifically to catch the likely corruption. Target activation, guardrail week-4 retention (catches hollow activations). Target signup conversion, guardrail onboarding completion (catches dark-pattern signups). Target velocity, guardrail defect rate. Choosing guardrails well requires imagining, in advance, exactly how a clever team would game the target — adversarial thinking, applied to your own incentives.
Anyone who has worked near compliance metrics, billable-hour targets, or security-audit checklists has watched Goodhart operate at industrial scale. The product version is gentler but identical. When a metric starts improving suspiciously smoothly, the first hypothesis isn't success — it's that someone found the seam.
Execution is where product reputations are actually made — not because shipping is more important than strategy, but because it is more visible, more frequent, and more failure-prone. The PM's execution job is not managing engineers; it is removing ambiguity before it becomes rework, slicing work so value arrives early, and handling the inevitable slip without burning trust. Unglamorous, learnable, compounding.
Call it a PRD, a one-pager, a brief — the artifact is the same: a written answer to the questions the team will otherwise ask serially, expensively, mid-build. The load-bearing sections: context (why this, why now — two paragraphs); the problem statement (Module 03, verbatim); success criteria (the measurable outcome, committed before building, so post-launch evaluation isn't a creative-writing exercise); scope edges — what's explicitly in and, more importantly, explicitly out, because unwritten exclusions become assumed inclusions; open questions, honestly listed, because pretending certainty you don't have is how specs lie; and the flows and edge cases that account for most clarifying questions: what happens on failure, with zero data, at the permissions boundary.
Length is a cost, not a virtue. The test of a spec is functional: an engineer can build from it without three rounds of questions, and a skeptic can determine afterward whether it worked.
Good specs are good contract drafting. Both exist to allocate ambiguity before it becomes a dispute; both are tested not by the happy path but by the edge case; and in both, the silent term is the dangerous one. If you have drafted agreements, you already know the discipline — define terms, enumerate the cases, say what happens when things fail.
The instinct when facing a big build is to slice it by layer: first the data model, then the services, then the UI, then integration. This is horizontal slicing, and it has a fatal property: nothing works until everything works. Value arrives at the end; so does the discovery of every wrong assumption, at the moment it's most expensive to fix.
The alternative is the walking skeleton: the thinnest end-to-end slice that touches every layer and does one real thing for one real user — ugly, narrow, and alive. Then you fatten it, slice by vertical slice, each one shippable. The benefits compound: integration risk surfaces in week two instead of month four; users react to something real early, while the roadmap can still respond; and the team always has a working product, which transforms every status conversation from "percent complete" (a fiction) to "here's what it does now" (a demo).
The companion skill is user-story hygiene: work expressed as who-needs-what-why ("an account admin can export seat data, so renewals don't stall") with acceptance criteria — the testable conditions of done. The why-clause isn't ceremony; it's what lets an engineer make the right micro-decision at 4pm without finding you.
Some work genuinely doesn't slice — a migration with a hard cutover, a cryptographic protocol, a regulatory all-or-nothing. Forcing vertical slices onto truly indivisible work produces waste dressed as agility. The honest move is recognizing indivisibility, isolating it, and managing it as the high-risk block it is — with the pre-mortem treatment below.
Every slipping project resolves through one of three levers: scope gives (ship less), time gives (ship later), or quality gives (ship worse). There is no fourth option, and "the team works harder" is the quality lever wearing a motivational poster. The PM's job is not picking the lever alone — it's making the choice explicit and owned, because the disaster pattern is the implicit version: the date holds, the scope holds, and quality quietly absorbs the difference, invisibly at first, then as a year of incidents.
Default to scope. A well-sliced project (previous section) makes scope-cutting cheap: drop the outermost slices, ship the core, and the cut is a roadmap adjustment instead of a crisis. Time is the second resort, expensive in trust — which is why slips communicated early with a new committed date cost less than slips communicated late with optimism. Quality should give last and on the record: a named shortcut, a ticket for the repayment, a date for it.
When engineering says a feature needs more time for testing or refactoring, the PM who overrides them has just chosen the quality lever — without saying so, and usually without the standing to evaluate the risk. The right response is to interrogate the tradeoff (what breaks if we don't? how likely?), then choose a lever in daylight.
A pre-mortem inverts the post-mortem: before work begins, the team time-travels to the failure — "it's six months out; the launch flopped" — and each person independently writes the story of what went wrong. Then you collect, cluster, and assign owners to the top risks.
The trick is psychological, and it works on professionals who are too smart for ordinary risk checklists. In a planning meeting, raising risks is socially expensive — you're the pessimist dampening the room. In a pre-mortem, failure is stipulated; producing reasons is the assignment, and prospective hindsight reliably extracts concerns people were sitting on. The quiet engineer's "the vendor API has never handled our volume" surfaces in a pre-mortem and almost never in a kickoff.
The same discipline extends to launch readiness: a launch is not the code being done. It's support knowing what's changing and what tickets will look like; sales and CS armed before customers ask; instrumentation live before the traffic arrives (you cannot retroactively measure a launch); a rollout plan with stages and a rollback trigger decided in advance — deciding "what would make us pull this" while calm, not at 2am with the dashboard red.
Security engineers will recognize the pre-mortem as a tabletop exercise, and rollback triggers as incident-response runbooks. Litigators will recognize launch prep as trial prep — the witnesses prepared, the exhibits ordered, and the answer ready for the question you hope nobody asks.
Module 01 established that the PM role runs on influence rather than authority. This module is the machinery: mapping who actually needs what, writing so that busy powerful people decide in your favor, and the meeting craft that converts discussion into decisions. If you arrive from law, consulting, or sales, this is your home module — the frameworks here will feel like naming things you already do. The product-specific part is calibrating them for an audience you'll work beside for years, not a judge you'll never see again.
The power–interest grid sorts stakeholders along two axes: power to affect your work, and interest in it. The quadrants prescribe different treatment, and treating them identically wastes your scarcest resource — attention. High power, high interest (your exec sponsor, your engineering lead): manage closely; these are partners, and surprises to them are self-inflicted wounds. High power, low interest (the CFO, the GC, an adjacent VP): keep satisfied — short, well-timed updates that require nothing of them, calibrated so their first detailed encounter with your project is never in a crisis. Low power, high interest (support leads, power users, the solutions engineer who lives in customer calls): keep informed and cultivate — they're your early-warning network and the source of your best evidence. Low power, low interest: a polite distribution list.
The grid's killer insight is the ambush quadrant: high power, low interest. These stakeholders ignore your project for two quarters, then attend one review and redirect it in forty minutes — not from malice, but because nobody kept their mental model current at the cadence their attention allowed. The few sentences a month that keep them satisfied are the cheapest insurance in the discipline.
The grid is a snapshot of an org that's actually a moving picture — reorgs, promotions, and shifting priorities redraw it quarterly. And power is not the org chart: the staff engineer with the CTO's ear and the EA who controls the calendar hold grid positions no diagram shows. Redraw it when the org moves, and map actual influence, not reporting lines.
Professionals trained in research, law, or science write in discovery order: background, analysis, evidence, and — at last, earned — the conclusion. Executive communication inverts this. The pyramid principle (Barbara Minto): conclusion first, then the two or three arguments supporting it, then the evidence under each. The reader who stops early — and they will — leaves with your answer instead of your throat-clearing.
SCQA compresses the setup when context is genuinely needed: Situation (what's true, undisputed, one or two lines), Complication (what changed or broke), Question (the decision now posed), Answer (your recommendation) — then the support. The five-minute exec update from the diagnostic statement is exactly this: "I need a decision on X. I recommend A, because of three things…" — decision named in sentence one, recommendation in sentence two, reasoning after.
Appellate lawyers already write this way — the brief leads with the holding you want, and nobody buries the lede past page one. The adjustment for product is tonal, not structural: a brief is written to defeat an adversary who reads it once; a product memo is written to inform a colleague who'll work with you for years. Keep the structure, drop the advocacy — state the strongest case against your own recommendation yourself, before someone else does it less charitably. In this audience, visible even-handedness is the persuasive move.
Amazon's PRFAQ: before any code, write the press release for the finished product — customer-named, benefit-led, quote from a delighted user — plus the FAQ, where the genuinely hard questions live: How is this different from X? What does it cost? What about the obvious objection? The format is a forcing function. Vague value propositions that hide comfortably inside a roadmap line ("improved analytics experience") die in daylight when forced into a press release a real journalist would read. If the press release is boring, the product will be boring, and you've learned it for the cost of an afternoon.
The deeper practice is writing as the decision mechanism. Meetings reward fast talkers and confident delivery; documents reward thought. A written narrative read silently at the start of a review (the Amazon ritual) means the room debates the actual proposal rather than each attendee's skim of it, the author has pre-confronted the hard questions, and there is a record of what was decided and why — which Module 01's legibility principle predicted you'd need. Six months later, when the context has evaporated, the document remembers what everyone agreed the plan was.
The FAQ section has a quality test: it should contain at least one question you genuinely struggled to answer. A PRFAQ whose every answer is smooth is an advocacy document, not a thinking document — you've written the direct examination and skipped the cross.
Meetings about decisions fail in two symmetric ways: the room that argues forever (chasing unanimous agreement), and the room that "aligns" instantly and then quietly doesn't execute (fake agreement, no alignment). The vocabulary that fixes both: agreement is everyone concurring; alignment is everyone executing the decision whether or not they'd have made it. Alignment is the requirement. Agreement is a luxury, pleasant when available.
The machinery: name the decision-maker before the debate — most decision meetings fail at this step zero, with everyone assuming a different person holds the pen. Frame options rather than open questions ("we choose between A and B; here's the tradeoff" beats "thoughts on direction?"). Make dissent cheap and explicit at decision time — the meeting where dissent is unwelcome is the meeting that produces sabotage by lethargy later. Then disagree and commit: once decided, dissenters — including you, when you lose — execute fully. Relitigating decided questions is the tax that makes orgs slow; so is pretending consensus that doesn't exist.
Negotiation training transfers here nearly whole: separate the people from the problem, trade on interests rather than positions, and know your BATNA — in stakeholder terms, what you'll do if this room won't decide (escalate with the tradeoff attached, run the cheap experiment, ship the reversible version). A PM with a BATNA negotiates differently than one who needs the room's blessing, and the room can tell.
This is the complete text of the course. With JavaScript enabled, this same page runs the interactive edition — a self-diagnostic that reorders the syllabus around your gaps, knowledge checks, applied worksheets with model answers, and a spaced-repetition review queue — with progress saved locally in your browser.