Your Specs Are the Bottleneck — A 340-Person Survey Quantifies the PM Failure Mode
A new survey of 340 engineering professionals across companies from 10-person startups to 1,000+ engineer organizations just produced the most uncomfortable mirror a PM could look into. The headline: only 27% of engineers say both the problem and success criteria are clear when they read a ticket. 60% need clarifying questions before they can start work. And the #1 cause of delays? Ambiguous acceptance criteria (50%) followed by late-discovered edge cases (40%).
Your requirements quality — not engineering capacity — is the dominant bottleneck in your team's output.
The asymmetry in what's unclear is revealing. 35% understand the problem but not the definition of done — nearly three times the 13% who have the inverse issue. PMs are decent at communicating the 'what' and 'why.' Where we're failing is the measurable definition of done. If your last PRD said 'the feature should feel fast' instead of 'P95 latency under 200ms,' you've identified your highest-leverage fix.
The AI Requirements Gap: A 10x Opportunity Hiding in Plain Sight
Here's the strategically fascinating part: 95% of teams use AI, 80% substantially — but only 9% use it for requirements generation. Teams are accelerating the part of the process that was never the bottleneck (writing code) while leaving the actual bottleneck (spec quality) completely manual. Steve Yegge, from Anthropic's orbit, reinforces this from a different angle: Anthropic practices 'slot machine programming' — building 20 implementations and shipping the best one. Claude Cowork went from prototype to launch in 10 days. When your competitor can generate 20 complete solutions in the time it takes you to align on a spec, your process is the constraint.
The Knowledge Graph Problem Compounds This
64% of teams store critical knowledge in people's heads, 57% have it scattered across Notion/Confluence/Google Docs, and only 3% intentionally organize documentation for AI tool consumption. Meanwhile, 52% of teams have zero shared AI context — each developer feeds different product assumptions into their AI tools. Large companies (500–1,000 engineers) are significantly worse at 75% individual context management vs. 51% for startups. You're sitting on the most valuable AI context your team doesn't have: user research, success metrics, strategic rationale. A shared product context document referenced in your team's CLAUDE.md or AGENTS.md isn't busywork — it's the highest-leverage way to multiply your product knowledge across every AI-assisted line of code.
The Existential PM Signal You Can't Ignore
59% of engineers say they handle more of the product process than a year ago, with tech leads at 72% scope expansion. AI enables engineers to work outside their specialty (74%). The 'product engineer' archetype is accelerating. PMs who define their role as 'writing Jira tickets' are being routed around. The value that persists: customer research synthesis, cross-functional alignment, strategic prioritization — and writing acceptance criteria clear enough that both humans and AI agents can execute against them.
What to do
Audit your last 10 tickets this week: count how many have measurable acceptance criteria vs. vague language like 'should work well.' Target 100% quantified success criteria within 2 sprints.
Start using Claude or GPT-4 to stress-test every PRD before sharing this sprint. Prompt: 'What edge cases, missing acceptance criteria, or ambiguous requirements exist in this spec?'
Create a shared product context document — vision, personas, metrics, constraints, decision history — and ensure it's referenced in your team's CLAUDE.md or AGENTS.md by end of sprint.
Institute a 30-minute 'pre-sprint discovery' session where PM + 1–2 engineers walk through upcoming tickets to surface dependencies and edge cases before work begins.