> ## Documentation Index
> Fetch the complete documentation index at: https://docs.plannotator.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# PRD vs Technical Specification vs Implementation Plan

> Choose a PRD, technical specification, or implementation plan by whether you need product intent, technical design, or an execution sequence.

Use a PRD to define what product outcome is needed and why. Use a technical specification to define how the system should behave and be designed. Use an implementation plan to sequence the current work. Link them instead of forcing all three jobs into one document.

## The practical comparison

| Question                              | PRD                                                                  | Technical specification                                                         | Implementation plan                                         |
| ------------------------------------- | -------------------------------------------------------------------- | ------------------------------------------------------------------------------- | ----------------------------------------------------------- |
| Main job                              | Establish product intent                                             | Establish maintained technical truth                                            | Establish the current execution sequence                    |
| Primary reader                        | Product, design, engineering, research, stakeholders                 | Engineers, operators, security, maintainers                                     | Implementers and reviewers of this change                   |
| Typical contents                      | Users, journeys, goals, non-goals, requirements, acceptance, metrics | Architecture, interfaces, data, failures, security, compatibility, verification | Affected areas, ordered steps, dependencies, risks, tests   |
| Should choose implementation details? | Only when a true product constraint requires one                     | Yes, at the level needed to preserve behavior and design                        | Uses accepted design to name concrete work                  |
| Lifecycle                             | Updated while product intent changes; then superseded deliberately   | Maintained with the system or explicitly superseded                             | Usually completed, abandoned, or replaced after the change  |
| Key review question                   | Are we solving the right problem with a testable boundary?           | Is the design correct, safe, operable, and maintainable?                        | Can this sequence implement and verify the accepted design? |

## One requirement through all three documents

```text theme={null}
PRD
  FR-4: An owner can choose an expiry when creating a guest link.

Technical specification
  Store an optional expiry timestamp, evaluate it in the access resolver before
  reading content, and make expired and unknown public responses equivalent.

Implementation plan
  1. Add the expiry field and migration.
  2. Enforce expiry in the shared access resolver.
  3. Add the Share-dialog control.
  4. Prove response equivalence and existing-link compatibility.
```

The documents remain traceable without repeating every paragraph. If evidence changes the product boundary, update the PRD. If implementation evidence changes the accepted design, update the technical specification or its linked ADR. If only the order of work changes, update the plan.

## Names vary, ownership should not

Some teams call the product-intent artifact a product specification, feature specification, or product brief. Some use “technical plan” for both design and sequencing. Do not manufacture a distinction from the filename alone. Inspect the document’s actual authority, contents, and lifecycle.

The separation here is supported by two inspectable source models:

* BMad Method’s pinned [PRD template](https://github.com/bmad-code-org/BMAD-METHOD/blob/717479bc3f50f38119fd958b9e577a8bde2e0184/src/bmm-skills/2-plan-workflows/bmad-prd/assets/prd-template.md) holds product intent before separate architecture, epics, and stories.
* GitHub Spec Kit’s pinned [feature specification](https://github.com/github/spec-kit/blob/57cc518d63d6f10da3dd93df1ebcadda87c59374/templates/spec-template.md), [implementation plan](https://github.com/github/spec-kit/blob/57cc518d63d6f10da3dd93df1ebcadda87c59374/templates/plan-template.md), and [task list](https://github.com/github/spec-kit/blob/57cc518d63d6f10da3dd93df1ebcadda87c59374/templates/tasks-template.md) assign different work to different artifacts.

For a concrete same-case artifact, inspect the [generated BMad express technical specification for reliable webhook delivery](https://github.com/plannotator/spec-planning-frameworks/blob/main/examples/bmad-method/raw/_bmad-output/specs/spec-reliable-webhook-delivery/SPEC.md). This run produced a technical specification, not a PRD.

## Choose the smallest complete set

* Use only a PRD when product scope needs agreement but design has not started.
* Add a technical specification when behavior or design must remain authoritative beyond one change.
* Add an implementation plan when the work spans enough systems or risk that sequence and validation need review.
* For a small reversible change, one well-written plan may carry enough product context. State that choice explicitly.

Copy the [PRD template](/templates/product-requirements-document), [technical specification template](/templates/technical-specification), or [AI coding plan template](/templates/ai-coding-plan). Read [What is a product requirements document?](/learn/planning/what-is-a-product-requirements-document) for the review workflow.

*Reviewed July 19, 2026. Written and maintained by the Plannotator documentation team.*