Module 3, Lesson 5: Writing the Implementation Roadmap

In this lesson, I'm taking the Feature Priority Matrix we generated in Lesson 4 and turning it into something you can actually execute against — a phased implementation roadmap, broken down into sprints, with a risk register and release checkpoints built in.

ℹ️

No corrections or updates to flag from previous lessons. Carry everything forward.

Before We Start

Here's what I'd expect you to have in place before this lesson:

From previous lessons:

Your .project/feature-priority-matrix.md exists — generated in Module 3, Lesson 4
Your /specs folder is populated with feature spec files — from Module 3, Lesson 2
Claude Code is installed and running in your WebStorm terminal

Tools / setup you'll need:

WebStorm open with your project loaded
Claude Code running in the terminal (claude command works)
Your .project/feature-priority-matrix.md file ready — this is the primary input for this lesson

By the end of this lesson, you'll:

Understand what an implementation roadmap is and why it needs to come from the RICE matrix — not your gut
Know how to write the prompt that turns the priority matrix into a sprint-by-sprint delivery plan
Have a .project/implementation-roadmap.md saved in your project — a real, structured roadmap with phases, sprints, a risk register, and release checkpoints
Understand how the design-dev pipeline fits into sprint planning (it's not just developers)

About This Lesson

Duration: ~10 minutes video + ~20 minutes practice
Skill Level: Intermediate
What You'll Build: An Implementation Roadmap document — phased delivery plan, sprint breakdown, risk register, and release checkpoints saved in your project.

The last lesson gave you a ranked list of what to build. This lesson answers the follow-up question: when, and in what order. It sounds like it should be simple — just take the RICE scores and line them up chronologically. But there's more to it than that. Dependencies matter. Design has to stay ahead of development. Capacity is real. And you need to know, at the end of every phase, what you can actually ship to users.

That's what this lesson covers.

Watch the Lesson

ℹ️

How I'd suggest going through this: Watch the video first without stopping — just get the big picture. Then come back here and work through the guide section by section, pausing the video at the timestamps I've noted. After that, this guide is your reference — you shouldn't need to rewatch to look something up.

What We're Covering

Here's what I'm walking you through in this lesson:

Why prioritisation alone isn't a plan — knowing what's highest priority doesn't tell you when to build it or whether you have the capacity to build it
The design-dev pipeline — design has to stay ahead of development. If you're not planning for this, you'll get blocked
How to write the roadmap prompt — the specific structure I use to turn the RICE matrix into a phased, sprint-based delivery plan
What "shippable" means at the end of each phase — not just "code complete" but something a real user can actually get value from
The risk register — identifying risks before they bite you, not after

1. Let's Set the Scene (~0:00)

We're at the point in the process where we've defined what to build — the RICE matrix took care of that. Now we need to define when.

And this is where I've seen a lot of people — myself included, early on — skip a step. They look at their priority list and just start building the top item. Which sounds logical. But without a roadmap, you end up in a situation where you're building features in isolation, design isn't ready, things block each other, and you're three months in with nothing you can actually ship.

The implementation roadmap is the answer to that. It's not a Gantt chart. It's not a waterfall plan. It's a phased delivery structure — phases that each end with something shippable, broken down into two-week sprints, with the design pipeline explicitly planned in.

You're going to run one prompt in Claude Code and get a properly structured roadmap document out of it. That document lives in your project, right next to your specs and your priority matrix.

2. The Core Idea

2.1 Why "Just Build the Top RICE Features" Isn't Enough

Let me explain the gap that this roadmap fills.

Your RICE matrix gives you a ranked list. Feature A scores highest, followed by B, C, D, and so on. But here's the problem: some features depend on others. You can't build Feature C until Feature A exists. You can't build Feature E until the auth system is done. The RICE score doesn't account for that — it's a priority rank, not a build order.

On top of that, you have real capacity constraints. You've got a fixed number of developers, a fixed number of hours per sprint, and design work that needs to happen before development — not at the same time.

The roadmap takes the RICE output and applies these real-world constraints to produce something you can actually execute.

2.2 The Design-Dev Pipeline

This is the one thing most solo founders and small teams overlook: design has to be done before a story enters a dev sprint.

If you're designing and developing at the same time, you're constantly blocking yourself. The developer finishes building something, then the design changes, and you have to rebuild it. That's wasted effort.

The way I structure it is simple: design runs at least one sprint ahead of development. If a story is going into Sprint 3 for development, the design deliverables for that story need to be ready by the end of Sprint 2. The roadmap prompt I use makes this explicit — it tracks design status per sprint so you always know whether you're at risk of a design-dev collision.

ℹ️

On the course project, design is handled by a freelancer — which is exactly the scenario most builders are in. The roadmap tracks design as a separate workstream that feeds into dev, rather than treating it as something that happens alongside dev. If you're doing your own design, the same principle applies — don't design and build the same thing at the same time.

2.3 Release Checkpoints — What Can You Actually Ship?

At the end of every phase, I ask one question: what can we ship to users right now?

Not "what is technically complete" — but what delivers real value that a real user can benefit from. If you can't answer that question at the end of a phase, the phase isn't structured right.

This matters because it forces you to think in terms of user value, not engineering milestones. A half-built feature that you can't ship is a cost, not progress. The release checkpoint structure makes sure every phase ends with something that can go in front of users.

2.4 How This Builds on Module 3, Lesson 4

The input to this lesson is the .project/feature-priority-matrix.md file we generated in Module 3, Lesson 4. The roadmap prompt reads that file directly — so Claude is working from your actual scored and ranked features, not guessing. If you don't have that file yet, go back and do Lesson 4 first.

3. Let Me Show You How It Works (~1:30)

3.1 The Prompt

Here's the prompt I use to generate the implementation roadmap. You have access to this — copy it and run it in Claude Code:

Based on the .project/feature-priority-matrix.md, create an Implementation Order Roadmap.

Write to: .project/implementation-roadmap.md

Structure as follows:

## Roadmap Overview
- Total phases: [X]
- Sprint cadence: 2 weeks
- Dev team capacity: [X] developers × [Y] days per sprint = [Z] person-days
- Design: Freelance (tracked separately)

## Design-Dev Pipeline
Design must be complete before stories enter a sprint. Plan for:
- Design lead time: [X weeks ahead of dev sprint]
- Design deliverables: Figma files with approved UI/UX

## Phase 1: [Phase Name] (Sprints 1-2)
**Theme:** [What value does this phase deliver?]
**Success Criteria:** [How do we know this phase is done?]
**Design Status:** [Complete / In Progress / Not Started]

### Sprint 1 (Week 1-2)
| Story | Priority | Dev Estimate | Dependencies | Design Ready |
|-------|----------|--------------|--------------|--------------|

### Sprint 2 (Week 3-4)
[Same format]

## Phase 2: [Phase Name] (Sprints 3-4)
[Continue pattern]

## Risk Register
| Risk | Likelihood | Impact | Mitigation |
|------|------------|--------|------------|

## Release Checkpoints
After each phase, what is shippable to users?

Before you start, where relevant, do additional web search for context with the web search tool and ask me additional questions for clarity with the ask user question tool.

⚠️

Notice the last two lines of the prompt. These are instructions telling Claude to ask you questions before it starts writing. Answer those questions carefully — they're usually about your team size, sprint cadence, or design constraints. The more specific your answers, the more accurate the roadmap.

3.2 Running It in Claude Code

Open your terminal in WebStorm (Cmd + E → Terminal), run claude if it's not already running, and paste the prompt.

Before Claude writes anything, it will likely ask you a few clarifying questions — team size, number of developers, design availability, target timeline. This is the prompt's ask user question tool instruction doing its job. Answer these specifically. Don't be vague.

When Claude asks if it can make changes to your files, allow edits for the session. Same as Lesson 4 — you want it to write the file without asking permission before every change.

When it's done, navigate to .project/implementation-roadmap.md in your project.

3.3 What Claude Does With This

When Claude runs this prompt, it's doing several things simultaneously:

Reading the .project/feature-priority-matrix.md — it knows your features, their scores, and their dependencies from the previous lesson
Applying your capacity constraints (developer count × days per sprint) to figure out what actually fits in each sprint
Respecting the dependency map from the RICE matrix — it won't schedule Feature C before Feature A if A is a dependency
Keeping the design pipeline a sprint ahead of dev
Ending each phase at a natural "shippable" point
Building a risk register for the things most likely to cause problems

The output is a structured Markdown file you can read, share, and update as the project evolves.

4. Reading the Output

Here's what to look at when you open the roadmap:

Roadmap Overview — check that the capacity numbers are right. If Claude guessed your team size or sprint length, correct it and re-run. Everything downstream depends on these numbers.

Design-Dev Pipeline — check the design lead times. Is design actually scheduled far enough ahead of the dev sprints it feeds? If a story is going into Sprint 3 dev but design is also scheduled for Sprint 3, that's a problem. Design needs to be Sprint 2 at the latest.

Phase themes — each phase should tell a clear story about what a user can do by the end of it. If a phase theme sounds like an engineering task ("Set up the database layer") rather than user value ("Users can sign up and log in"), that phase probably needs to be reframed.

Sprint tables — look at the Dependencies column. If anything in Sprint 1 has a dependency that isn't already built, that needs to move or the dependency needs to be in Sprint 1 too. Don't let blocked stories sneak into early sprints.

Risk Register — read this carefully. Claude will flag the most likely risks based on your features and dependencies. Most of these will be things you already knew, but seeing them written down with likelihood and impact scores forces you to think about mitigation before it's a crisis.

Release Checkpoints — this is the most important section. For each phase, ask yourself: would I genuinely be comfortable putting this in front of a user? If the answer is no, the phase needs adjusting.

🔥

The release checkpoint question is a forcing function. If you can't ship something real to users at the end of Phase 1, you've probably front-loaded too much infrastructure. Infrastructure has to serve user value — if it's not enabling something a user can touch by the end of the first phase, reconsider the phasing.

5. Watch Out For These

⚠️

Skimming past Claude's clarifying questions
Here's why this happens: you're eager to see the output, so you answer quickly with vague responses.
The way I avoid it: treat those questions like a brief but important conversation. If Claude asks about team capacity, give it real numbers. If it asks about your launch timeline, give it a real date. Garbage in, garbage out.

⚠️

Treating the roadmap as fixed
Here's why this happens: it looks like a finished document, so people treat it like one.
The way I use it: this is a living document. As you build, you'll learn things that change your estimates and priorities. Update the roadmap when that happens — it's not a contract, it's a plan.

⚠️

Design not actually being ready before dev starts
Here's why this happens: the roadmap shows design as "In Progress" for Sprint 2, dev starts Sprint 3, and you assume it'll be done in time. Then it isn't.
The way I avoid it: design ready means design signed off and in Figma before the dev sprint starts — not "we're working on it." Treat the Design Ready column as a hard gate, not a status update.

6. Practice

Exercise 1: Generate Your Roadmap

What to do: Copy the prompt from Section 3.1 and run it in Claude Code. When Claude asks questions, answer them with real numbers — your actual team size, your actual sprint capacity, your target launch date. Navigate to .project/implementation-roadmap.md when it's done.

A nudge if you're stuck: If Claude isn't asking questions before writing, check that the last two lines of the prompt are included — the ask user question tool instruction is what triggers that behaviour. If it wrote the file without asking, re-read the roadmap and check if the capacity assumptions match your reality.

How you'll know it's working: You have a roadmap file with multiple phases, each ending at a natural shippable point, with sprint tables that include dependency and design-ready columns.

Exercise 2: Audit the Release Checkpoints

What to do: Read the Release Checkpoints section. For each checkpoint, write one sentence (in the doc or in your own notes) describing what a user could actually do at that point. If you can't write that sentence, the checkpoint isn't real yet — note that and flag it.

What this is practising: Product thinking. The ability to translate engineering milestones into user value is one of the most useful skills you can build as a founder.

7. You Should Be Able to Build This Now

With what we've covered in this lesson and the last one, you have:

A Feature Priority Matrix telling you what to build and in what order
An Implementation Roadmap telling you when to build it, with capacity constraints, design pipeline, and risk planning baked in

That combination is more rigorous planning than most small teams do. And it all lives in your project — tracked in version control, right next to your code.

Check Yourself

.project/implementation-roadmap.md exists in my project
The capacity numbers in the Roadmap Overview match my actual team
Design is scheduled at least one sprint ahead of the dev sprints it feeds
Each phase ends at a clear, shippable point I can describe in one sentence
I've read the Risk Register and I understand the top 2–3 risks going into the build

✅

If those are ticked, you're ready for the next lesson. The planning is done. We're going into the build phase — and we're going in prepared.

If Something's Not Working

⚠️

Claude wrote the roadmap without asking any questions
What's happening: The ask user question tool instruction didn't trigger — Claude may have had enough context to proceed, or the instruction was cut off.
How to fix it: Review the roadmap and check whether the capacity and timeline assumptions are reasonable. If they're not, add a note to the prompt with your actual constraints and re-run.

⚠️

The feature-priority-matrix.md file isn't found
What's happening: Claude can't locate the input file — either the path is wrong or the file doesn't exist yet.
How to fix it: Check that .project/feature-priority-matrix.md exists (it should from Module 3, Lesson 4). If it doesn't, go back to Lesson 4 and generate it first.

The Short Version

Here's what I want you to walk away with:

The RICE matrix tells you what, the roadmap tells you when — they're two separate documents that work together. Don't skip either one
Design before dev, always — plan for design to be a sprint ahead. Make it a hard gate, not a hope
Every phase ends with something shippable — if you can't describe what a user can do at the end of a phase, that phase needs restructuring
What you can do now: You have a full planning stack in your project — research → docs → specs → priority matrix → roadmap. That's your foundation for the build

Quick Reference

Output File Location

.project/implementation-roadmap.md

Input File (Required)

.project/feature-priority-matrix.md

Roadmap Structure

Roadmap Overview         → capacity, sprint cadence, team
Design-Dev Pipeline      → design lead time and deliverables
Phase N: [Name]          → theme, success criteria, design status
  Sprint N (Week X-Y)    → story table with estimates and dependencies
Risk Register            → risks, likelihood, impact, mitigation
Release Checkpoints      → what's shippable after each phase

How to Run

Open terminal in WebStorm (Cmd + E → Terminal on Mac)
Run claude if not already running
Paste the prompt from Section 3.1
Answer Claude's clarifying questions with real numbers
Allow file writes when prompted
Navigate to .project/implementation-roadmap.md to review

Resources

Tools Used

Questions I Get Asked

Q: Do I need to update the roadmap as I build?

Yes — and don't feel bad about it. The roadmap is a plan, and plans change as you learn things. If a feature takes twice as long as estimated, update the downstream sprints. If a dependency shifts, update the phases that depend on it. The document is most useful when it reflects reality, not when it perfectly matches what you wrote before you started.

Q: What if I'm the only developer?

Set your capacity accordingly — one developer, however many days per sprint you're realistically available. The maths still works. The roadmap will just show fewer stories per sprint, and that's honest. Better to plan for realistic capacity than to build a roadmap you'll never hit.

Q: Can I skip the risk register section?

You can, but I wouldn't. The risks Claude surfaces are usually the ones you already know about in the back of your head but haven't written down. Writing them down with likelihood and impact makes you take them seriously. The mitigation column is what matters most — it forces you to have a plan for things going wrong before they go wrong.

Q: How do I know I'm ready for the next lesson?

You've got a roadmap file, you've read it, and you can describe what's shipping at the end of each phase. That's all you need. The next lesson is where we move from planning to building.

💬 Stuck? Come Talk to Us

💡

If something's not clicking or you want to share what you've built — come find us in Discord.
Build What Ships community → https://discord.gg/RFXRf9yg
Drop your question in the right channel. The community's active and I check in there too.

Glossary

Implementation Roadmap: A phased, sprint-based delivery plan that translates the Feature Priority Matrix into a concrete build order — with capacity constraints, design pipeline, risk register, and release checkpoints. Saved as .project/implementation-roadmap.md. (first introduced in Module 3, Lesson 5)

Sprint: A fixed two-week development cycle. Each sprint has a defined set of stories to build, a capacity constraint (person-days available), and a set of dependencies that must be met before the sprint starts. (first introduced in Module 3, Lesson 5)

Design-Dev Pipeline: The practice of keeping design work at least one sprint ahead of development. Design deliverables (Figma files with approved UI/UX) must be complete before a story enters a dev sprint. (first introduced in Module 3, Lesson 5)

Release Checkpoint: A defined point at the end of each phase where the work completed so far is shippable to real users. Not just "code complete" — something a user can actually get value from. (first introduced in Module 3, Lesson 5)

Risk Register: A table of identified risks, each with a likelihood rating, an impact rating, and a mitigation strategy. Included in the implementation roadmap to surface known risks before they become problems. (first introduced in Module 3, Lesson 5)

Person-Days: The unit of development capacity used in sprint planning. Calculated as: number of developers × working days per sprint. Determines how many stories can fit in a given sprint. (first introduced in Module 3, Lesson 5)