In short
This track is for you if others will help you deliver a roadmap. Some of them may be people. Some may be AI agents. You will write a one-page direction and a short set of working agreements. You will say who decides what. You will give feedback by describing what happened. You will learn to receive feedback without defending yourself. You will write briefs for agents and review their work against written checks.
You can hand work to an agent. You cannot give away responsibility. One named person answers for the result. On the agent ladder, you start with use and delegate. A team of people and agents reaches orchestrate and govern.
Key words
- Working agreements: A short written set of rules for how a team works together.
- Brief: A written task for an AI agent, with its goal, limits and checks.
- AI agent: An AI coding assistant that reads your project and builds tasks. It does the task in front of it. It does not own the plan.
- Agent ladder: Four rungs of skill with AI agents: use, delegate, orchestrate and govern. Each rung needs different skills.
A Product Development Manager (PDM) rarely works alone. Sooner or later you lead a few people: a designer, someone in support, a part-time engineer, a mentor who gives you an hour a week. You also lead AI agents, which write drafts, code, tests and summaries all day. Both groups need the same things from you: a clear direction, clear expectations, honest feedback and someone who answers for the result.
This track is about those four things. It is not about being a charismatic boss. It is about writing and speaking clearly enough that other workers, human or not, can do good work without you standing over them.
Who this track is for
You have a roadmap, or you are building one, and you are about to ask others to help you deliver it. It follows the roadmapping and epics track and the stakeholder communication track. It also supports week 4 of the Developer path, where you explain your plan to other people, and the Master Developer review, where a panel asks how you would lead a team. If you work alone today, the track still helps: you lead your agents, and you will lead people soon.
About the sources
This track is built from free outside material that we opened and checked, and from the Dojo’s own rules. The Curiosity leadership guide repository is, today, an empty stub: it holds a title and nothing else. So no text from it was used, and this track does not claim to continue it. Every idea here is written in our own words. When we rely on a publisher’s research or guide, the lesson says so and points to it in the further learning list. Where a source describes one company’s own data, we say that it is one company’s data.
The rule that shapes this track
The person who owns the outcome stays a person. You can hand work to an agent, and you can hand work to a colleague. You cannot hand over the answer to the question “who is responsible for this?” Every lesson in the track comes back to that rule, and to the habit that makes it possible: write things down so that the right person can check them.
The three lessons
- Set direction and written expectations. A one-page direction, goals with a way to check them, working agreements and a clear owner for each decision.
- Give and receive feedback. Describe the situation, the behaviour and the effect. Run a one-to-one. Hear feedback without arguing, and decide what to do with it.
- Run a team of people and agents. Brief, review and account for agent work next to human work, and decide when a team needs more than a brief.
Each lesson has 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 repository, a checklist and links to free outside learning.
The 2030 Product Development Manager at work
The PDM decides the direction, the priorities, who owns each decision and what “good enough” means. The PDM delegates drafting, summarising, reminders and routine checks to agents, each with a written brief. The PDM verifies by reading the work against the written checks, asking the people involved and looking at real results. The PDM answers for all of it.
Leadership is also a place where many disciplines meet. Finance wants to know the cost of a team and of a delay. Operations wants to know who is on call and what happens when someone is away. Security and privacy want to know who may see what, and which data an agent may touch. Design and engineering want to know where their judgement is wanted and where it is not. Brand and marketing want to know who may speak for the product. A leader who can name these needs, and write the rule that serves them, is easier to follow.
Each lesson also places its work on the ladder for working with agents: use one agent for one task, delegate a whole task with a written brief, orchestrate several agent sessions at the same time, and govern them with written policy and gates, so that the work stays safe without you watching every step. Direction and feedback are mostly about the first two rungs. Running a mixed team reaches into the third and the fourth, because you will need rules that hold when you are not in the room.
How it maps to the Dojo
- Developer, week 4. Lesson 1 helps you explain the plan so that others can act on it.
- Developer, weeks 5 and 6. Lessons 2 and 3 help when you ask a friend, a mentor or an agent to review your demo and package.
- Master Developer. The decision rights page, the working agreements and the record of your own review habits are evidence a panel can read.
Time needed
Plan about two to three hours per lesson. The writing is short. The slow part is thinking about real people and testing your pages on them.
What you will keep
A one-page direction, a goal with checks, a working-agreements page, a decision-rights table, a written piece of feedback in the situation-behaviour-impact form, a one-to-one agenda, a brief for an agent and a review log, and a short team page that says who is accountable for what. All of them live in your git repository, where a sponsor, a mentor or a panel can read them.
