Present and defend the roadmap

Supports: Developer, week 4 (Defend the roadmap), Part 1: the 10-minute roadmap presentation. Time: about three hours, plus practice.

1. Why this matters

A roadmap that cannot be defended will not survive its first meeting. A sponsor asks, “Why this first?” A partner asks, “When will it reach us?” An engineer asks, “What if that dependency slips?” If you answer with a shrug or with a speech, you lose trust. If you answer with one clear sentence and a source, you gain it.

The defence is not a performance. It is an honest test of your plan, in front of people who see things you cannot. The best outcome of a roadmap review is sometimes a change of order. A manager who changes the plan because a good objection was raised is stronger than one who defends a mistake.

For a Product Development Manager (PDM) the review is where the planning craft meets the people. Your epics, the order, the reasons, the risks and the not-doing list are all in lessons you have already done. Here you learn to present them in ten minutes and take the questions.

What the PDM decides here

You decide	You may delegate to an agent	You verify	Other disciplines involved
The audience, what to show, what to cut, how you answer, what you change afterwards	Slide layout; a first list of hard questions; a timing check; a check that every number matches the roadmap file	Every claim matches roadmap/; you can answer the hardest question without notes; changes are recorded	Finance (cost, cash), legal and privacy (gates), sales and support (promises), engineering (feasibility), operations (running it)

2. Key ideas

Know the audience

Atlassian’s tips for presenting product roadmaps advise adapting the roadmap to the audience. Executives want outcomes, risks and money. Engineers want dependencies and clarity. Sales and support want what they can promise. Customers and partners want what is in it for them and when. Write the audience at the top of your notes. Decide what they need to decide or do after the meeting.

The ten-minute shape

Ten minutes is short on purpose. A shape that works:

Minutes	Content
1	The product, the person and the goal, in two sentences
3	The roadmap picture: now, next, later, one reason per epic
2	The top three risks, each with an owner
1	What you chose not to do, and why
1	What you need from this audience
2	Questions (or more, if you have time)

Atlassian’s roadmap guide and the NN/g video on UX roadmaps both describe roadmaps as communication tools that show direction, not fixed promises. Use now, next, later, with real dates only for the near term.

One reason per epic

For each epic, say one sentence beginning “This comes before the next because…”. You wrote these in the ordering lesson. If you cannot say it without notes, you do not own it yet.

Risks, said plainly

NN/g’s video on risk statements describes a way to state risk so that business people can weigh it: a clear statement of what might happen, how likely, and what it would cost. A risk statement in the Dojo has four parts: what could happen, how likely (low, medium, high, with a reason), what it would cost and what you will do, with an owner.

Do not hide risks to look confident. A visible risk with an owner reads as control. A hidden one reads as luck.

The not-doing list

Show it. It proves that you made choices. It also gives people a chance to tell you if you cut something important. “Loyalty points: no evidence in interviews” invites an answer. If somebody gives you evidence, change the roadmap.

Prioritisation, as a tool for the argument

If someone challenges your order, a clear method helps. Atlassian’s guide to prioritisation frameworks lists several. You do not need to show a scoring table in a ten-minute talk. Have it ready for the question “How did you decide?”. Say the method, your inputs and where they were guesses.

Answering hard questions

Four moves cover most questions.

1. Listen to the whole question. Restate it in a short sentence.
2. Answer in one sentence first, then give the reason.
3. If you do not know, say so, and say when you will find out and how you will tell them. “I do not know yet. I will have it by Friday” beats a confident invention.
4. If the question changes your mind, say it. “That changes my view. I will move this up and update the roadmap.”

Avoid defending out of pride. Avoid answering a question nobody asked. Avoid blaming other people or agents.

Record the challenges

Write each challenge, your answer and any change. This record is the strongest evidence that your plan was tested. Put it in roadmap/review-notes.md.

3. Step by step

Step 1: Name the audience and the ask

Write who will be in the room, what they care about and what you need them to decide or do.

Step 2: Draft the picture

One page with now, next and later. Epics as outcomes for people, one reason each, real dates only for the near term.

Step 3: Draft the risks

Top three, in four parts each, with an owner.

Step 4: Draft the not-doing list

Three to five items with the reason.

Step 5: Write the speaking notes

For each part, write two or three sentences, not a script. Say them aloud. Cut what you stumble on.

Step 6: List the hard questions

Write ten questions you hope nobody asks. Write your answer to each. Mark the ones where you would say “I do not know yet”.

Step 7: Practise aloud, three times

Time it. Ask a friend to interrupt with the hard questions. Change what does not work.

Step 8: Present

Present to real people if you can: a mentor, a colleague, a coach. Ask someone to take notes of the challenges.

Step 9: Record and act

Within a day, write the challenges, your answers and the changes. Update the roadmap, the decision log and the stakeholder table. Send a thank-you note with the changes.

4. Worked example: TrailMug

TrailMug is fictional. The audience is the mentor and the privacy adviser. The ask: “Agree the order, and confirm a privacy review slot.”

Minute 1. “TrailMug lets commuters like Maya swap a used cup for a clean one at partner cafés in under a minute, without slowing down cafés like Leo’s.”

