Final assignment

What you will be able to do

Bring the whole course together in one document: an AI product and team plan for one use case that you know. It says which problem you solve and what it is worth, and how you get the AI. It says how you plan and judge the work, how people use it, who does what, and how you launch it safely. A leader can hand this plan to a sponsor, a team or a reviewer.

Before you startWhat to know and to have readyAbout 180 minutes

What you need to know

• Modules 1 to 6. Each part below names the lessons that it uses.
• At least one case study is helpful: each one is a smaller version of a part of this plan.

What you need

• A browser and a document tool. No account, no installation and no money.
• The plan template templates/ai-product-and-team-plan.md, copied into your document. It has one section for each part below, and the reviewer’s list at the end.
• The other templates that each section names, in the same templates/ folder. You used all of them in the module practices.
• Three to six pages is enough. A short plan with evidence beats a long plan without it.

Choose your use case

Choose one use case from your own field, or from a field that you know well. It needs a real user, a task or decision that the AI changes, and a mistake that costs something. Your own work is the best choice, because you know its numbers and its people.

If you have no use case of your own, choose card 3, 5, 6, 7 or 8 in evidence/use-case-cards.md. Do not choose cards 1, 2 and 4: the lessons and the case studies already worked on them. Add the facts that the card does not give as labelled assumptions.

You have seen every part of this plan once, for Larkfield’s support reply assistant. Now you do it for your own case, and the decisions are yours.

Label every number. Use the four labels of Read the evidence pack: recorded, price, assumption or constructed. In your own field, most numbers start as assumptions. That is fine, if each one has a label, a low / base / high range and a plan to measure it.

Part 1: the problem and its value

Uses Problems before tools, What AI does well and badly and Estimate value and return.

1. Write the use case: the user, the task or decision, the outcome that you want to improve and the cost of a mistake. Then write the baseline: how the work is done today.
2. Run the use-case screen. Name the cheaper fix that you considered (a rule, a report, a form or a process change), and say why it is not enough.
3. Fill the value estimate: volume, the share where the tool helps, adoption, time saved after review, the cost of an hour, the cost of mistakes, model and upkeep costs. Give the net value as low, base and high.
4. Name the assumption that changes the value most, as in Which assumption matters most?, and how you will measure it.

Part 2: build, buy or partner

Uses Build, buy or partner, Choose vendors and models as a leader and Run a fair pilot.

1. List at least two options. Today’s way counts as one of them.
2. In the vendor comparison, write the criteria, their weights and the must-haves before you score. Include the data terms and how you leave.
3. Score each option, with the evidence for each score. A demo or a vendor’s own claim is a claim, not evidence.
4. Write the fair trial in the pilot plan: the same examples for every option, the criteria and the decision date, all fixed before the start.
5. Write the decision. If the trial has not run yet, make the decision depend on it: “buy B if it passes the trial; otherwise build A”.

Part 3: roadmap and definition of done

Uses Why AI plans are different, Milestones and roadmaps and Define done with evidence.

1. In the stage-gate roadmap, plan four stages: feasibility, pilot, limited launch and full launch. Give each one a time box, the question that it answers and the evidence to pass.
2. Write the result that stops the work at every gate. “Stop” must be a real option.
3. In the definition of done, name the evaluation set, the acceptance thresholds with their numbers, the blockers, the number of runs and the one owner who signs.

Part 4: human review and adoption

Uses Human review by design, Earn user trust and Change and adoption.

1. Choose the autonomy level in the autonomy ladder. Justify it with the two costs: the cost of review and the cost of a mistake. Say what evidence would let you move one level up.
2. Fill the human-review canvas: who reviews, what they see, how they report an error, the signs of too much and too little trust, and what always goes to a person.
3. Write the adoption plan for the first group of users. Put the outcome measure first, with its baseline. Usage alone is not success.

Part 5: the team

Uses Team roles by stage, Hire and grow skills, Review work you cannot write yourself and Team rituals and AI-assisted work. For the team’s weekly rhythm, on-call and growth, see also Run an AI team day to day and Grow and keep AI specialists.

1. Fill the role map for all four stages. Put one person who decides in each stage. Keep the person who builds a change apart from the person who evaluates it.
2. Name one role that is missing, and say whether you hire, grow or borrow it, and why.
3. Say how you review work that you cannot write yourself: which lines of the experiment-review checklist you always ask for, and the team’s rhythm of reviews.
4. Write the team’s policy for AI-assisted development: what assistants may do, what a person must check, and who owns the result.

Part 6: risk and launch

Uses Risk at leadership level, Governance in practice and Launch and after.

1. Write the risk register: five to ten risks, each written as who could be harmed and how. Rate impact and likelihood, and give each risk one owner who is a person.
2. Name one risk that you cannot remove, and say why launching with it is or is not acceptable.
3. Set the approval level of the launch from the register’s scores. Say whether you need a privacy or legal specialist, and when.
4. Fill the launch checklist: the rollout steps, at most five signals with at least one about the outcome, and at least two pause conditions. For each condition, write the normal value, the line and who may act alone.

