In short
This track is for you if you must explain a roadmap to other people. They may have money, power or opinions. You will map who is affected, what they want and what they fear. You will write a one-page brief and a short regular note. You will present and defend your roadmap in ten minutes. You will learn to say no, report risk and give bad news in writing.
Agents can draft messages. You decide what is sent, and you answer for it. You also say plainly where agents helped and where people decided. On the agent ladder, the governing rule is simple. No outside message goes out until a person has read it.
Key words
- Stakeholder: A person or group affected by the product or able to affect it.
- Roadmap: Epics laid out in order over time.
- Decision log: A dated list of decisions with the question, answer, reason and name.
- AI disclosure: A plain line that says where AI helped with a piece of work. It goes in the README or the merge request.
- Agent ladder: Four rungs of skill with AI agents: use, delegate, orchestrate and govern. Each rung needs different skills.
A product is never built for one person. Customers, partners, sponsors, advisers, colleagues and the people and agents who build all affect it, and all are affected by it. Most products that fail with good code fail in the gaps between these people: a partner who was never told, a sponsor who was surprised, a rule nobody checked.
This track teaches the part of product management that looks soft and is not. You will write things down clearly, show your reasoning and make it easy for the right person to say yes, no or “not like that” early, when the answer is cheap.
Who this track is for
You have a roadmap, or an early version, and you now have to explain it to people who have money, power or opinions. It follows the roadmapping and epics track and supports week 4 of the Dojo program: the roadmap defence. It is also useful if you are good at building and find meetings draining. Writing well is a way to need fewer of them.
The rule that shapes this track
Write it down, and write it for the reader. The Dojo asks for decisions and plans in git, in plain words. Written communication scales: it reaches people in other time zones, it can be checked later and it can be read by agents. A person who must ask you what you meant is a person you failed to write for.
A second rule: no surprises. People forgive a delay they hear about early. They do not forgive a delay they find out about at the deadline.
What changes when agents do the building
Three effects make this track more important, not less.
- Speed raises the cost of misunderstanding. An agent can build the wrong thing in an afternoon. A sponsor who disagrees with the order of epics should find out before, not after.
- Others will ask what agents did. Customers, partners and regulators increasingly ask whether AI was involved. You need a plain, honest answer, in writing.
- Agents can draft; people must own. An agent can turn your notes into a first draft of a message. It cannot know what your sponsor fears, what a partner was promised last week or what is safe to say. You decide what is sent, and you answer for it.
The four lessons
- Map the stakeholders. Who is affected, what they want and fear and what they can decide.
- Write the one-pager and the weekly note. Short written communication that keeps people aligned.
- Present and defend the roadmap. Ten minutes, an order, risks and a not-doing list.
- Say no, report risk and deliver bad news. Requests, trade-offs, risk statements and honest disclosure.
Each lesson follows the same shape as the rest of the Dojo: why it matters, key ideas, steps, a worked example with the fictional product TrailMug, working with AI agents, common mistakes, a practice exercise that ends in a file in your repo, a checklist and links to free outside learning.
The 2030 Product Development Manager at work
The manager decides who needs to know what, when, and in what form. The manager delegates drafting, summarising and scheduling to agents with a brief, and verifies that every message is true, kind and complete before it goes out. The manager is the one person who can say “I decided this, and here is why”.
Many disciplines meet in a stakeholder table. Finance wants cost and runway. Legal and privacy want obligations met before launch. Sales and support want to know what to promise and what to say when things break. Engineering wants clear work. Operations wants to know what it will have to run. Design wants to know what people will see. A strong manager can speak to each in the words that discipline uses.
Each lesson places its work on the agent ladder: use one agent, delegate whole tasks with a brief, orchestrate several sessions, and govern them with written policy, hooks and gates. The agent orchestration track covers the upper rungs. In communication, the governing rules are the ones that say what an agent may send on your behalf. The answer for external messages is: nothing, without a person reading it first.
How it maps to the Dojo
- Developer, week 4: Defend the roadmap. Lessons 1 to 3 are the long form: the stakeholder table, the weekly note and the ten-minute roadmap presentation.
- Developer, weeks 5 and 6. Lesson 2 supports the demo and the package, which must be understandable by people who were not there.
- Master Developer. Your decision log, your risk statements and your honest AI-use disclosures are evidence the panel will ask about.
Time needed
Plan about two to three hours per lesson. Most of the time goes to writing and rewriting. Practise the presentation aloud at least three times.
What you will keep
A stakeholder table, a one-page brief, four weeks of short notes, a ten-minute roadmap presentation with a recorded Q&A, a risk list with owners and a short, honest statement about how you use AI. These are the documents a sponsor, a partner or a panel will actually read.
