Spec-Driven Development for Product Managers: The Complete Guide
Spec-Driven Development for Product Managers: The Complete Guide
Vibe coding gave builders a superpower: ship anything in hours. It also gave them a new failure mode: ship the wrong thing at 10x speed.
AI coding tools don't second-guess you. Feed Cursor a vague feature request and it will build something — confidently, quickly, and potentially completely wrong. The ambiguity you typed becomes the architecture that gets shipped. By the time you notice the misalignment, it's baked into your data model, your user flows, and three sprints of downstream decisions.
Spec-driven development (SDD) is the formal response to this problem. The idea: separate the "what and why" phase from the "how and build" phase, so AI agents execute against structured intent instead of improvising from incomplete prompts.
Here's the catch: every SDD guide you've read was written for engineers. Amazon Kiro lives in your IDE. GitHub Spec-Kit is a Python CLI with 84.7k stars. These are the tools developers use after the spec arrives. None of them are where the spec gets written.
That's the PM's problem — and the PM's opportunity. This guide is for the product seat.
What Is Spec-Driven Development? (The Non-Developer Definition)
Spec-driven development is a discipline, not a tool. At its core, it enforces one rule: the planning phase must complete before the implementation phase begins.
That sounds obvious. It isn't. When AI coding tools entered the workflow, the planning phase didn't go away — it collapsed into the first chat prompt. Requirements discovery, scoping, constraint definition, and success criteria all started happening in real time, inside a conversation with something that would execute on every ambiguity with complete confidence.
SDD pushes back. It says: before you touch a coding tool, you need a structured artifact — a spec — that defines what you're building, why, what success looks like, and what's explicitly out of scope. Once that spec exists, the AI coding session executes against it, not against the conversation.
Thoughtworks Technology Radar Vol. 33 placed SDD in the "Assess" ring in December 2025 — the signal that a practice is real enough to track, even if it's still maturing. The formal definition from Liu Shangqi, Thoughtworks Tech Director APAC: SDD is "a development paradigm that uses well-crafted software requirement specifications as prompts, aided by AI coding agents, to generate executable code."
The key distinction from a traditional PRD: SDD specs are executable, not just readable. They're not documentation that humans interpret and implement. They're structured input that AI agents validate against. Augment Code's definition captures this: SDD "treats specifications as executable build artifacts from which code is derived and validated, preventing architectural drift in AI-generated code through automated enforcement rather than passive documentation."
For PMs, the implication is direct. Sean Grove, speaking at AI Engineer World's Fair 2025, put the stakes plainly: "Only 10-20% of your value is the code you push. The other 80-90% is the structured conversation that decides what to build."
PMs have always owned that 80-90%. SDD makes it machine-readable.
Why Vibe Coding Without a Spec Creates Architectural Debt
The failure mode isn't code quality. It's intent drift.
When a PM hands a vague brief to a developer, the developer asks clarifying questions. They push back. They flag the parts that don't make sense. When a PM (or an engineer following a PM's brief) hands that same vague brief to Cursor, Claude Code, or v0 — the AI builds it. Confidently. All the way through.
The first prompt becomes the spec. And first prompts are always underspecified.
A 2026 study examining Cursor AI adoption across 807 GitHub repositories captured this precisely: vibe-coded sessions created "transient velocity increases with persistent code complexity growth." In plain language: the code ships fast, and then becomes progressively harder to maintain. The speed is real. So is the compounding architectural debt it leaves behind.
The debt isn't just technical. It's product-level.
Wrong data model: the AI interpreted "users" as individual accounts when you meant teams. Now your permission model is upside down. Wrong user flow: the AI built the happy path without edge cases, because edge cases weren't in the prompt. Wrong assumptions baked in at the foundation: the feature works, but not for the actual use case — because "the actual use case" lived in your head, not in the spec.
This is where PMs are specifically implicated. The code is downstream of intent. If the intent wasn't structured before the session started, no amount of engineering discipline downstream can fully correct it. As one PM guide put it: "Code is a compressed snapshot of intent — fast for machines, but lossy for everyone else." The lossy translation happens at the moment you hand off an unstructured brief.
The good news: this failure mode is entirely preventable. The spec is the prevention.
The PM Spec Workflow: From Problem to Stack-Ranked Spec
Every SDD article describes what a spec should contain. None of them show PMs how to build one from the work they already do. That's the gap this section closes.
A PM spec for SDD has five components. You probably write four of them already.
Step 1: Problem Statement + KPI
Not "we should add X." That's a solution. Start with the problem.
"Users are manually exporting data to spreadsheets every week because there's no automated report in the product. This is costing us X hours of user time and showing up as a top-3 reason in churn interviews."
The problem statement defines the "why" that the spec will address. The KPI defines what success looks like in measurable terms — not "users are happier" but "weekly exports drop by 80% within 30 days of launch."
Step 2: User Story
Restate the problem as a user need in falsifiable form.
"As a growth PM at a SaaS company, I need automated weekly reports delivered to my inbox so that I don't have to manually pull data every Monday morning."
User stories are PM-native. In an SDD context, they also become the functional requirement that anchors the spec — the "what" and "who" that the AI agent is building toward.
Step 3: Acceptance Criteria
This is the definition of done, stated as conditions the AI can validate against.
"Given a user with a connected data source, when Monday 9 AM arrives, then an email report is delivered to the user's primary email address containing the last 7 days of activity data."
Given/When/Then structure is the standard. Thoughtworks recommends it specifically because it converts human intent into machine-testable conditions. The acceptance criteria is what separates a SDD spec from a PRD — it's not description, it's verification.
Step 4: Out-of-Scope Declaration
This is the most underrated component of a PM spec, and the one most consistently skipped.
Every feature you fail to explicitly exclude becomes a feature the AI might build anyway. Scope creep at the AI layer is faster and more expensive than scope creep at the human layer, because AI agents don't flag ambiguity — they resolve it, unilaterally, and ship code.
"Out of scope: custom report templates, Slack delivery, CSV export, real-time data (reports use 24-hour-delayed data only)."
Clear exclusions bound the AI agent's decision space. They're not pessimistic — they're the most valuable constraint you can write.
Step 5: Stack Rank It
Here's what every SDD framework misses entirely: priority.
SDD articles treat specs as flat lists of requirements. They don't answer the question that matters most for PMs: which spec should I write first?
If vibe coding's failure mode is building the wrong thing fast, then the spec that matters most is the one for the highest-priority problem. Writing a perfect spec for a low-priority feature is still a waste. If you're speccing everything, you're speccing nothing.
Before you hand a spec to engineering or an AI agent, it needs a position in the priority queue. Stack ranking isn't just about order — it's about commitment. The spec you rank first is the one that gets your attention, your out-of-scope rigor, and your acceptance criteria precision. Lower-ranked items can stay rough until their turn arrives.
How this maps to the engineering workflow:
GitHub Spec-Kit uses a three-step slash command workflow: /specify → /plan → /tasks → implement. PMs own the /specify command — that's the problem statement, user story, acceptance criteria, and out-of-scope. Engineers own /plan and /tasks. The handoff is clean because the spec is structured. This is what SDD looks like when it works: the PM's artifacts are the input, not a conversation to be decoded.
How Structured PM Specs Make AI Coding Tools Dramatically Better
What Cursor, Claude Code, v0, and similar tools need to do their best work: bounded scope, known constraints, and a definition of done. What they get without a spec: a chat window that doubles as a requirements discovery session, with something that will confidently resolve every ambiguity in real time.
The research on this is blunt. Augment Code, citing Yan et al. (2025), found that LLMs generate vulnerable code at rates between 9.8% and 42.1% across benchmarks when given unstructured prompts. Thoughtworks: "Clear specifications significantly reduce model hallucinations and produce more robust code."
Consider the difference between these two AI session starts:
Unstructured:
"Build a weekly email report feature for our SaaS app."
The AI will make dozens of decisions you didn't make: which data to include, when to send, what the email looks like, how to handle users with no data, whether to build a settings UI, what timezone to use. Each decision is a guess that compounds into architecture.
Structured (from a SDD spec):
"Build a weekly email report. Goal: reduce manual data exports. User: growth PMs. Success: report delivered Monday 9 AM with 7-day activity summary. Out of scope: custom templates, Slack delivery, real-time data. Acceptance criteria: Given a connected user, when Monday 9 AM arrives, then email is delivered to primary address."
The AI's decision space collapses to the actual feature. It's not smarter — it's better constrained. The spec is doing the thinking that would otherwise happen inside the session, in real time, with consequences.
The compounding effect matters too. When the spec lives in a platform rather than a chat history, it becomes the AI's persistent context. Every subsequent session starts from the current version of intent, not from memory of what was discussed three weeks ago. A session without spec context is a one-time conversation. A session with a living spec is an ongoing product relationship — the AI always knows what you're building and why.
StackRanked as the PM-Native Spec-First Platform
GitHub Spec-Kit is a developer CLI. Amazon Kiro is an IDE extension. Augment Code Intent is an enterprise engineering platform. BMAD Method is community-built AI agent orchestration.
All four assume the spec arrives from somewhere upstream. None of them are where the spec gets written.
That gap is the PM's problem. The entire SDD ecosystem is built downstream of the decisions PMs make — but there's no PM-native home for the spec itself. It gets written in Notion, emailed around, debated in Slack, and finally copy-pasted into a developer tool that transforms it into tasks. Every handoff is a lossy translation.
StackRanked is that upstream. It's the PM-native platform built around the spec-first workflow: where the spec is created, versioned, prioritized, and kept alive across the product lifecycle.
Three capabilities make it SDD-native in a way no other tool addresses:
1. Stack-ranked prioritization. StackRanked doesn't just store specs — it forces the question every SDD framework skips: which one matters most? The platform's core mechanic is priority ordering: every spec competes for position based on impact, effort, and strategic fit. You can't accidentally spec a low-priority problem into a first-sprint build.
2. Roadmap versioning. Products change. Requirements evolve. The spec you wrote in Q1 may be obsolete by Q2 — and if it's a Markdown file in a repo, no one knows it changed. StackRanked keeps every version of every spec, so the audit trail of decisions is always available. You know not just what you're building, but why the spec looks the way it does today compared to six weeks ago.
3. AI context memory. When you start a new AI coding session, the relevant spec is available as structured context — not reconstructed from memory, not summarized from a doc, but the current version of intent. The AI always has access to the decisions that matter. Specs don't go stale between sessions.
The entry point is also different from every other SDD tool. Kiro and Spec-Kit require an engineering team decision to adopt — new workflows, new tooling, new overhead. StackRanked's token-based pay-as-you-go model removes the commitment barrier. Try spec-first thinking on one feature. If it improves the quality of your next AI coding session, you'll know immediately.
The Waterfall Objection — And Why It Doesn't Apply to PMs
In November 2025, François Zaninotto of Marmelab published the most prominent critique of spec-driven development: "Spec-Driven Development revives the old idea of heavy documentation before coding — an echo of the Waterfall era."
He's not wrong about developer-facing SDD. Some implementations generate thousands of lines of Markdown before a single line of code runs. That is a documentation overhead problem. His frustration is real and legitimate for that context.
But here's the thing: that critique applies to code-first SDD. It doesn't apply to PMs.
PMs don't write 1,300-line specs. They write user stories. They write acceptance criteria. They define scope and out-of-scope. They stack-rank features against each other. Every component of a SDD spec is something a PM was already producing — the only change is the format: machine-readable instead of human-only.
Thoughtworks responded directly to the waterfall objection: "SDD is not creating huge feedback loops like waterfall — it's providing a mechanism for shorter and more effective ones than would otherwise be possible with pure vibe coding." The spec isn't the bottleneck; the spec is the thing that makes the coding session shorter, more precise, and less likely to require a rebuild.
For PMs, SDD isn't new ceremony. It's existing backlog discipline with an upgraded output format. The spec-then-build loop is exactly how agile is supposed to work: problem → user story → acceptance criteria → priority → build. SDD doesn't add steps to that process. It makes each step machine-readable, so the AI agent downstream actually has something to execute against.
The waterfall critique lands on engineers writing specs they didn't want to write. It doesn't land on PMs writing specs they were already writing. The difference is who's doing the work and why.
Write the Spec Before You Open the Chat Window
Structured intent is the scarcest resource in AI-native product development. AI coding tools have made execution nearly free. What they can't manufacture is clarity about what to build and why.
That clarity lives in the spec. The spec lives with you, the PM — before it hits a developer, before it hits a coding agent, before it becomes architecture that's expensive to undo.
Every SDD tool on the market assumes the spec already exists when it shows up. GitHub Spec-Kit needs it. Kiro needs it. Cursor needs it. They're all downstream of the decision you make when you write down, precisely, what problem you're solving and what done looks like.
StackRanked is where that decision gets made, written, versioned, prioritized, and kept alive.
Start building spec-first at stackranked.ai — free to start, no commitment required.
Sources: Thoughtworks Technology Radar Vol. 33 (Dec 2025); Augment Code "What Is Spec-Driven Development?" (Feb 2026); Microsoft Developer / GitHub Spec-Kit blog (Sep 2025); Marmelab, François Zaninotto (Nov 2025); arXiv "Spec-Driven Development: From Code to Contract in the Age of AI" (Feb 2026); MSR '26 Cursor study, 807 GitHub repositories (Nov 2025); Sean Grove, OpenAI, AI Engineer World's Fair 2025; TADSummit interview with Jason Goecke (Nov 2025); S.M. Talha Wadood, LinkedIn PM Guide (Oct 2025).