Your PO Should Own the Spec, Not the Developer — Here's How

Thesis

In most AI-assisted development workflows, the developer writes the prompt and owns the outcome. SPECLAN flips this: the Product Owner writes the spec, the status lifecycle controls who can do what, and the developer (human or AI) implements only what's been approved. The spec is a relay baton that passes between roles at each status gate.

Body

The Problem: Who Decides What Gets Built?

Every team hits this friction eventually. The PO writes a Jira ticket. The developer reads it, interprets it, and builds something. The PO looks at the result and says "that's not what I meant." Three sprints later, you're still iterating on the same feature.

AI agents made this worse, not better. Now the developer prompts an AI with a vague description, the AI generates 2,000 lines of code in minutes, and nobody — not the developer, not the PO, not the AI — has a clear record of what was actually specified. The code exists, but the intent is scattered across chat logs, Slack threads, and someone's memory.

The root cause isn't bad developers or bad POs. It's that nobody owns the spec as a living artifact. Jira tickets describe work to be done. Confluence pages describe features that were planned. But neither survives as the authoritative record of what the product should do, updated as it moves through development.

The SPECLAN Approach: Roles + Status Gates

SPECLAN structures this with a simple idea: the spec file has a status, and the status determines who's responsible.

draft → review → approved → in-development → under-test → released

Each transition is a handoff between roles. Not a notification. Not a Slack message. A status change in the file's YAML frontmatter, committed to Git, visible to the entire team.

A Concrete Example: Adding a Shopping Cart

Let's walk through it.

Phase 1: The PO Drafts the Spec (Status: draft)

Sarah is the Product Owner. She opens VS Code, navigates to the SPECLAN spec tree, and creates a new Feature: "Shopping Cart." Under it, she creates three Requirements:

• R-4201: "Add to Cart" button on product pages
• R-4202: Cart page with quantity editing and removal
• R-4203: Cart persistence across sessions (localStorage + server sync)

She writes each requirement using the WYSIWYG Markdown editor — no code, no YAML syntax to learn. She describes what the feature should do, not how to implement it. For R-4201, she writes:

When a user clicks "Add to Cart" on a product page, the item is added to their cart with a quantity of 1. If the item is already in the cart, the quantity increments. A toast notification confirms the action. The cart icon in the header updates to show the total item count.

She adds Acceptance Criteria under each Requirement:

• AC-8501: Toast notification appears within 500ms
• AC-8502: Cart icon count updates without page reload
• AC-8503: Adding a duplicate item increments quantity rather than creating a new entry

All of this lives in the spec tree as individual Markdown files with YAML frontmatter. Status: draft.

What the dev team sees: The specs are visible in their tree view. They can read them, comment in Git, and ask questions. But the status is draft — this is explicitly not ready to implement. No AI agent picks it up. No developer starts coding. The PO is still thinking.

This is the draft fence. It prevents the #1 failure mode in AI-assisted development: implementing something that wasn't fully thought through.

Phase 2: The Team Reviews (Status: review)

Sarah finishes drafting and changes all three Requirements to review. This signals the team: "I think this is ready, but I want your eyes on it."

Marco, the senior developer, reads R-4203 and flags a concern: localStorage has a 5MB limit, and a large cart with product images in the metadata could hit it. He suggests stripping image URLs from the stored cart object. Sarah updates the spec.

Lisa, the QA lead, reads the Acceptance Criteria and adds a note: AC-8503 needs to define what happens when the item is at maximum stock quantity. Sarah adds AC-8504: "If the item is at max stock, show a 'maximum reached' message instead of incrementing."

The reviewers are satisfied. They set the status to approved.

Key detail: All of this happened in Git. Marco's concern is a commit. Sarah's revision is a commit. Lisa's addition is a commit. The full history of how the spec evolved is preserved — not in Jira comments that nobody reads after the sprint, but in the same repository as the code.

Phase 3: The Dev Team Implements (Status: in-development)

Now the specs are approved. The dev team opens the Implementation Assistant in SPECLAN. They select the three approved Requirements and SPECLAN generates a workpackage breakdown — a structured plan that groups the specs into logical implementation chunks:

# Shopping Cart Implementation

- [ ] Cart Data Layer
  - [[R-4203-cart-persistence]]
  - [ ] localStorage adapter with size guard
  - [ ] Server sync API endpoint

- [ ] Product Page Integration
  - [[R-4201-add-to-cart]]
  - [ ] "Add to Cart" button component
  - [ ] Toast notification system
  - [ ] Header cart icon with live count

- [ ] Cart Page
  - [[R-4202-cart-page]]
  - [ ] Quantity editor with stock limits
  - [ ] Item removal with undo

The AI agent reads the approved specs via SPECLAN's MCP tools — it has access to the full requirement text, acceptance criteria, and the spec hierarchy. It doesn't guess. It implements what was specified.

As each item progresses, the spec status updates: in-development while work is ongoing. The PO can see exactly what's being worked on and what's still pending. No standup needed to know the status — it's in the spec file.

The AI is a team member, not a cowboy. It works within the same status lifecycle as everyone else. It can't implement a draft spec. It can't skip review. The human governance layer stays intact even when the coding is automated.

