Spec-driven development for product managers

A product manager writes a careful PRD for team invitations. It explains the problem, the user research, the success metric, and why invites should expire. An engineer pastes it into an AI coding agent and asks for an implementation.

The agent builds invitations that expire after 24 hours. The PRD said "should expire after a reasonable period." Nobody wrote down that enterprise admins can resend, that expired links should show a friendly page, or that guests don't count toward seats. The agent didn't ask. It made reasonable choices, and three of them were wrong.

Spec-driven development is the industry's answer to that gap. This guide explains it for product managers: what it is, which part of the spec is yours, how a spec differs from a PRD, and the problem the tools don't solve yet.

What is spec-driven development?

Spec-driven development is a way of building with AI coding agents where a written spec comes before any code. GitHub's Spec Kit describes it in one line: define what to build and why, then turn the specification into a plan, tasks, and working code.

The idea caught on fast. Spec Kit has more than 146,000 stars on GitHub as of 4 November 2026, and the Kiro editor is built around the same workflow. The common shape across tools is three documents:

Step	Spec Kit	Kiro	Who should own it
What and why	/speckit-specify produces spec.md	requirements.md: user stories with acceptance criteria	Product
How	/speckit-plan produces plan.md	design.md: architecture and approach	Engineering
Work breakdown	/speckit-tasks produces tasks.md	tasks.md: discrete, trackable tasks	Engineering, with the agent
Build	/speckit-implement, then /speckit-converge to check completion	Tasks run in dependency order	The agent

Spec Kit adds one more file before all of this: a constitution.md of project principles, written once per project. Kiro adds a separate bugfix spec for diagnosing bugs.

Which part of the spec is yours

The first row is product work. Spec Kit's own example makes the split visible. The specify step reads like a product brief: "Build a photo organizer with albums grouped by date." The plan step reads like an engineering decision: "Use Vite with vanilla JavaScript."

If a product manager doesn't write the what and why, someone else will, usually an engineer under time pressure, in one sentence typed into the agent. The agent then fills every gap with a guess. The guesses are plausible, which is what makes them expensive. They pass review because nobody is checking them against an intent that was never written down.

Owning the first row doesn't mean learning the tools. It means producing a requirements section precise enough that an agent can't misread it.

How a spec differs from a PRD

A PRD and a spec are written for different readers. A PRD persuades and aligns humans. A spec is read literally by an agent that will act on every word and invent every missing one.

	PRD	Spec for an agent
Reader	Stakeholders, designers, engineers	An AI coding agent, then a reviewer
Job	Explain why this matters and agree on scope	Remove ambiguity before code exists
Tone	Narrative, with context and research	Short, testable statements
"Reasonable period"	Fine	A bug waiting to happen
Edge cases	Often implied	Every one named
Non-goals	Sometimes listed	Always listed, or the agent may build them

You don't have to choose. Keep the PRD for the why. Extract the spec from it for the agent. The extraction step is where the unasked questions surface, and that is half its value.

What a PM's spec should contain

A requirements section an agent can follow has five parts. Using the invitations example:

The user and the problem, in two sentences. "Workspace admins need to invite teammates by email. Today they share a password, which breaks our audit log."

Rules, numbered and testable.

R1  An invite link expires 7 days after it is sent.
R2  An admin can resend an expired invite; resending creates a new link.
R3  Opening an expired link shows a page with a "request a new invite" button.
R4  Invited guests do not count toward paid seats.
R5  An invite to an email that already has an account adds them directly.

Acceptance criteria per rule. How you will check it in a demo. Kiro's requirements format builds this in by pairing each user story with acceptance criteria.

Non-goals. "Bulk CSV invites are out of scope." "No change to SSO users." An agent treats silence as permission.

Open questions, marked as open. "Should invites to personal email domains be blocked? Not decided." This stops the agent from deciding it for you.

Leave out anything about implementation: tables, endpoints, libraries. That is the plan step, and engineers will make better calls there than a PRD can.

The problem with spec-driven development

The workflow has real critics, and a product manager should know the criticisms before adopting it. Birgitta Böckeler's analysis of Kiro, Spec Kit, and Tessl on martinfowler.com raises three that matter for product teams:

• Review load. The tools generate a lot of markdown, and she found Spec Kit's output repetitive and tedious to review. A spec nobody reads closely is not a spec.
• Agents still drift. Even with detailed specs, agents ignored instructions or over-interpreted them. A spec improves the odds. It does not guarantee the result.
• Specs are often discarded. She separates three levels: spec-first, where the spec guides the first build and is then thrown away; spec-anchored, where it is kept and evolved with the code; and spec-as-source, where people edit only the spec.

Most teams are at the first level without meaning to be. The spec is excellent on the day of the first build. Then a customer call changes R1 to 14 days, an engineer adds an exception for enterprise accounts in a pull request, and a Slack thread decides that personal email domains are blocked after all. None of that reaches spec.md. The next time an agent works on invitations, it reads a spec that describes a product that no longer exists.

That is spec drift, and it is a product problem more than an engineering one. Engineering can regenerate code. Only product knows which version of the rule is the current one.

How to keep a spec true after the first build

Treat requirements as decisions with owners, not as paragraphs in a file:

1. Give each rule an owner. Usually the PM for product rules, the tech lead for technical constraints.
2. Record changes as new versions, not edits. "R1 changed from 7 to 14 days on 12 November, approved by the PM, because enterprise customers asked." The old rule stays visible as replaced.
3. Route decisions made elsewhere back to the spec. A rule changed in a Slack thread or a PR comment is still a spec change.
4. Demo against the numbered rules, not the tickets. Read each rule aloud and show it. Misses surface before launch instead of after. More on this in how to know engineering built what the PRD said.
5. Make the next agent session start from the current version. If the agent reads an old file, every step above was wasted.

Steps one to four are process. Step five needs tooling, because it has to happen at the start of every session for every engineer.

Where Lockstep fits

Lockstep handles the parts of spec-driven development that happen after the spec is written. A product manager can start without a repo or a developer: paste a brief, review the requirements Lockstep extracts with their source passages, and approve the ones that are right. Open questions stay marked as open. The approved set becomes an implementation brief you can copy and hand to engineering.

When the brief changes, earlier versions stay available and changed requirements go back to review before the brief is regenerated. Once a developer connects their repo, their Claude Code sessions are briefed on the approved requirements that apply, and an opt-in check can flag code changes that may conflict with one. The check is advisory: it surfaces a possible conflict, and people decide.

It does not replace Spec Kit or Kiro, and it does not write the plan or the code. Session briefings work with Claude Code today. Pasted briefs are maintained in Lockstep, not synced from an external document. See Lockstep for product teams.

Sources checked 4 November 2026

• https://github.com/github/spec-kit
• https://kiro.dev/docs/specs/
• https://martinfowler.com/articles/exploring-gen-ai/sdd-3-tools.html
• https://github.com/lockstep-team-agent/lockstep

Related reading

For checking a build against requirements, see how do I know engineering built what the PRD said?. For the term itself, see spec drift. For keeping both sides in sync during the build, see how to keep product and engineering aligned.