Check your work

A reviewer marks each required item demonstrated, partially demonstrated or not yet demonstrated, with a concrete reason. To complete the course, all six must be demonstrated. You can improve an item and send it again. If no reviewer is available to you, use the same table on your own plan, or ask a colleague to use it.

Required item	Demonstrated when	Partially demonstrated, for example	Not yet demonstrated, for example
1. A use case with a value range and its main assumptions, and the reason AI is the right tool	The range has low, base and high. Every input has a label. The biggest assumption is named. A simpler fix was considered.	The range is there, but some inputs have no label, or the biggest assumption is not named.	One value with no range. Or “AI” is the goal, and no simpler fix was considered.
2. A build, buy or partner decision tied to stated criteria and trial evidence	The criteria were written before scoring. Every option is judged on the same evidence. A demo alone is not the evidence.	The criteria are clear, but one option is judged on its own claims. Or the trial is not designed.	The decision rests on a demo or a price list, with no criteria.
3. A stage-gate roadmap with acceptance thresholds and stop criteria	Every gate has the evidence to pass and a result that stops the work. Thresholds are numbers on a named set, with an owner.	The gates are there, but one has no stop result, or a threshold has no number.	Fixed dates with no gates. Or “the team is happy with the answers” as the definition of done.
4. A human-review and adoption design with a justified level of autonomy	The level is justified with the cost of a mistake and the cost of review. The adoption plan measures an outcome, not only usage.	The level is chosen, but only one of the two costs is counted. Or the outcome measure has no baseline.	No level is chosen. Or success is measured by usage only.
5. A team plan with roles, review practices and an AI-assisted development policy	One person decides at each stage. The review questions work without code. The policy says who owns the result.	The role map has two deciders at one stage. Or the policy has values (“use assistants responsibly”), not checks.	No role map. Or the person who builds a change also judges it, and nobody else reads the evidence.
6. A risk register with owners, and launch and pause conditions	Every high-impact risk has an owner. Pause conditions are written. A person can correct the AI where a mistake causes harm.	The register is there, but one risk is owned by a team, not a person. Or a pause condition says nobody may act on it alone.	No register. Or no pause condition.

Not accepted: a plan that launches without an owner for a high-impact risk, or without a way for a person to correct the AI where a mistake causes harm. Such a plan is “not yet demonstrated” on item 6, however strong the rest is.

Every claim in the plan must point to evidence or carry the label “assumption”. Check the sums in your value estimate and your costs again. A reviewer checks that the numbers add up, and that you can explain each decision.

AI assistants

You can use an AI assistant to check your spelling, to ask you hard questions about your plan, or to suggest risks that you missed. The decisions and the evidence must be yours. Check every suggestion, and say in the plan which decisions you made. An assistant does not know your users, your numbers or your team.

Common mistake

A plan that hides its assumptions

Symptom: the plan says “the assistant will save US$400,000 a year” and “the model is 95% accurate”. The numbers have no label and no range, and the reviewer cannot tell where they come from.

Cause: the learner wrote the plan as a sales pitch. Each number looks stronger without its label, so the labels were left out.

Fix: go back to Part 1. Give every number its label and its low / base / high range. Name the assumption that changes the value most, and plan how to measure it before the pilot gate. A plan with honest ranges is easier to approve, because the reader can see what is known.

Common mistake

A plan with no way to stop

Symptom: every gate in the roadmap has the evidence to pass, but no result that stops the work. The risk register has no pause conditions.

Cause: the plan was written to get approval for the whole project at once.

Fix: for each gate, write the result that would make you stop or change the work, before anyone sees a result. Then write at least two pause conditions, with who may act alone. The stalled project in Recover a stalled AI project shows where a plan without stop results ends.

Recap

In this course, you learned to lead AI work without writing its code:

• Decide where AI helps: start from a use case and a baseline, try the cheapest fix first, and give the value as a range with labelled assumptions.
• Decide how to get it: build, buy or partner on criteria written first, and judge every option with a fair trial on your own examples, not a demo.
• Plan under uncertainty: experiments with a time limit, stage gates with stop results, and a definition of done with thresholds and one owner.
• Design for people: an autonomy level justified by two costs, trust that matches the AI’s real quality, and adoption measured by the outcome.
• Run the team: one person who decides at each stage, a builder who does not judge their own work, reviews from the evidence, and a policy for AI-assisted work.
• Launch responsibly: a risk register with owners, approvals in proportion to the risk, a staged rollout and pause conditions written before the launch.

Keep your plan up to date as the work moves through the gates. Measure the biggest assumption first, and write each hard-to-undo decision in a decision record.