Spec-driven development for product managers

Published 23 October 2026

In spec-driven development, a product manager or product owner usually does not write the spec the AI coding agent builds from — the agent drafts it, with a developer. The product manager owns what comes before and after: the intent the spec is drafted from, the review that decides whether the spec says the right thing, the decision when it has to change, and the acceptance of what was built against it. The documents get shorter and arrive earlier; the decisions have to be written down, because the agent cannot ask the hallway. Below is who does what, how a PRD, a user story and a spec differ now, a ten-minute review of an agent-written spec, what to do when the spec lives in git, how to approve a change, and what goes wrong.

When specs live in code repositories, product managers and business analysts (the very people who should be defining the “What”) face barriers to participation.

— Hari Krishnan, InfoQ, February 2026

Who does what in spec-driven development

Anthropic’s course on an AI-native development process describes the same split. An intent.md comes first: “the product owner reviews and corrects the agent-written intent.md before it is committed.” Then the agent turns it into a requirements and design spec: “The product owner reviews that spec, but doesn’t write it.” And at the end: “The product owner signs off on the spec, and routes flagged concerns to the named policy owners” (Claude Academy).

The product manager’s work moves earlier and gets more concentrated: fewer documents written by hand, more reading, and more decisions that used to be made in passing.

PRD, user story or spec?

They overlap, but each does a different job now.

The PRD is shrinking rather than disappearing. One commenter’s advice for fast-moving teams: “keep just 3 sections: (1) problem/why now, (2) definition of done + acceptance criteria, and (3) a short decision log” (r/ProductManagement, 2026). Another describes the handover: “As a PM, I’m writing the PRD with AI and my engineer and UX counterparts. When we agree it’s done, it’s locked in, we create individual tickets (we use jira) and then the engineers use AI to implement the work” (r/ProductManagement, 2026).

A user story alone is too thin for an agent. One commenter’s view of most companies: “Practically every company already uses ‘spec-driven development’, just with incredibly vague specs in the form of poorly written Jira tickets” (Hacker News, 2025). The useful way to think about what the product manager hands over: “A product brief works well when it is defined as the set of inputs the spec is not allowed to invent” (r/ProductManagement, 2026).

How to review an agent-written spec in ten minutes

The spec will read well — agents write fluent, confident prose. What a review has to catch is a wrong value, a missing case, or a requirement nobody asked for. Ten questions:

1. Does the why match your intent, in your words, not a paraphrase that drifted?
2. Is every number right? Days, amounts, limits, roles. An agent can turn “seven days” into three in a perfectly formed sentence.
3. Does every requirement have cases with real values, and could you tell from them whether the result is right?
4. Are the edge cases you know about there? The partly paid invoice, the customer with two accounts, the first day of the month.
5. Is there anything you did not ask for? Every requirement should trace back to the intent.
6. Does “out of scope” match what you agreed with the client or the business?
7. Is “must not change” complete? What already works and must keep working.
8. Are the open questions marked, each with who answers it — and are the ones for you answered?
9. Is it short enough that the people who have to agree will read it?
10. Who else has to agree, and have they?

If the spec fails three of these, send it back rather than fixing it line by line. The longer list is in the requirements review checklist; why the developer’s own review is not enough is in who reviews the spec.

When the spec lives in git

Most spec-driven tools keep specs as markdown files in the code repository, reviewed in pull requests. That works for developers and shuts out almost everyone else — the problem in the InfoQ quote above. Hari Krishnan lists the questions it leaves open for teams: “When does each stakeholder’s contribution begin and end? How do they know when to review? Who approves what?”

There are three workable answers:

• The product manager works in the repository through an assistant. Anthropic’s course: “contributors without Git experience don’t need to use Git directly”, because a connector lets the assistant commit the files for them.
• The tracker stays the record. “Jira, ServiceNow, or the requirements tool holds the authoritative record, and the Markdown artifacts are working copies” (Claude Academy).
• Either way, one place is named. “For each artifact the process produces, one system should be named the source of truth and the others hold a copy or a link.” Two places that both claim to be current are how specs drift.

How requirements work in Jira, in Confluence and in git, and where each loses track.

Approving a change to the spec

The build always finds something. When it does, the agent should stop and the spec should change — and someone has to decide. For a change inside the agreed scope, that is the product manager or the owner of the rule; for a change to what the client agreed, it is a change request. Anthropic’s course draws the line by risk: “Routine changes are approved by the engineer, and anything the organization classes as higher risk goes to a tech lead or architect.”

Write each decision down with its reason — a line in the decision log is enough. One small study shows why it matters even when nothing goes wrong: reviewers who checked code against an approved spec found no more problems than those who read the code alone, but 81% of their findings could be tied to a named requirement, against none without the spec (Nitin Garg, InfoQ, 2026). A problem tied to an agreed requirement has an owner; a problem without one is an argument. A full example of a change to a spec, from request to version 2, is in the spec-driven development example.

Accepting the result

The spec’s cases are the acceptance tests. The agent runs them; the product manager checks that the cases still describe what the business needs, and tries the ones that matter by hand. It is still the slow part. One commenter whose team uses Kiro to draft epics: “What we haven’t solved yet is how it can help us with epic acceptance. Still highly manual and testing/acceptance is a bottleneck” (r/ProductManagement, 2026). For a client or a release, the formal version is the UAT sign-off.

What goes wrong

• Specs nobody on the business side understands. One commenter describes “a guy in marketing that has taken it upon himself to use Claude to draft these wildly complicated and dense implementation specs that he doesn’t understand” (Hacker News, 2026). A spec the author cannot defend line by line is not a spec, whoever generated it.
• Documents passed from model to model. “we’re running full steam ahead to spec-driven development, and it’s devolved into everyone generating a doc that just gets passed to another LLM with whatever upstream assumptions and implicit debt passed along without a thought” (r/ProductManagement, 2026).
• Decisions that live only in someone’s head. “the robot was literally changing things back and forth because we didn’t have it properly documented,” wrote one commenter about one of their mostly AI-driven teams (r/ProductManagement, 2026).
• The job turns into feeding the machine. A product manager of 20 years: “Need to write conception using Claude and OpenSpec and it just isn’t fun anymore. I feel like a secretary to the machine god” (r/ProductManagement, 2026). The product manager’s value is in the decisions, not in the volume of documents.

What the research says

The largest study of spec-driven development in practice found that the benefits for collaboration appeared only where specs passed between developers and people in other roles. There, a product owner told one participant, “Now I see what my developers are doing”, and another team reported “A lot of communication has been offloaded to the spec itself”. In developer-only teams the benefit was modest. The same study found how rarely that happens: “98.3% of spec files with a recorded history have a single author” (Agarwal et al., 2026, preprint).

Spec-driven development, as most teams practise it, is a developer’s tool. The product manager is the reason it can be more than that — and what the research says about the rest of its claims is in does spec-driven development work?

Where Specroot fits

This is the problem Specroot works on: specs that product managers, clients and other reviewers can read and approve without git, with each change and the decision behind it kept with the spec. Specroot for teams using AI coding agents.