Minutes 2 to 4. The roadmap picture: now: lawful and honest, café partners. Next: price, sign-up and pay, welcome email. Later: status page. For each, one sentence of reason. “Lawful and honest comes first because nothing that collects emails or money can start without it, and two other epics depend on it.”

Minutes 5 to 6. Risks. Example: “If the privacy notice is not live by 1 December, sign-up cannot open. That is medium likelihood, because the review slot is not yet booked. The cost is a month’s delay. I will book the slot this week. Owner: me.”

Minute 7. Not doing: “Loyalty points, because no interviewee asked. Event catering, because it is outside our focus. A barista app, until swaps are proven.”

Minute 8. The ask.

Questions.

• Mentor: “Why café partners before price? Without a price you cannot learn whether people pay.” The founder answered: “Without cafés there is nothing to pay for. But you are right that I am guessing about willingness to pay. I will add a small price test to the two-café trial.”
• Privacy adviser: “What data does the sign-up collect?” The founder knew: café name, address and a contact. She said she had a table in the repo and would send it.
• Mentor: “What if the supplier doubles prices?” She did not know. “I do not know yet. I will call two backup suppliers by 20 November and write you what I find.”

Recorded changes. The price test was added to the first milestone. The data table was sent. The supplier risk became the fourth risk. The roadmap and decision log were updated the same day.

5. Working with AI agents on this

Delegate:

• A hard-question list. “Play a sceptical sponsor. From this roadmap, list the fifteen hardest questions in order of how much they would hurt. Do not answer them.”
• A role-play session. “Ask me one question at a time. After I answer, tell me in one sentence if I avoided the question. Then ask the next.”
• A consistency check. “Compare my slides with roadmap/ROADMAP.md. List any difference in title, order, date or reason.”
• A timing check. “Estimate the speaking time of these notes at 130 words per minute.”
• Layout. “Turn this table into a clean one-page slide in plain HTML.”

Do yourself:

• Choose what to show and what to cut.
• Write the reasons and the risk statements.
• Answer the questions, including “I do not know”.
• Decide what changes.

A brief you can adapt (role-play):

You are a sceptical sponsor reviewing my product roadmap. Read
roadmap/ROADMAP.md and the risk list. Ask me one hard question at a
time and wait. After each of my answers, tell me in one sentence whether
I answered the question, avoided it or bluffed. Then ask the next
question. Do not suggest changes to the roadmap. Stop after ten
questions and list the three where I was weakest.

How to check the output. The agent’s questions are generic until you give it your documents. Add the risk list, the not-doing list and the stakeholder table. Compare its “weakest answers” with how you felt. If it says you were strong where you felt weak, trust your own sense.

Warning. An agent playing a sponsor is polite and well read, but it does not know your sponsor’s history, her money or her mood. Use it for practice, not for prediction.

Where this sits on the ladder. The agent skill of a manager climbs four rungs: use one agent, delegate whole tasks with a brief, orchestrate several sessions, and govern them with written policy, hooks and gates. This lesson sits on use: you talk to one agent, and you judge every answer. The roadmap itself, once presented, becomes the standard that governs later work, because every brief points to it. The agent orchestration track covers the upper rungs.

Disclose. In roadmap/review-notes.md: “AI use: practice questions and a consistency check. The roadmap, the reasons and the answers are mine.”

6. Common mistakes

• One presentation for every audience. Name who is in the room.
• Too many slides. Ten minutes is about five.
• Hiding the risks. Show them with owners.
• Dates two years out. Use now, next, later.
• Defending out of pride. Change the plan when the argument is good.
• Bluffing. Say “I do not know yet” and give a date.
• Skipping the not-doing list. It shows you chose.
• Not recording the challenges. The record is the evidence.
• Using an agent’s questions as if they were your sponsor’s.

7. Practice: present and record

Deliverable: in your git repo:

1. roadmap/presentation.md or a one-page file in your site: the picture, reasons, three risks (four parts each), the not-doing list and your ask.
2. roadmap/speaking-notes.md: short notes for each part.
3. roadmap/hard-questions.md: ten questions and your answers, with the “I do not know yet” ones marked.
4. roadmap/review-notes.md: after you present to a real person, each challenge, your answer and what you changed.
5. An updated roadmap and decision log.
6. Your AI-use line.

Commit with a message such as Add roadmap presentation and review notes.

Check: present it within ten minutes to a person who is not a developer. Ask her to say back the order and the reason for the first epic.

Stretch: present to a second audience, such as a possible partner, and write what you changed for them.

8. Checklist

• I wrote who the audience is and what I need from them.
• The presentation fits in ten minutes.
• Each epic has one reason.
• The top three risks have four parts and an owner.
• The not-doing list is shown.
• I wrote answers to ten hard questions.
• I practised aloud three times.
• I recorded the challenges and my changes.
• I updated the roadmap and the decision log.
• I recorded my AI use.

9. Further learning

Atlassian’s tips on presenting roadmaps and its roadmap guide help you adapt to the audience. NN/g’s videos on UX roadmaps and on risk statements show how to frame direction and risk for business readers, and Atlassian’s page on prioritisation frameworks supports the question “How did you decide?”. In the next lesson you learn to say no, report risk and deliver bad news.