Clear-Goal Ambiguity Cut
Because general LLMs can do anything, a sharp key-user + problem + use-case triad is what rules approaches out
- Difficulty
- Easy
- Time to result
- ~days to results
- Steps
- 4
- Confidence
- 90%
General-purpose models create enormous ambiguity about who you're building for and what problem you're solving — the model could plausibly do almost anything. Cat's antidote is to force a concrete triad: name the key user, the specific problem, and the target use case. A well-set goal is valuable precisely because it eliminates most possible approaches, letting the whole team make decisions without being blocked on the PM.
Origin
Cat Wu's product-definition practice on Claude Code at Anthropic, framed as a response to LLM generality.
Core principles
- 01LLM generality is a source of ambiguity, not just power
- 02A good goal is defined by what it rules OUT, not just what it enables
- 03Specificity in user + problem + use case unblocks autonomous team decisions
- 04Team principles (who our key users are and why) should be written down so anyone can decide without the PM
How to run it
- 1
Name the key user
State precisely who the feature is for — e.g. 'professional developers at enterprises' — not a vague 'our users.' The narrower the user, the fewer valid approaches remain.
- 2
State the specific problem
Identify the concrete pain, e.g. too many permission prompts causing fatigue. Anchor on an observable user friction, not an abstract opportunity.
- 3
Define the target use case as a measurable end-state
Frame the win concretely, e.g. 'professional developers at enterprises safely get to zero permission prompts.' This clarity mechanically rules out approaches that don't serve it.
Pro tip Write the goal so it eliminates options — if it doesn't kill any candidate approaches, it isn't specific enough.
- 4
Publish team principles so decisions decentralize
Codify key users, why they're the key users, and what you're willing to trade off, so team members make aligned calls themselves rather than escalating to the PM or other stakeholders.
In the wild
For a permission-fatigue feature, Cat set the goal as: key user = professional developers, problem = too many permission prompts causing fatigue, use case = safely reaching zero permission prompts. This immediately ruled out a large set of possible approaches to reducing prompts.
→ A sharp goal that constrained the solution space and let the team execute without re-litigating direction.
Common mistakes
Leaving the target user generic
With a general model, 'build for our users' permits nearly any feature. Without a named user and use case, the team burns cycles on undifferentiated options.
Setting goals that don't exclude anything
A goal that every candidate approach satisfies gives no decision leverage. The test of a good goal is how many approaches it eliminates.
Is it for you?
Best for
AI PMs defining features on general-purpose LLM products where the solution space feels unbounded
Not ideal for
Narrow single-purpose tools where the user and use case are already obvious
From the transcript
“Because LLMs are so general, that actually creates a lot of ambiguity in who we're building for, what problems we're trying to solve, what the…”
“And that actually sets a pretty clear goal because it it rules out a lot of potential approaches for reducing permission prompts”
“it lets people make decisions by themselves without feeling like they're blocked on PM or any other stakeholder.”
From the episode
How Anthropic’s product team moves faster than anyone else
Cat Wu (Head of Product, Claude Code)