In this module
- Learning objectives
- Why this module is vendor-agnostic — and why it matters
- The six recurring PM problems — independent of tooling
- What's NEW about these problems in the Adaptive era — the same problems, harder versions
- The trap of solving for the wrong problem — when tooling vendors mis-frame
- What "good" looks like for each problem — outcome criteria, not feature checklists
- Sidebar: how PM33 attacks each problem
- Discussion prompts
- Further reading
Learning objectives
After this module you should be able to:
- Name six recurring PM problems that exist independent of any tool
- For each problem, identify what changed about it in the Adaptive AI era
- Distinguish "the vendor solved the wrong problem" from "the vendor solved nothing"
- Articulate outcome criteria for each problem — what you'd need to see to know it was solved
Why this module is vendor-agnostic
Module 1 made the case that the substrate is shifting. This module steps back from the substrate question and asks: what does a PM actually spend their week on, regardless of what era they're in?
The reason for this digression is intellectual hygiene. Many product management curricula (and many product management tools) are organized around features the tool provides. That framing puts the cart before the horse — it teaches you to use a hammer rather than recognizing what's a nail.
If we name the underlying PM problems clearly, we can evaluate any tool (PM33 included) on whether it materially addresses them. We can also recognize when a vendor has named a fake problem to sell a feature, and when a real problem has been ignored because no one's built for it yet.
The six recurring PM problems
These six show up across Waterfall, Agile, and Adaptive teams. They're not specific to any era or tool stack.
Problem 1: Prioritization under uncertainty
Always-true statement of the problem: At any moment, the PM has more candidates for "next work" than the team has capacity. The candidates differ in confidence, effort, strategic value, and dependencies. The PM must pick — knowing the picks will be wrong some fraction of the time, and that "wrong" is only knowable after the fact.
What good looks like: A defensible prioritization that reflects current strategic objectives, accounts for capacity and dependencies, and produces evidence — over time — about which prioritization choices reliably moved metrics.
Common failure modes:
- Picking by squeakiest wheel (sales-led prioritization without filtering)
- Picking by spreadsheet optimization (WSJF, RICE) without acknowledging the inputs are guesses
- Avoiding the picking decision by letting the team self-select work
- Picking the same way that worked 18 months ago (Agile cargo cult)
Problem 2: Outcome measurement and attribution
Always-true statement: Without measuring whether the shipped thing moved the metric, the PM has no learning signal. Without a learning signal, the next set of prioritization decisions are no smarter than the last set.
What good looks like: For every meaningfully-scoped piece of work, a declared expected outcome (predicted metric movement), a measurement window, and a post-ship comparison — predicted vs. realized.
Common failure modes:
- No measurement at all (shipped, declared victory, moved on)
- Measurement that's hand-waved (the metric moved, was it us?)
- Measurement that's cherry-picked at quarter-end to justify the work that was done
- Conflating correlation (the metric moved while we shipped X) with attribution (the metric moved because of X)
This problem is the central differentiator of the Adaptive era, per McKinsey QuantumBlack (2025): only ~5.5% of surveyed orgs report >5% EBIT attributable to AI, and that group is defined by their attribution capability, not their adoption volume.
Problem 3: Stakeholder alignment
Always-true statement: Engineering, design, customer success, sales, support, and executive leadership all have legitimate but differing models of what the team should be doing. The PM bridges. Without alignment, even a well-prioritized roadmap becomes a political fight at every handoff.
What good looks like: Each stakeholder can articulate what the team is doing AND why, in their own language. Disagreements surface early (at scoping) rather than late (at delivery or QBR).
Common failure modes:
- One stakeholder's view dominates (eng decides priority, or sales decides priority, etc.)
- "Alignment" via lowest-common-denominator (we did the things nobody objected to)
- Late-stage discovery of misalignment (design surprise at sprint kickoff, security gate at PR review, exec ask at QBR)
Problem 4: VOC (Voice of Customer) triage at scale
Always-true statement: Customer signals flow in faster than the PM can process them. Support tickets, sales calls, NPS comments, churn interviews, feature requests, bug reports, social mentions. The triage problem is two-part: separate signal from noise, and route signal to the right place (this sprint, next quarter, future roadmap, ignore).
What good looks like: A repeatable triage process that catches high-signal items quickly, doesn't lose them, and produces a defensible answer to "why aren't we doing X?" when a stakeholder asks.
Common failure modes:
- Triage debt — the inbox grows; the PM stops reading
- Loud-customer bias — the customer who emails the CEO gets disproportionate weight
- Triage handed to a junior PM without quality controls
- Customer-success-team's tickets and product team's roadmap living in separate worlds
Problem 5: Strategy → execution translation
Always-true statement: The strategy ("become the dominant platform in mid-market HR tech") is too abstract to schedule. Individual work items are too specific to map directly to strategy. The PM translates: strategic objectives → quarterly themes → epics → work items. Each layer is a translation, and at each layer, information is lost or distorted.
What good looks like: At any layer, a team member can trace upward ("what strategic objective does this Brief support?") and downward ("for strategic objective X, which currently-active work items address it?"). The translation is legible.
Common failure modes:
- Strategy as wall art — declared in January, never referenced
- Execution as autonomous islands — each team picks its own work, weakly correlated to strategy
- Translation by PM heroics — the PM remembers the strategy and quietly steers; works until they go on PTO
- Strategy that changes too often — every quarter, the translation has to start over
Problem 6: Trade-off framing
Always-true statement: Most consequential PM decisions are trade-offs without a "right" answer. Speed vs. quality. Feature vs. tech debt. Breadth vs. depth. Customer A vs. Customer B. The PM's job is to frame the trade-off legibly so stakeholders can decide together — not to pretend the trade-off doesn't exist.
What good looks like: Trade-off decisions are documented at the moment they're made, with the considered alternatives. Stakeholders see the same frame; the PM doesn't re-litigate the same trade-off every retrospective.
Common failure modes:
- Hiding trade-offs (saying yes to everything, then triaging silently)
- Imaginary trade-offs (presenting two options when there are five)
- Asymmetric framing (always presenting "the safe choice" as default)
- One-time decisions that should have been re-evaluated
What's NEW about these problems in the Adaptive era
The six problems above are eternal. What's new in the Adaptive era is that each problem now has a higher-leverage solution and a higher-leverage failure mode.
| Problem | What's NEW in Adaptive |
|---|---|
| Prioritization | AI can compute alignment scores at scale; AR(1)-style confidence intervals on delivery; capacity-aware scheduling. Higher leverage. Failure mode: trusting the score without understanding the math. |
| Outcome attribution | Closed-loop measurement is finally tractable — predicted outcomes declared upfront, realized outcomes attributed back. McKinsey identifies this as the differentiator (2025). Failure mode: gaming the attribution layer once it's measured. |
| Stakeholder alignment | Briefs as artifacts make stakeholder requirements legible — the eng-readable parts and the security-readable parts live in the same document. Failure mode: hiding compliance impact in vague Brief fields. |
| VOC triage | AI scoring + clustering can process 10x signals in 1x time. Pam-style assistants triage overnight. Failure mode: trusting the clusters without sampling. |
| Strategy → execution | Strategic objectives become first-class entities that work items link to; the translation is auditable. Failure mode: outdated objectives nobody refreshed. |
| Trade-off framing | Conversational AI (with workspace context) can structure trade-offs faster than a human can. Failure mode: accepting the AI's framing without iterating. |
The pattern: each problem gets a powerful new tool, and each tool introduces a new failure mode. The Loop Master role (Module 4) is partly about making sure the new failure modes don't quietly replace the old ones.
The trap of solving for the wrong problem
Some vendors and methodologies sell solutions to adjacent problems that look like the real ones but aren't.
| Real problem | Tempting fake | Why the fake fails |
|---|---|---|
| Prioritization under uncertainty | "Run RICE on every Brief" | RICE inputs are still guesses — the score is fake precision |
| Outcome attribution | "Track every metric in a dashboard" | A dashboard isn't attribution — it's surveillance |
| Stakeholder alignment | "More meetings" | More meetings reveal misalignment without producing alignment |
| VOC triage | "Tag everything in Zendesk" | Tagging is filing, not triaging — without scoring it's noise |
| Strategy → execution | "Annual OKR cycle" | OKRs help; the translation problem persists between them |
| Trade-off framing | "Decision logs" | Logs help; the framing skill isn't logged, it's practiced |
A good test of any tool you're evaluating: which of the six problems does it materially attack, and which is it adjacent to? If the answer is "it does five things adjacent to the real problems," you have a fake solution. If the answer is "it makes three of the six problems easier and the rest unchanged," you have a real but partial solution. Most tools are partial. That's fine — you stack tools to cover the rest.
What "good" looks like — outcome criteria per problem
For each problem, here's what evidence of good would look like at your team:
- Prioritization — you can point at last sprint's top-ranked items and explain why they were top, in language that survives "why not the other things?"
- Outcome attribution — for at least 60% of shipped work in the last quarter, you can say "this is the metric we predicted would move, here's whether it did, here's the confidence." 60% is realistic; 100% means you're either lying or not shipping enough to learn from
- Stakeholder alignment — fewer than 1 "design / security / eng surprise" event per sprint. Surprises are a signal of upstream alignment debt
- VOC triage — your VOC inbox doesn't have a backlog of items "I'll get to those." A backlog there means triage isn't running
- Strategy → execution — pick a random Brief in flight; the team member working on it can name the strategic objective it ladders to within 30 seconds
- Trade-off framing — at last retro, the team can name at least one trade-off you framed clearly and one you didn't. Both are useful — bothering with the unclear one teaches the team you take framing seriously
Sidebar — how PM33 attacks each problem
PM33 takes a position on each of the six. The position isn't "PM33 solves problem X." It's "here's how PM33 reduces the failure surface for problem X."
| Problem | PM33's mechanism |
|---|---|
| Prioritization | pm33_optimize_priorities — strategic alignment × AR(1) confidence × capacity × dependencies. Reserves 20% for origin: bottom_up work (tech debt). |
| Outcome attribution | outcomeHook field on every Brief; attribution computed at the configured measurement window; recalibration history visible. |
| Stakeholder alignment | Brief schema with named fields per stakeholder (specification → eng, outcomeHook → exec, side effects → security, edge cases → design). |
| VOC triage | Pam overnight triage with workspace-objective alignment scoring; PM confirms or corrects top 5-10 daily. |
| Strategy → execution | strategic_objectives table; every Brief links to an objective; score_alignment computes the mapping. |
| Trade-off framing | Pam conversational planning ("I'm choosing between X and Y — what am I missing?") |
What PM33 explicitly does NOT do for each:
- It doesn't decide for you when the inputs to prioritization are guesses
- It doesn't tell you whether the attributed metric movement is the right metric
- It doesn't run the human conversation that produces stakeholder alignment
- It doesn't read VOC items for you — it scores; you confirm
- It doesn't fix strategy that's confused
- It doesn't make the trade-off — it frames
That distinction — what the system does vs. what the human still owns — is the running theme of the curriculum. Module 4 covers the role boundary in depth.
Discussion prompts
- Pick the problem you currently struggle with most. What have you tried? What worked, what didn't?
- For each problem, name your current tool. Is it attacking the real problem or the adjacent fake? If adjacent, why are you using it?
- Which of the six problems is easier today than it was 5 years ago, given the tools you have? Which is harder?
- What would you need to see in the next 6 months to believe outcome attribution is solved at your org?
Further reading
- John Cutler — "The Product Outcomes Formula" — defines the closed loop in PM-native terms
- Lenny Rachitsky — "How AI will impact product management" — the new PM skill set
- Marty Cagan — Transformed (2024) — operating-model lens on the same six problems
- Next module: PM Module 3 — Sprints → Loops