In Class 42 you gave the project a durable memory: a specification that records what the system is supposed to do, and a decision log that records why. A roadmap is what turns that memory into order. It answers the question every AI worker asks next, explicitly or implicitly: what should happen first, what must wait, and how will we know a phase is done?

Without a roadmap, "build the app" becomes a thousand untracked AI decisions. One agent builds login before data exists. Another invents a payment flow nobody approved. Nothing fits.

A roadmap is not a wishlist

A wishlist says "it would be nice to have payments, social sharing, live refresh, and an agent swarm." A roadmap says "Phase 1 delivers this usable capability, after these prerequisites, validated by this check, with these things explicitly out of scope."

Define it plainly:

Each word earns its place:

• Sequenced. Order matters. Some work must come before other work.
• Phases. Each phase creates a usable capability, not just activity.
• Dependencies. What must exist before this phase can start.
• Validation. How you prove the phase works — not "it looks done."
• Ownership. Who (which human, which model role) is responsible.
• Stop points. Gates where the project pauses for review before continuing.

The transformation: user problem to tasks

Roadmapping is a transformation with five visible steps:

User problem
  → PRD / feature spec
  → architecture boundaries
  → dependencies and risk
  → phases that create usable capability
  → small tasks with acceptance checks

Walk it with the course running example, the research dashboard: a user chooses a public company, sees a source-linked research brief, saves a private watchlist, and later receives a refreshed brief.

1. User problem. "I want to research a company and trust what I read." That is the starting truth from PRD.md.

2. PRD / feature spec. The spec from Class 42 narrows it: public-company scope, approved sources only, brief with citations, private watchlist, empty and error states, three acceptance checks. It also records non-goals.

3. Architecture boundaries. ARCHITECTURE.md draws the boxes: frontend page, data/API layer over approved sources, database for saved items, auth boundary for the private watchlist, scheduled job for refresh, and deployment with observability. No code yet — just the surfaces where work could collide.

4. Dependencies and risk. Now the ordering logic appears. A screen can be mocked before the real data exists. A real saved watchlist cannot — it depends on user identity, a data model, access rules, and an agreed interface. Refresh cannot run before there is something worth refreshing. Auth cannot be an afterthought bolted onto saved data.

5. Phases, then tasks. Group the work into phases that each deliver something checkable, then break each phase into small tasks (Class 44 teaches task cards in full).

The dashboard v1 order

A sensible v1 phase order for the research dashboard looks like this:

Notice what is missing from v1: payments, social features, and an agent swarm. Not because they are uninteresting, but because they add risk and dependencies without serving the v1 outcome. An AI can generate a payments page in minutes. That does not make payments part of v1.

Dependencies make collisions visible early

The most valuable sentence in a roadmap is often "X cannot start until Y is agreed."

Consider two workers in parallel. Worker A builds a watchlist screen against a mocked list. Worker B builds the real save endpoint. If the mock assumes a plain array of tickers and the endpoint requires user identity, a data model, access rules, and a shaped interface, the two disagree at integration. Both did reasonable work in isolation.

The roadmap prevents this by naming the dependency chain for the real watchlist:

user identity → data model → access rules → interface contract → UI

Mocked screens may proceed against the agreed contract (Lesson 43.2). Real persistence waits its turn. Two agents building conflicting assumptions is not a speed problem. It is a planning problem.

Milestone versus task

People blur these two, and AI happily blurs them further. Keep them distinct:

• A milestone is a checkable capability: "research brief works for one company with visible sources."
• A task is one bounded piece of work that moves toward it: "render publishedAt beside each citation with a missing-date state."

"Work on frontend" is neither. It has no user outcome, no finish line, and no validation. If you cannot demo it to a skeptical reviewer, it is not a milestone. If a new AI session cannot execute it after reading the named files, it is not yet a task.

The ROADMAP.md shape

Keep one canonical roadmap file. Every phase uses the same fields so reviewers and agents know where to look:

# ROADMAP.md — Research Dashboard v1

## Phase 3: Single-company brief UI

- Goal:
- User value:
- Prerequisites:
- Tasks:
- Owner / model role:
- Risk level:
- Validation:
- Non-goals:
- Decision gate:

What each field must contain:

Non-goals and the decision gate are the fields beginners skip and experienced builders never skip. Non-goals stop scope creep. The gate forces a human decision before risk increases — especially before Phase 5, where identity and private data enter.

Exercises

1. Write a three-phase roadmap. Pick a real small product — the research dashboard or your own. For each phase, write one user-visible outcome, one dependency, one risk, and one validation event. Keep it to one page.

Finish line: a ROADMAP.md where the next phase is obvious, and you can explain in one sentence why it comes before the following one.

Verify it with this check: cover the task list and read only the goals, prerequisites, and gates. If the order still makes sense, the roadmap is doing its job.

Common failure: phases named by layer ("frontend phase," "backend phase"). Recovery: rename each phase by user capability ("visitor sees a sourced brief") and move layer work inside it as tasks.

Check your understanding

• What distinguishes a roadmap from a feature wishlist?
• Why does the real watchlist depend on identity, data model, access rules, and an interface, while a mocked screen does not?
• What is the difference between a milestone and a task?
• Which two ROADMAP.md fields most directly prevent scope creep and premature escalation?

In the next lesson you will solve the failure this roadmap exposes: separate workers building pieces that do not fit. The fix is planning the interfaces before parallel work begins.