AI-Ready Docs

01 / PRD

Product Requirements Document

What are we building and why?

The PRD defines the product before implementation begins. It establishes the problem, users, goals, scope, and boundaries that guide everything that follows.

Layer
Product
Primary purpose
Define the product and its boundaries.
Used by
Product / Design / Engineering / AI
On this page
  1. 01What is it?
  2. 02Why do we need it?
  3. 03When do we create it?
  4. 04Who benefits from it?
  5. 05What does it contain?
  6. 06What does it NOT contain?
  7. 07How does AI use it?
  8. 08How does it connect to other documents?
  9. 09Example
  10. 10Template
  11. 11Common mistakes
01

What is it?

The Product Requirements Document defines what the product is, why it exists, who it serves, what it should achieve, and where its boundaries are.

It establishes product-level context before detailed feature, design, and engineering decisions are made.

PRD defines

  • Product intent
  • Product boundaries
  • Product goals

PRD does not define

  • UI implementation
  • Database structure
  • API contracts
  • Code architecture
02

Why do we need it?

When there is no product-level definition, later documents and AI implementation are left to make their own assumptions about the product.

Without a PRD

Idea
Feature decisions
Design decisions
Code

With a PRD

Idea
Product definition
Features
Design
Engineering
Implementation
03

When do we create it?

Create the PRD before detailed feature, design, and engineering decisions begin.

The PRD can evolve as the product becomes clearer, but it should establish the initial product direction before implementation starts.

Idea
PRD
FSD / BRD / UFD
Design + Engineering
Implementation
04

Who benefits from it?

  • Product

    Uses the PRD to define goals, scope, and product direction.

  • Design

    Uses it to understand users, problems, goals, and product boundaries.

  • Engineering

    Uses it to understand what is being built and why.

  • AI agent

    Uses it as product-level context while implementing later specifications.

05

What does it contain?

These are the proposed PRD sections for this methodology.

  1. 01

    Product Overview

    A brief summary of what the product is.

  2. 02

    Problem Statement

    The problem the product exists to solve.

  3. 03

    Target Users

    Who the product is for.

  4. 04

    Product Vision

    The long-term direction of the product.

  5. 05

    Goals

    What the product is intended to achieve.

  6. 06

    User Needs

    The needs the product must address.

  7. 07

    Value Proposition

    Why the product matters to its users.

  8. 08

    MVP Scope

    What is included in the first usable version.

  9. 09

    Out of Scope

    What is explicitly excluded.

  10. 10

    Success Criteria

    How success will be evaluated.

  11. 11

    Assumptions

    What is being assumed to be true.

  12. 12

    Constraints

    Limitations the product must work within.

  13. 13

    Risks

    Potential risks to the product or its delivery.

06

What does it NOT contain?

  • Detailed feature behavior
  • Detailed business rules
  • User flow diagrams
  • UI specifications
  • Database schema
  • API contracts
  • Technical architecture
  • Implementation tasks

PRD

Defines product context.

Other documents

Define increasingly specific decisions.

07

How does AI use it?

The PRD gives the AI agent product context. It helps the agent understand what is being built, who it is for, why it exists, and what is inside or outside the intended scope.

PRD
Product context

AI understands

  • What the product is
  • Who it serves
  • What problem it solves
  • What the goals are
  • What is in scope
  • What is out of scope

The PRD is context, not a direct coding instruction. It informs decisions made in later documents rather than dictating them.

Context

PRD

Constraints

BRD

Implementation instructions

AI Instructions

08

How does it connect to other documents?

PRD
FSD
BRD
UFD
DSD
DDD / ASD / TAD
DR
AI Instructions

The PRD establishes the product context that later documents make progressively more specific.

This isn't necessarily one strict linear sequence — documents can inform each other and evolve together.

09

Example

Feature concept

Create a Project

PRD perspective

Users need a way to organize their work into projects.

PRD

Why

Why the capability exists

FSD

What

What the Create Project feature does

BRD

Rules

Rules the feature must follow

UFD

Behavior

How the user reaches and completes it

DSD

Interface

How the interface behaves

DDD

Data

What data is stored

ASD

Communication

How the client communicates with the backend

TAD

Structure

How it is structured in the codebase

DR

Order

When it should be implemented

AI Instructions

Implementation

How the agent should implement it

10

PRD Template

prd-template.md

# Product Requirements Document

## 01. Product Overview

## 02. Problem Statement

## 03. Target Users

## 04. Product Vision

## 05. Goals

## 06. User Needs

## 07. Value Proposition

## 08. MVP Scope

## 09. Out of Scope

## 10. Success Criteria

## 11. Assumptions

## 12. Constraints

## 13. Risks
11

Common mistakes

  • Writing implementation details too early.
  • Turning the PRD into a feature dump.
  • Leaving scope undefined.
  • Describing solutions instead of problems.
  • Writing goals that cannot be evaluated.
  • Expecting the PRD to define technical architecture.
  • Letting AI fill in major product decisions that were never documented.