Senior PMs rarely get handed a ticket — they get handed fog: "improve retention," "fix onboarding," "figure out enterprise." The job before the job is converting that fog into a framed problem statement you can bet against, using a repeatable sequence from symptom to hypothesis to a smallest testable slice.
Quick Answer: Don't start by asking "what should I build." Start by naming the observed symptom, writing a falsifiable problem statement, forming a testable hypothesis, and picking the smallest slice that would prove or kill it — in that order, before any solution talk.
Why Ambiguity Shows Up as a Tax, Not a Gift
Open-ended charters feel like autonomy but function like a tax: every week spent un-framed is a week of runway burned with nothing bettable to show for it. The cost is invisible until a leadership review asks "so what are we actually solving," and there's no crisp answer.
This is structurally different from feature work. A backlog ticket already encodes someone else's framing — the problem was defined upstream, and your job is execution quality. An ambiguous mandate like "improve retention" has done none of that work. It's a symptom wearing the costume of a goal, and treating it as a goal is the single most common way senior PMs waste a quarter.
The tax has three components, and naming them helps you notice which one you're paying:
- Framing debt — time spent building before the problem is defined, which usually means rebuilding later
- Alignment debt — stakeholders who nodded at "improve retention" discover mid-project they meant different things by it
- Reversibility debt — early architecture and roadmap commitments made under a vague mandate are expensive to unwind once the real problem surfaces
Leadership isn't withholding clarity to test you. Often they genuinely don't have it — that's precisely why the role exists at the senior level. The senior PM's job is increasingly this: converting ambiguity into decision-ready structure, not just executing a structure someone else already built.
From "What Do I Build" to "What Problem Am I Solving"
The reflex under ambiguity is to reach for a solution — a roadmap slide, a feature idea, something concrete to show progress. Resist it. The first 40-60 word answer to "what do I build" should always be "I don't know yet, because I haven't confirmed what problem this is actually a symptom of."
That reframe changes your first deliverable. Instead of a feature list, your first artifact is a problem statement — a single sentence naming who is affected, what breaks for them, and how you'd know if it stopped breaking. Everything else in this article builds toward writing that sentence well.
Why Leadership's Own Uncertainty Is Useful Signal
A vague mandate isn't leadership failing to do their job — it's often leadership accurately reporting that the organization doesn't yet know the problem's shape. Treat "we're not sure either" as useful data, not an obstacle. It tells you the mandate is genuinely open, which is exactly the condition where a well-run framing pass earns its keep — a role connected to moving from feature owner to strategic bet owner.
The Framing Sequence: Symptom → Problem Statement → Hypothesis → Smallest Testable Slice
The sequence has four stages, each with a distinct output artifact, and skipping a stage is the most common reason teams ship the wrong thing confidently. Each stage narrows scope without yet committing to a solution — narrowing is the whole discipline.
| Stage | Input | Output artifact | Governing question |
|---|---|---|---|
| 1. Symptom | Leadership's raw mandate | A list of observed signals, not causes | "What did someone actually notice?" |
| 2. Problem statement | Symptoms + data + interviews | One falsifiable sentence | "Who is affected, and what specifically breaks?" |
| 3. Hypothesis | Problem statement | An "if we X, then Y" claim with a metric | "What would make this statement true or false?" |
| 4. Smallest testable slice | Hypothesis | A scoped, time-boxed bet | "What's the cheapest way to learn if we're right?" |
Stage 1 — Collect the Symptom Without Diagnosing It
A symptom is what someone observed: "retention dipped for cohorts signed up after March," "support tickets about setup tripled," "enterprise deals stall at the security review." Write these down verbatim, resisting the urge to jump to why.
The discipline here is separating observation from interpretation. "Retention dropped" is an observation; "because onboarding is confusing" is already an unverified interpretation smuggled in as fact. Most premature framing failures trace back to skipping this separation — the team debates a cause nobody confirmed.
Stage 2 — Write a Falsifiable Problem Statement
A problem statement earns the name only if it can be wrong. "Users churn because retention is bad" is not falsifiable — it's circular. A workable version names a specific population, a specific breakdown, and a way to measure it: "Users who complete signup but never invite a teammate within 7 days churn at 3x the rate of those who do."
Use this template as a forcing function:
- Population — which segment, precisely (not "users," but "self-serve signups from paid channels")
- Behavior gap — what they do or don't do that correlates with the bad outcome
- Evidence — the data point or pattern that surfaced it, cited by source
- Boundary — what this statement explicitly does not claim, to stop scope creep
A good test: could a skeptical colleague read the statement and propose a way to disprove it? If not, it's still a symptom wearing a sentence's clothing.
Stage 3 — Form a Hypothesis With a Named Metric
The hypothesis stage converts the problem statement into an "if-then" claim: "If we surface a shared workspace during onboarding, then 7-day team-invite rate rises and 30-day retention for that cohort improves." Name the metric and the direction before you name the feature.
This is also where you should explicitly separate confidence from evidence quality — a hypothesis you're pursuing on thin data isn't wrong to pursue, but it changes how you stage the bet. That's the same discipline covered in making high-conviction bets on incomplete data: conviction and evidence are different axes, and conflating them is how teams either freeze waiting for certainty or overcommit on a guess.
Stage 4 — Find the Smallest Testable Slice
The smallest testable slice is the cheapest experiment that could falsify the hypothesis — not the full feature, not an MVP of the eventual product, but the minimum that produces a real signal. If the hypothesis is about team invites during onboarding, the slice might be a single prompt shown to 10% of new signups, not a redesigned onboarding flow.
Three questions size the slice correctly:
- Can this ship in days or low single-digit weeks, not a quarter?
- Does it produce a measurable signal on the named metric, not a proxy three steps removed?
- Is it reversible if the hypothesis is wrong?
If the answer to any of these is no, the slice is still too big — narrow it further before committing engineering time.
The Problem Framing Canvas
A canvas turns the four-stage sequence into something you can put in front of stakeholders instead of carrying in your head. It also functions as an artifact of record — proof, later, that a bet was framed deliberately rather than reverse-engineered from whatever got built.
| Canvas field | What goes here | Common failure mode if skipped |
|---|---|---|
| Mandate (verbatim) | Leadership's original words, unedited | Team "improves" the mandate silently and loses the paper trail |
| Symptoms observed | Bulleted raw signals, cited by source | Symptoms get conflated with causes |
| Problem statement | The falsifiable sentence from Stage 2 | Statement is unfalsifiable, so nothing can ever prove it wrong |
| Explicitly out of scope | What the statement does not claim | Scope creep re-absorbs the whole original vague mandate |
| Hypothesis + metric | "If X, then Y," with a named number | Metric is a vanity number disconnected from the hypothesis |
| Smallest testable slice | The minimum experiment and its timebox | Slice quietly grows into a full build before any signal returns |
| Kill criteria | The result that would make you stop | No kill criteria means the bet never dies, it just fades |
Use the canvas as a one-page artifact you review with your stakeholders before writing a line of a spec — a natural moment to also pressure-test whether people who disagree with the framing have actually been heard, which is part of leading peers you don't manage toward a shared bet rather than a mandate imposed on them.
Worked Example: Narrowing "Improve Retention" Into a Defined Bet
A vague retention mandate becomes bettable only by running it through all four stages in sequence, discarding plausible-sounding shortcuts at each step. Below is one realistic path from mandate to bet — not the only correct path, but a demonstration of the discipline.
The mandate, verbatim: "We need to improve retention this quarter."
- Symptoms collected: 90-day retention for signups since March is down 6 points versus the prior cohort; support tickets mentioning "how do I get my team in" rose sharply in the same window; a handful of churned-account exit surveys mention "never got the whole team using it."
- Problem statement: "Self-serve signups from paid acquisition who do not invite a second teammate within 7 days churn within 30 days at meaningfully higher rates than those who do, and the March cohort shows a disproportionate share of solo, never-invited accounts."
- Explicitly out of scope: enterprise accounts (different sales-assisted onboarding), retention for signups older than the March cohort, pricing-driven churn.
- Hypothesis: "If we prompt a workspace invite step directly inside the first-session setup flow, then 7-day team-invite rate for the affected segment rises, and 30-day retention for that segment improves."
- Smallest testable slice: a single invite prompt shown to a held-out sample of new self-serve signups for two weeks, measuring only invite rate and 14-day retention as a leading proxy — not a redesigned onboarding flow, not a new lifecycle email system.
- Kill criteria: if invite rate doesn't move within the test window, the "missing teammate" framing is likely wrong, and the team returns to symptom collection rather than iterating on prompt copy.
Notice what didn't happen: nobody built a referral system, a full onboarding redesign, or a new analytics dashboard in week one. The mandate went from unfalsifiable fog to a two-week test with a named metric and a defined death condition — the entire point of the sequence.
Capturing Ambiguity Before It Evaporates
Half of what makes ambiguous mandates hard isn't the framing logic — it's that the raw material (a hallway comment, a half-formed doubt in a stakeholder meeting, your own suspicion that the real problem is something nobody said out loud) gets lost before you ever sit down to frame it. Symptom collection depends on capturing the unfiltered version, not the version filtered through memory a week later.
Key Takeaways
- Fog is not a brief — an open-ended mandate like "improve retention" is a symptom, not a problem statement, and must be converted before any building starts.
- The framing sequence has four non-skippable stages: symptom, falsifiable problem statement, hypothesis with a named metric, smallest testable slice.
- A problem statement must be falsifiable — if a skeptical colleague can't propose a way to disprove it, it's still a symptom in a sentence's clothing.
- The smallest testable slice is not an MVP — it's the cheapest experiment that produces a real signal on the named metric, sized in days or low weeks, not a quarter.
- Kill criteria matter as much as success criteria — a bet without a defined death condition never actually dies, it just fades into permanent low-priority work.
- Capture symptoms the moment they surface, before memory sanitizes them into a tidier, less useful story.
Frequently Asked Questions
How do I push back when leadership won't give me a clearer mandate?
Don't ask them to clarify in the abstract — bring them a draft problem statement built from available symptoms and ask them to confirm or correct it. A concrete draft is easier to react to than an open question, and it shifts the conversation from "what do you want" to "is this the right framing."
What's the difference between a problem statement and a hypothesis?
A problem statement describes what's currently true and falsifiable about a symptom; a hypothesis proposes a causal fix and names the metric that would prove or disprove it. Skipping straight to a hypothesis without a problem statement usually means the team is testing a solution nobody confirmed matches the actual problem.
How small should the "smallest testable slice" really be?
Small enough to ship in days to low single-digit weeks, produce a real signal on the named metric, and be reversible if wrong. If a proposed slice fails any of those three checks, it's still sized like a project, not an experiment, and needs to shrink further.
Isn't this framing process itself a form of analysis paralysis?
Framing well is faster than building the wrong thing twice, but only if each stage has a time-box — symptom collection in days, not weeks, and a problem statement drafted, not endlessly workshopped. The discipline fails when framing becomes its own open-ended mandate instead of a bounded step toward a bet.
How does this connect to customer research methods like JTBD or journey mapping?
Symptom collection and problem-statement drafting are exactly where frameworks like Jobs to Be Done and customer journey mapping earn their keep — they give structured ways to surface the "why" behind a symptom instead of guessing at causation. Use them to strengthen Stage 1 and Stage 2, not to skip the falsifiability test in Stage 2.