AI-Ready Docs

09 / DR

Development Roadmap

In what order should the product be implemented?

The Development Roadmap translates the documented product, design, data, communication, and architecture decisions into an ordered implementation sequence. It defines what should be built, what each task depends on, and how completed work should be verified.

Layer
Implementation
Primary purpose
Define the order in which the product should be implemented.
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. 07What does an implementation task look like?
  8. 08Roadmap elements
  9. 09How does AI use it?
  10. 10How does it connect to other documents?
  11. 11Example
  12. 12Template
  13. 13Common mistakes
01

What is it?

The Development Roadmap translates documented product, design, data, communication, and architecture decisions into an ordered implementation sequence. It defines what should be built, in what order, and what each piece of work depends on.

  • FSD

    What

  • BRD

    Rules

  • UFD

    Behavior

  • DSD

    Experience

  • DDD

    Data

  • ASD

    Communication

  • TAD

    Structure

  • DR

    Order

TAD answers how the system is structured. DR answers in what order that structure should be implemented.

02

Why do we need it?

Complete specifications can describe everything a product needs to do without describing the order in which that work should be implemented, or what each piece of work depends on.

Without DR

Specifications
Large implementation task
AI decides order
Hidden dependencies
Unclear progress

With DR

Specifications
Dependencies identified
Ordered implementation tasks
Incremental verification
Implementation

The purpose is to make implementation sequence explicit. The problem is undocumented implementation dependencies, not that developers cannot plan implementation.

03

When do we create it?

The DR is created once the product, business rules, behavior, experience, data, communication, and architecture provide enough context to define a safe implementation order.

DR should not be created by guessing implementation order before the relevant specifications exist.

PRD
FSD
BRD
UFD
DSD
DDD
ASD
TAD
DR
Implementation
04

Who benefits from it?

  • Product

    Uses it to understand how the documented product becomes an implementation sequence.

  • Design

    Uses it to understand when interface work is expected to be implemented and what it depends on.

  • Engineering

    Uses it to understand implementation dependencies, task boundaries, and verification requirements.

  • AI agent

    Uses it as the execution sequence and task context for implementation.

05

What does it contain?

These are the fields a development roadmap can define.

  1. 01

    Implementation Phases

    Logical groups of implementation work.

  2. 02

    Tasks

    Specific pieces of implementation work.

  3. 03

    Task IDs

    Stable identifiers for implementation tasks.

  4. 04

    Dependencies

    Other tasks or decisions that must exist first.

  5. 05

    Prerequisites

    Conditions that must be satisfied before a task begins.

  6. 06

    Specification References

    Links back to the relevant PRD, FSD, BRD, UFD, DSD, DDD, ASD, or TAD decisions.

  7. 07

    Scope

    What the task includes and does not include.

  8. 08

    Acceptance Criteria

    Conditions that must be satisfied for the task to be considered complete.

  9. 09

    Verification

    How the implementation should be checked.

  10. 10

    Implementation Order

    The sequence in which tasks should be executed.

  11. 11

    Status

    The current implementation state when status tracking is relevant.

  12. 12

    Specification Gaps

    Known missing decisions that block implementation.

  13. 13

    Milestones

    Meaningful points where a coherent capability or system layer becomes usable.

Not every roadmap needs every field — only document what is relevant to the product.

06

What does it NOT contain?

  • Product vision
  • Feature requirements
  • Business rules
  • Complete user flows
  • UI design decisions
  • Database schema
  • API contracts
  • Technical architecture
  • Detailed source code
  • AI behavior rules
  • Team performance tracking
  • Individual productivity metrics
  • Sprint ceremonies
  • Generic project-management processes

TAD

How is the system structured?

DR

In what order should it be implemented?

AI Instructions

How should the agent behave during implementation?

07

What does an implementation task look like?

Implementation task

Task ID
TASK-021
Task name
Implement Project Creation

Purpose

Implement the project creation capability defined by the existing specifications.

Specification references

  • FEAT-004Create Project
  • RULE-001Project creation rule
  • FLOW-001Create Project
  • SCREEN-009Create Project interface
  • ENTITY-001Project
  • API-014Create Project
  • COMP-001Project Service

Prerequisites

  • Project data structure defined.
  • Project communication contract defined.
  • Project component responsibility defined.

Depends on

  • TASK-018Project data model
  • TASK-019Project communication contract
  • TASK-020Project service foundation

Scope

Implement the defined project creation capability within the documented architecture.

Do not introduce new product behavior.

Acceptance criteria

  • The documented project creation flow can be completed.
  • The defined business rules are respected.
  • The defined interface behavior is implemented.
  • The documented data is persisted correctly.
  • The documented communication contract is respected.
  • The implementation remains within the defined architectural boundaries.

Verification

  • Run the relevant tests.
  • Verify the documented flow.
  • Verify expected success and error states.
  • Confirm no undocumented behavior was introduced.

Implementation order

TASK-018
TASK-019
TASK-020
TASK-021

