Track · Product skills

Roadmapping and epics

Write epics by hand, order them with reasons, keep the plan in git and cut the first epic into milestones that AI agents can build from.

In short

This track is for you if you have done discovery and need a plan. People write epics and roadmaps. AI never does. You will write each epic yourself. It has a problem, a person, an outcome and a measure. You will order the epics and write one reason for each place. You will keep the plan in git, on a free GitLab account. Then you will split the first epic into three to five milestones.

Agents can build from those milestones. You check their work against acceptance criteria that you wrote first. You decide the scope, and you can defend it. A reviewer may ask you to explain every epic out loud.

Key words

  • Epic: A whole-product outcome across several repos. Weeks to months. Written by a human.
  • Roadmap: Epics laid out in order over time.
  • Milestone: A time-boxed slice of work with a goal and a date.
  • Issue: One task. One agent can finish it in one merge request.
  • Acceptance criteria: Checks that prove an issue or epic is done. A person must be able to test each one.

This is the heart of the Dojo. A roadmap is the plan for the whole product, and the epic is the unit of that plan. If you learn only one craft in the program, learn this one. Everything agents build starts from what you write here.

Who this track is for

This track is for you if you have done discovery and written personas and journeys, and now need to turn that learning into a plan. It follows the personas and journeys track and uses the list of breaks you produced there.

The rule that shapes this track

People write epics and roadmaps. AI never does. This rule is not about fear of technology. It is about where the value of a plan comes from. A roadmap rests on facts no prompt contains: what a customer said last week, what sales promised, how much money is left, what another team plans. It also forces you to decide what is in scope, what is out and what you will refuse to do. If a model writes it, you skip the thinking and you cannot defend the result. Agents also agree too easily, and planning is exactly where a wrong idea should be stopped.

What agents can do is everything around and below the plan: they can check your epic for vague words, ask you hard questions, break a milestone you wrote into issues, build those issues, and report back. The art of this track is to write epics and milestones precise enough that agents can build from them without guessing.

What you will be able to do

After the five lessons you will be able to:

  • Explain the four levels of planning (vision, epic, milestone, issue) and which of them you own.
  • Write an epic with a problem, a person, an outcome, a measure, what is in and out of scope, the parts of the product touched, dependencies, risks and an owner.
  • Choose and explain an ordering method, and write why each epic comes before the next.
  • Keep the plan in git using issues, milestones, labels and boards on the free GitLab plan, and know what the paid epics feature adds.
  • Turn the first epic into three to five milestones with dates, and then into agent-ready work.

How the five lessons build

  1. What an epic is. The four levels and the size tests.
  2. Write an epic yourself. The template, line by line, and how to write a measure.
  3. Order the epics. Value, risk and dependency, and how to defend your order.
  4. Your roadmap in git. Free-plan GitLab practice, labels, boards and the roadmap view.
  5. Agent-ready milestones. How to hand a milestone to an agent, review the result and keep the decision log.

Each lesson follows the same shape as the rest of the Dojo’s tracks: why it matters, key ideas, step by step, a worked example with the fictional product TrailMug, working with AI agents, common mistakes, a practice exercise ending in a file in your repo, a checklist and links to free outside learning.

The 2030 Product Development Manager at work

At this level the manager is a strategist and a specifier. You decide which outcomes the whole product must deliver and in what order. You write the specification so clearly that several agents can work in parallel without colliding. You judge their output against acceptance checks you wrote beforehand. You manage the risks that cross repos: two agents that name a field differently, a service that is built but never connected, a promise on the website the app cannot yet keep.

Several disciplines meet in an epic. Finance asks what it costs and what it earns. Operations asks who runs it. Security and privacy ask what data it touches. Design asks what the person will see. Sales and support ask what they must tell customers. A good epic has a line for each of these, even if the answer is “not affected”.

How it maps to the Dojo

  • Developer, week 3: Problems to epics. Lessons 1 to 4 are the long form of week 3: list the gaps, write 4 to 8 epics, order them, put them in git and cut the first one into milestones.
  • Developer, week 4: Defend the roadmap. Lesson 5 supports agent-ready epics and the weekly rhythm. The stakeholder communication track covers the defence itself.
  • Master Developer. Your roadmap and your evidence of complete epic management are central to the Product Package, and the Master Developer review asks you to explain every epic out loud, without notes.

Time needed

Plan about three hours per lesson. The writing is slow on purpose. A good epic takes an hour or more to write, because the thinking is the work. Spread the track across about two weeks, and leave a day between writing and reviewing, because you will see your own mistakes more clearly after a night’s sleep.

What you will keep

You will have a roadmap of four to eight epics in your repo, each written by you, a written order with reasons, a live GitLab plan, and one epic cut into milestones ready for agents. This folder is the strongest evidence you can bring to a coach, a panel or an employer.

Lessons

Lessons in order

You mark a lesson done at the end of the lesson. This is saved only in this browser, on this device. It is not a grade and not a certificate.

  1. What an epic is, and what it is notCore2 hours

    Learn the four levels of planning, why an epic is not just a big issue, and three size tests that tell an epic from a milestone or an issue.

  2. Write an epic yourselfCore3 hours

    Write a complete epic by hand, line by line: the person, the problem, a measurable outcome, scope in and out, the parts touched, dependencies, risks and an owner.

  3. Order the epics and defend the orderCore2.5 hours

    Order your epics by value, risk and dependency, write one sentence of reasoning for each position, choose a prioritisation method on purpose and say what you chose not to do.

  4. Your roadmap in gitCore3 hours

    Run the whole roadmap on a free GitLab account with issues, milestones, labels and boards, keep a plain-text copy in the repo and know what the paid epics feature would add.

  5. Agent-ready milestonesCore3 hours

    Cut your first epic into milestones with acceptance checks a person can test, hand a milestone to an agent with a written brief, review the result and keep a decision log.

All tracks · Learning resources