Kill Ambiguous Requirements Before They Reach a Sprint

Most scope-creep I've seen doesn't start with engineers gold-plating. It starts one step earlier — a requirement that sounds clear in a planning doc but quietly means five different things to five people. By the time that ambiguity surfaces, it's a half-built feature and an awkward standup.

When I defined a 3-pillar roadmap tied to quarterly OKRs, the single highest-leverage habit wasn't the roadmap itself. It was killing ambiguous requirements before sprint start.

The test: can an engineer disagree with it?

A good requirement is falsifiable. If an engineer can't look at it and say "that's wrong, here's why," it isn't a requirement — it's a vibe.

"Improve onboarding" is a vibe. "Cut Step-3 drop-off from 40% to under 15% for new B2B accounts" is a requirement.

The second one is disagreeable. Someone can argue the number is too aggressive, or that Step 3 isn't the real problem. That argument is the point — it's cheaper to have it now than after two sprints.

Three questions I run on every line item

1. What outcome does this move? If I can't tie it to an OKR or a metric, it's a candidate for the "not now" pile.
2. What does "done" look like? Acceptance criteria that a QA engineer could test without asking me a question.
3. What are we not doing? Explicit non-goals kill more scope-creep than any prioritization framework.

Why this protects the team

Ambiguity is a tax that compounds. Every unclear requirement generates clarification threads, rework, and the quiet resentment of a team that shipped the wrong thing. Removing it up front is the least glamorous, highest-ROI thing a PM does.

The roadmap gave engineering priorities. Killing the ambiguous requirements gave them trust that the priorities were real.