Each task depends on the one before it. TASK-021 cannot begin until TASK-018, TASK-019, and TASK-020 are complete.

This is a methodology example — no actual code or framework-specific implementation is defined here.

08

Roadmap elements

  1. 01

    Phase

    A logical grouping of related implementation work.

  2. 02

    Task

    A specific implementation unit.

  3. 03

    Dependency

    A task or condition that must be satisfied first.

  4. 04

    Prerequisite

    A required condition before work begins.

  5. 05

    Reference

    The specification that defines the requirement being implemented.

  6. 06

    Acceptance Criteria

    Conditions that determine whether the task is complete.

  7. 07

    Verification

    How the completed implementation is checked.

  8. 08

    Milestone

    A meaningful point where a coherent part of the product becomes usable.

  9. 09

    Specification Gap

    A missing decision that prevents safe implementation.

09

How does AI use it?

The DR gives the AI agent an explicit implementation sequence to follow. It tells the agent what to build next, what it depends on, which specifications apply, and how the result should be verified.

DR
Implementation sequence

AI understands

  • What task comes next
  • What it depends on
  • Which specifications apply
  • What the task includes
  • What the task does not include
  • What acceptance criteria apply
  • How the result should be verified

Without DR

Complete specification
AI chooses implementation order

With DR

Complete specification + DR
AI follows defined implementation sequence

DR controls implementation order. It does not control agent behavior. AI Instructions will define how the agent should behave while executing each task.

Specification gap

Task

Implement Project Creation

Blocked by

Project creation ownership is not defined.

The relevant product, data, and API specifications exist, but the required architectural decision is missing.

Implementation paused.

Decision required

Define the missing architectural responsibility before continuing.

Human

  • Implementation priorities
  • Dependencies
  • Task boundaries
  • Acceptance criteria
  • Verification requirements
  • Decisions when specifications are incomplete

AI

  • Defined implementation tasks
  • Defined dependencies
  • Defined acceptance criteria
  • Tests
  • Refactoring
  • Repetitive implementation work
  • Verification within the documented scope

AI should execute an implementation sequence, not invent one while coding.

10

How does it connect to other documents?

FSD

Create Project

“What capability exists?”

BRD

Project creation rules

“What conditions apply?”

UFD

Create Project flow

“How does the behavior progress?”

DSD

Create Project interface

“How should the experience be represented?”

DDD

Project data

“What information must be stored?”

ASD

Create Project operation

“How is information communicated?”

TAD

Project technical structure

“Where does the behavior belong?”

DR

Project implementation task

“When should it be implemented?”

The DR does not create new product or technical decisions. It organizes already-defined decisions into an executable implementation sequence.

Feature

FEAT-004

Rule

RULE-001

Flow

FLOW-001

Screen

SCREEN-009

Entity

ENTITY-001

API

API-014

Component

COMP-001

Task

TASK-021

11

Example

Feature concept

Create a Project

DR perspective

The project creation capability is broken into dependent implementation tasks and placed in the appropriate execution sequence.

PRD

Why

Users need a way to organize their work into projects.

FSD

What

Users can create a project.

BRD

Rules

Project creation follows defined business rules.

UFD

Behavior

The user moves through the project creation journey and reaches a defined outcome.

DSD

Experience

The interface represents the journey through defined screens, states, interactions, responsive behavior, and feedback.

DDD

Data

The system stores the project information and its relationship to the relevant organization.

ASD

Communication

The project creation operation defines how the client communicates the required information and receives the result.

TAD

Structure

The technical component responsible for project creation is defined together with its responsibilities, boundaries, and dependencies.

DR

Order

The project creation capability is broken into dependent implementation tasks and placed in the appropriate execution sequence.

AI Instructions

Implementation

The agent follows the defined task sequence and behavior rules while implementing the work.

12

DR Template

dr-template.md

# Development Roadmap

## 01. Implementation Overview

## 02. Phase

### Phase ID

### Phase Name

### Purpose

### Dependencies

### Milestone

---

## 03. Implementation Task

### Task ID

### Task Name

### Purpose

### Specification References

### Prerequisites

### Dependencies

### Scope

### Out of Scope

### Acceptance Criteria

### Verification

### Status

---

## 04. Implementation Order

## 05. Milestones

## 06. Specification Gaps

## 07. Open Implementation Decisions
13

Common mistakes

  • Creating tasks before understanding the underlying specifications.
  • Turning the roadmap into a list of vague feature names.
  • Creating tasks without dependencies.
  • Creating tasks that are too large for incremental verification.
  • Creating tasks that are so small they provide no meaningful implementation boundary.
  • Leaving specification references out of implementation tasks.
  • Defining acceptance criteria that cannot be verified.
  • Mixing new product decisions into implementation tasks.
  • Using the roadmap to introduce undocumented technical architecture.
  • Letting AI change implementation order without a documented reason.
  • Treating status tracking as more important than implementation clarity.
  • Starting a task while a required specification gap is unresolved.
  • Writing a roadmap that only humans can understand.
  • Letting AI implement the entire roadmap in one uncontrolled pass.