Why Ambiguity Is the PM's Job
If you've ever been in a meeting where someone says "we need to improve the user experience" and the room nods along — you've encountered unstructured ambiguity. Everyone agrees something needs to happen. No one agrees on what, why, or how to know if it worked.
Here's the thing: ambiguity is the PM's primary raw material. Engineers work with code. Designers work with interfaces. PMs work with ambiguity. Our job is to take messy, contradictory, incomplete information and turn it into a clear plan that a team can execute.
But most PMs don't have a repeatable system for this. They rely on experience, pattern matching, and (secretly) hoping someone else in the room will add structure. Across my internships so far and my own side projects — from lead-qualification work at Omniful to analytics tools I built myself — I've developed a 4-step framework I keep coming back to.
The 4-Step Framework
The framework is intentionally simple. Complex frameworks don't get used. This one does.
- Scope: define boundaries.
- Decompose: break into parts.
- Prioritize: sequence by impact.
- Execute: iterate and measure.
Then loop: what you learn in step 4 feeds back into step 1, so you refine the scope and go round again.
Step 1: Scope — Define the Boundaries
Every ambiguous problem is infinite until you draw a box around it. Scoping isn't about finding the answer — it's about defining which answers you're looking for.
Ask three questions:
- What are we NOT solving? This is more useful than "what are we solving" because it eliminates the infinite space of possible directions.
- Who is the decision for? "Improve user experience" for power users is a completely different problem than for new signups.
- What does success look like in 90 days? If you can't describe a measurable outcome, the problem isn't scoped yet.
Take an illustrative brief (not a project I ran): "improve warehouse operations." After scoping, it might become: "Reduce pick-to-ship time by 20% for warehouses processing 500+ orders/day within Q2." The numbers are invented, but the shape is the point. That's a problem a team can solve.
Step 2: Decompose — Break It Into Parts
Once scoped, break the problem into independent sub-problems. I use a MECE-ish approach (Mutually Exclusive, Collectively Exhaustive — but I don't stress about perfection).
For the warehouse example:
- Discovery: What's causing the current pick-to-ship delays?
- Design: What workflows can reduce movement/search time?
- Technical: Can we optimize the routing algorithm?
- Operational: Are there process changes (no code needed) that would help?
The key insight: each sub-problem can be worked on independently. Discovery can happen in parallel with technical research. You don't need to solve them sequentially.
Step 3: Prioritize — Sequence by Impact
Not all sub-problems are equal. Prioritize on two axes:
- Impact: How much does solving this move the needle on the 90-day goal?
- Confidence: How certain are we about the solution approach?
High-impact, high-confidence items go first — they're quick wins that build momentum. High-impact, low-confidence items need experiments before commitment. Low-impact items get deprioritized regardless of confidence.
The prioritization trap: Most teams prioritize by effort, not impact. They solve the easy things first and never get to the hard, important ones. Prioritize by the value of the answer, not the ease of finding it.
Step 4: Execute — Iterate and Measure
Execution isn't "go build it." It's a cycle:
- Pick the top-priority sub-problem
- Define a hypothesis: "If we [action], then [metric] will [change] by [amount]"
- Build the minimum thing needed to test the hypothesis
- Measure the result
- Update your understanding and re-prioritize
This is where most frameworks stop, but the loop back to Step 1 (in the list above) is critical. Every execution cycle teaches you something that may change how you scoped the problem. The framework is a loop, not a line.
Worked Example (Hypothetical): Empty Slots at a Clinic-Booking App
Illustrative scenario; numbers invented to show the method. This is not a product I worked on.
Imagine a clinic-booking team that brings you "too many appointments go unused":
Scope: Narrow it to "cut no-shows on first appointments from 18% to below 12% by end of Q3." Explicitly exclude walk-in clinics (different booking dynamics) and repeat patients (different problem).
Decompose: Three sub-problems might emerge: (1) patients who book and forget, (2) patients who meant to cancel but found cancelling hard, (3) patients who booked a slot days away and solved the problem elsewhere. Each has different root causes.
Prioritize: Say category 1 is the biggest group (about half of no-shows in this made-up data) with the cheapest fix. Category 2 is a UX issue (a separate initiative). Category 3 is a supply issue (outside scope).
Execute: A hypothesis could be that forgetful patients would turn up if a reminder asked them to confirm. Build a confirm-or-release reminder 24 hours ahead, and state the success bar before shipping, for example "no-shows in that group down by a third within six weeks." Then measure against it.
Common Pitfalls
Using it since, here are the mistakes I see (and sometimes still make):
- Scope too broad: "Improve retention" is not a scoped problem. Neither is "reduce no-shows." Get specific about who, what, by how much, by when.
- Decompose into tasks, not sub-problems: "Build a notification system" is a task. "Understand why users forget to return" is a sub-problem. Decompose into problems, not solutions.
- Prioritize by consensus: The loudest stakeholder's pet project isn't necessarily the highest-impact item. Use data (even rough data) over opinions.
- Execute without measuring: If you don't define what success looks like before you build, you can't tell if you succeeded after. Define the metric and threshold before writing a line of code.
- Skip the feedback loop: The framework is a cycle. After executing, go back and re-scope. The problem has changed — your understanding of it should too.
Making It Yours
Frameworks are tools, not religions. Take what works from this and adapt it. The core principle is simple: structure your approach to ambiguity before diving into solutions.
Good PMs tend to have some version of this — a repeatable process for taking messy inputs and producing clear outputs. It doesn't have to be this exact framework. But it should be something. Intuition is real, but it's not scalable. A framework is.
And if you're in an interview and someone asks "how would you approach [ambiguous problem]?" — this framework is your answer. Walk them through it with a real example, and you'll stand out from candidates who jump straight to solutions.
For the framework applied to a design review, see From ‘It Looks Off’ to a Ranked Tracker. For the same scoping instinct applied to data, see Data-Driven Doesn't Mean Dashboard-Driven.
