operatorlab.ai
← All playbooks
Workflow

PRD-First Development

A repeatable workflow for turning a vague product idea into a shippable PRD that an agent (or a team) can execute against without ambiguity.

8 min read

If you've ever handed Claude Code a four-line ticket and watched it confidently sprint in the wrong direction, you already know the lesson: the agent is only as good as the brief. Writing a real PRD before writing a single line of code is no longer a "process" tax — it's the highest-leverage move you make per hour.

This site itself was built this way. The docs/PRD.md and docs/portfolio.md files in the repo are the literal artifacts that became the implementation plan. Look there for a worked example as you read.

The shape of a useful PRD

A PRD is useful to an agent when it answers, in order:

  1. Why does this exist? One paragraph. Not features — the world it changes.
  2. What does "done" feel like? Concrete success criteria a non-builder can verify.
  3. What are the non-goals? This is where most PRDs collapse. Every "let's also" you don't write down here becomes scope creep at 2pm on Friday.
  4. What's the stack and the non-negotiables? Framework, language, deploy target, design principles. The agent will quietly pick its own if you don't.
  5. What's the build sequence? Order matters more than completeness. Even a rough 1→8 ordering beats a perfect bag of work items.

The loop

PRD-first iteration loop
  1. Step 1Draft PRDHuman writes vision + constraints
  2. Step 2PlanAgent proposes architecture, asks 2-3 questions
  3. Step 3ExecuteAgent implements in sequence
  4. Step 4VerifyHuman checks against success criteria
  5. Step 5Update PRDEncode lessons back into the doc

The fifth step is the one nobody does. Treat the PRD as a living spec the way a senior engineer treats their ARCHITECTURE.md. Every time you catch the agent doing the wrong thing, ask whether the PRD told it to — and if not, fix the PRD before fixing the code.

A minimal template

docs/PRD.md
# <ProjectName> — PRD

## Context
Why this exists, in one paragraph.

## Success criteria
- A non-builder can verify each of these.
- They should fail today and pass when we're done.

## Non-goals
- Things that look related but we are explicitly NOT doing.

## Stack
- Framework, language, hosting, key libraries.
- Anything load-bearing the agent shouldn't second-guess.

## Build sequence
1. ...
2. ...

That's it. Five sections, no decorations. The discipline isn't in the format — it's in the willingness to write the non-goals before you write the goals.

When NOT to PRD

A PRD is a tax. For one-line fixes, single-file refactors, or anything you'd handle in less time than the brief itself takes to write — skip it. The right test is: would another engineer (or another agent) be able to execute this without asking me a single clarifying question? If yes, you don't need a doc. If no, you do.