Decision-making

In short

This track is for people who must make many smaller choices inside each epic. You do not need to code. You will write a problem statement with an owner and a deadline. You will list the people who decide, advise or are affected. You will compare options, including doing nothing, against criteria you wrote first. You will record the trade-off you accept.

Agents can find options and build a table for you. You keep a log of what you used and what you threw away. The agent never decides. You decide, and you write down why. On the agent ladder, you move from use to delegate. Orchestration starts when several agents each argue one option.

Key words

• Problem statement: A short text that says who has a problem and why it matters. It also says how you will know it is solved.
• Stakeholder: A person or group affected by the product or able to affect it.
• Decision record: A short file for one decision: the options, the choice and the reasons. It also names the day to look again.
• Decision log: A dated list of decisions with the question, answer, reason and name.
• 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 2030 Product Development Manager is paid to decide. Agents can write code, draft research and build a comparison table in minutes. They cannot be accountable for the choice. When a product has to pick a payment model, a first market, a partner or a tool, one person must say “we do this, and not that”, and write down why. This track trains that skill.

Who this track is for

This track is for you if you have framed a product idea and started a roadmap, and you now face the next layer: the many smaller decisions that sit inside every epic. It suits juniors who have never had to defend a choice, career changers who are used to being told what to do, and experienced developers who now direct agents and must decide what to ask them for.

You do not need to code. You need to write plain sentences, talk to the people affected and accept that a decision can be wrong. The aim is not to make perfect choices. The aim is to make choices that are clear, checked and easy to review later.

The rule that shapes this track

The agent never decides. An agent can find options you missed, collect public facts, build a table from criteria you wrote and argue against your favourite idea. It cannot know what your customer said last week, what your budget really is or what you are willing to give up. It also tends to agree with you. So the decision, its reasons and its signature stay human. This is the same idea as the Dojo rule that people write epics and roadmaps, applied to the choices that shape them.

What you will be able to do

After the four lessons you will be able to:

• Turn a vague worry (“we need to sort out payments”) into a decision with an owner, a deadline and a clear problem statement.
• Tell a symptom from a cause, and a problem from a solution.
• List the people who decide, advise, are affected and can block, and ask each of them better questions.
• Sort what you know, what you believe and what you do not know, and decide how much more learning is worth the time.
• Compare options, including “do nothing”, against criteria you wrote before you looked at the options.
• Write a decision record: the context, the options, the decision, the trade-off, the risks and the day you will look again.
• Brief an agent with an exact written task, read what it returns with suspicion and keep an honest log of what you used and what you threw away.

How the four lessons build

1. Frame the problem. One problem statement, one decision, one owner, one deadline, and a test for “solved”.
2. Ask better questions. Stakeholders, assumptions and unknowns, and how to stop asking.
3. Compare options and write the trade-off down. Criteria, options, second-order effects and the decision record.
4. Decide with agents. The brief, the checks and the line between help and decision.

The lessons use one running decision from the fictional product TrailMug: how partner cafés are rewarded for washing and handing out reusable cups. You will build one folder of files for your own decision, one lesson at a time, so that at the end you hold a complete trail from problem to record.

The 2030 Product Development Manager at work

At this level the manager is a framer and a judge. You decide what question is worth answering and what is not. You decide who must be heard before the choice. You write the criteria, so the comparison measures what matters to your product. You delegate the legwork to agents with a written brief, and you verify the output yourself. Then you decide, and you sign.

Many disciplines meet in a decision. Finance asks what each option costs and what it earns. Operations asks who will run it on a busy day. Legal and security ask what rules and data are involved. Design and support ask what the person will experience and what they will have to explain. A good decision record has a line for each of them, even when the line says “not affected”.

How it maps to the Dojo

• Developer, week 3: Problems to epics. The lessons give you the habit behind every epic: a clear problem, a stated measure and a written order. See week 3.
• Developer, week 4: Defend the roadmap. A decision record is the best answer to “why did you choose this?” The stakeholder communication track covers the defence out loud.
• Master Developer. The decision record template is part of the Track B work and the capstone. This track teaches the thinking behind it for product decisions, before you use the longer open source form.
• Assessment. A reviewer looks for reasoning made visible: problem statements, questions, trade-off notes and decision records, revised after feedback. Your folder of files is that evidence.

Where it sits on the agent ladder

The agent skill is a ladder: use one agent, delegate a whole task with a written brief, orchestrate several sessions, govern them with written policy and gates. Lessons 1 and 2 are on the use rung. Lesson 3 moves toward delegate. Lesson 4 is firmly delegate, and it shows where orchestration begins (several agents, each arguing one option) and what governance keeps it safe (a rule that only a named person can mark a decision accepted).

Time needed

Plan about two to three hours per lesson, including the exercise. The reading is short. The writing and the conversations take time. Spread the track across about two weeks, and leave a night between writing a decision and reviewing it. You will see your own gaps more clearly the next morning.

What you will keep

You will have a folder in your git repository with a problem statement, a question list, an options table, a decision record and the agent brief and review notes that went with it. It is small, readable evidence of how you think, and it is what a coach, a panel or an employer can read in ten minutes.