Phase 4: QA Handback (Status: under-test)

Development is done. The spec status moves to under-test. This is the handback moment — responsibility flows back from the dev team to the experts.

Sarah deploys to the QA staging environment. She opens each Acceptance Criterion in SPECLAN and tests manually:

• AC-8501: Click "Add to Cart." Toast appears in ~200ms. ✓
• AC-8502: Cart icon updates. No page reload. ✓
• AC-8503: Add the same item twice. Quantity shows 2. ✓
• AC-8504: Add item at max stock. "Maximum reached" message. ✓

The person who wrote the requirement is the person who accepts the result. Not a developer marking their own ticket as done. Not a QA engineer who wasn't in the planning room. The PO who defined the acceptance criteria checks them off.

Phase 5: Release (Status: released)

The team agrees the work is done. The spec status moves to released. The code ships to production.

The spec files don't disappear. They remain in the repository as the permanent record of what the product does and why. Six months from now, when someone asks "why does the cart sync to the server instead of just using localStorage?", the answer is in the spec file — including Marco's commit from the review phase explaining the 5MB limit concern.

Why Not Just Use Jira?

Jira tickets describe work to be done. They live in a sprint, get completed, and nobody looks at them again. The acceptance criteria on a Jira ticket are a checklist for a moment in time — they don't survive as a living document.

SPECLAN specs describe what the product does. They survive after the sprint. They're the authoritative record of intent, updated as the product evolves. When the next feature depends on how the shopping cart works, the developer reads the spec — not a closed Jira ticket from six months ago.

Aspect	Jira Ticket	SPECLAN Spec
Describes	Work to do	Product behavior
Lifespan	One sprint	Product lifetime
Lives in	External tool	Git (next to the code)
After completion	Closed, archived	Released, still authoritative
Collaboration	Comments	Git commits (full history)
AI-readable	Copy-paste into prompt	MCP tools read directly
Status gates	Optional workflow	Enforced lifecycle

The two aren't mutually exclusive — you can use Jira for sprint planning and SPECLAN for the specs themselves. But the spec should outlive the sprint.

What Makes This Different

1. The PO writes the spec, not the developer. The person closest to the customer defines the requirement. The developer (or AI) translates it to code. The spec bridges the gap with enough structure to be machine-readable but enough flexibility to be human-written.

2. Status gates enforce the workflow. A draft spec can't be accidentally implemented. An approved spec has been reviewed by the team. under-test means someone needs to verify. You don't need process discipline — the tool enforces it.

3. Git is the collaboration layer. No switching between Jira, Confluence, Slack, and the codebase. Specs live in the same repo as the code. Same branches, same PRs, same review flow. The PO doesn't need to learn a new tool — VS Code with SPECLAN is enough.

4. AI agents respect the lifecycle. They read specs via MCP tools, not copy-pasted prompts. They only implement approved specs. They update the status as work progresses. The AI is governed by the same rules as human developers.

5. The spec outlives the sprint. When the next developer asks "what is this code supposed to do?", the answer is in the spec file — with the full review history, acceptance criteria, and the PO's original intent.

Solo Developers: All Roles, One Person

This isn't just for teams. If you're a solo developer or indie maker, you're already playing all these roles — you just switch between them unconsciously, and that's where things break.

You're the PO when you decide what to build. You're the developer when you implement it. You're the QA when you test the result. The problem is that without structure, these mental switches happen mid-sentence. You're halfway through writing a spec when you think "I know how to build this" and jump straight to coding. The spec never gets finished. Two weeks later, you can't remember what you originally intended.

SPECLAN's status lifecycle gives solo developers what it gives teams: forced phase separation.

• Specificator hat on: You write specs in draft, think through edge cases, define acceptance criteria. No coding yet — the status fence keeps you honest.
• Reviewer hat on: You re-read your own specs with fresh eyes, move them to review, then approved. This is the moment where you catch "wait, I forgot about the error case" — before a single line of code exists.
• Implementor hat on: Now you (or your AI agent) implement from approved specs. The spec is your context — no re-inventing decisions from memory.
• Verifier hat on: After under-test, you check your own acceptance criteria. Did you actually build what you specified? Not "does the code work" but "does it do what I intended?"

The status lifecycle isn't bureaucracy. It's a mental discipline tool that structures your work into phases. Most solo developers skip straight from idea to code and wonder why month 3 is a mess. The ones who don't skip it — whether they use SPECLAN or just Markdown files — ship better software.

This is the same workflow as the team example above, just with one person wearing all the hats. The Git history still captures your thinking. The specs still survive between sessions. And when you come back to the project after a vacation, you read the spec tree instead of reverse-engineering your own code.

Key Points

• The spec is a relay baton: PO drafts it, team reviews it, devs implement it, PO accepts it
• Status gates (draft → review → approved → in-development → under-test → released) are ownership signals, not just labels
• Git is the collaboration layer — same repo, same PRs, same history as the code
• AI agents are team members, not cowboys — they work within the status lifecycle
• Specs outlive sprints — they're the permanent record of product intent
• Solo developers benefit equally: status gates enforce phase discipline (specify → implement → verify) and prevent the "idea to code with no spec" failure mode