Recommended resources
The freely available resources this lesson will direct you to.
- A Day in The Life of An AI Product Manager | How You Could Transition To AI Product Managementwww.youtube.com
- How to Build AI Products by Microsoft Group Product Managerwww.youtube.com
- User Needs + Defining Success - People + AI Researchpair.withgoogle.com
- What each role does in a service teamwww.gov.uk
Good to see you again. Last lesson, you mapped how a product team moves from discovering a problem to evaluating a release. That map raises a practical question: who gets to decide what happens at each point?
Today you’ll distinguish decisions an AI Product Manager (AI PM) is accountable for from decisions that need specialist input, shared agreement, or formal approval. We’ll use the proposed support-ticket summary feature throughout. Allow about 40–45 minutes, including the resources and a short addition to your portfolio note.
Product accountability is not sole authority
A PM is typically accountable for keeping the team focused on which user problem is worth solving, what outcome matters, and which work deserves priority. That does not make the PM the sole designer, technical architect, legal reviewer, or owner of every budget decision.
The UK Government’s service-team guidance offers a useful role comparison. Its arrangements are specific to public services, so treat them as an illustration of decision boundaries rather than a universal organisation chart.
What each role does in a service team
Read the UK Government guidance to compare product and delivery accountabilities, then see what researchers, designers, and developers contribute.
Under “Product manager,” read the PM responsibilities. Under “Delivery manager,” read the delivery responsibilities. Then, under “User researcher,” continue from research through development, including the “Designer” and “Developer and frontend developer” subsections. Focus on where the PM sets direction and priority, and where others provide evidence or specialist decisions.
Your delivery-management experience is relevant to removing blockers and helping a team execute. The shift in a PM role is that a well-run delivery plan is no longer the primary test of success. If research shows that agents need a better handover template rather than generated summaries, the PM must be prepared to change the proposed work—even if the AI feature already has an attractive schedule.
It helps to separate three meanings of ownership:
- Accountability: You must ensure a decision is made and can explain its rationale. The PM is usually accountable for the product’s priorities and intended outcomes.
- Expertise: Someone has the knowledge to make or substantiate a specialist judgment. Engineers, for example, assess technical feasibility; researchers plan sound user research.
- Authority: Someone is permitted to approve a commitment or accept a risk. Funding, use of sensitive data, and release approval may sit outside the PM’s authority.
These can belong to different people for the same decision. A PM can recommend a pilot, supported by evidence, without being authorised to approve its budget or override a security objection.
What changes when the product uses AI?
An AI PM still starts with a user problem. They also have to ask whether AI adds enough value to justify its cost and failure modes. That is a product choice to lead, not a technology choice to make in isolation.
Google’s People + AI guide frames two useful questions: might a simpler approach solve the problem, and should AI automate a task or augment a person doing it?
User Needs + Defining Success - People + AI Research
Read the relevant parts of Google’s People + AI guide to see how user value and the consequences of errors shape an AI product choice.
In “Find the intersection of user needs & AI strengths,” start at the problem and AI discussion, ending in “Decide if AI adds unique value.” In “Assess automation vs. augmentation,” read from the workflow choice through “When to automate.” Finally, under “The stakes of the situation are high,” read the stakes discussion. Consider who should retain control of an escalated-ticket handover.
For our example, the PM can lead the comparison between a standard handover template and an AI-generated draft. They should bring evidence about agent needs, likely time saved, omission risks, and cost. Engineers and AI specialists assess what can be built and how reliably it might work; designers and agents help determine whether reviewing a draft is usable. The PM owns the product rationale, not the model implementation.
This short video excerpt makes that distinction concrete. Some team structures in the talk will differ from those you encounter, but the division between understanding the desired output and selecting an algorithm is useful.
How to Build AI Products by Microsoft Group Product Manager
Watch excerpts from “How to Build AI Products by Microsoft Group Product Manager,” on Product School. Listen for how the PM works with data specialists without replacing them.
Watch the specialist roles, where the speaker describes data scientists’ and data engineers’ contributions. Then watch model selection: notice that the PM clarifies the intended output and user interaction while a data scientist advises on the algorithm. You do not need to learn model names for this lesson.
There is an important qualification to “leave the model to specialists.” An AI PM need not prescribe an algorithm, but does need to help agree what performance is acceptable for the user’s task. If a draft omits an escalation decision, that error may be more consequential than a slightly awkward sentence. The team will later define how to evaluate such failures; for now, the decision boundary is the key point.
A decision map for the support-ticket feature
Imagine the team has evidence that agents spend substantial active time preparing and reviewing escalated-ticket handovers. The following map distinguishes a typical PM lead from a decision that needs another role’s expertise or authority. Exact rights vary by employer, so a new PM should confirm them rather than assume them.
| Decision | PM’s part | Essential collaborators or approvers |
|---|---|---|
| Which problem and outcome to pursue? | Lead the problem framing; propose measures such as median preparation and review time, with an omission-quality check. | Agents and user researchers provide evidence; operations and commercial stakeholders test whether the outcome matters to the business. |
| Template, AI draft, or another response? | Lead the value comparison and priority recommendation. | Design tests the workflow; engineering and AI specialists assess feasibility, reliability, and cost. |
| What should the first version do? | Prioritise a narrow scope—for example, draft summaries for a defined type of handover. | Agents and design shape review and correction; engineering decides the implementation approach and advises on effort. |
| May ticket data be used for this purpose? | Specify what data the feature needs and challenge unnecessary collection. | Data owners, privacy, security, and legal specialists assess permissions, controls, and applicable requirements; the authorised owner approves use. |
| Is a pilot ready to release? | Recommend whether the expected benefit and remaining risk justify a limited pilot. | Engineering and QA verify readiness; security and privacy specialists review relevant safeguards; the designated release or risk owner gives required approval. |
| Continue, change, or stop after the pilot? | Lead the product recommendation using usage, review time, omissions, agent feedback, and business evidence. | Researchers, analysts, operations, technical specialists, and the investment owner test the interpretation and approve commitments within their remit. |
Notice that collaboration does not mean an endless vote. A good decision has a named lead, evidence from the people who know most about the question, and clarity about any approval that cannot be delegated. Your PM responsibility is to bring the customer and business trade-off into view—and to surface an unresolved specialist objection before a decision is treated as settled.
Responsible AI adds more reasons to make these boundaries explicit. Microsoft’s diagram groups six principles alongside organisational building blocks for putting them into practice:
For ticket summaries, “privacy and security” raises questions about who can access the source tickets and drafts. “Reliability and safety” raises the risk of a missing escalation detail. “Transparency” affects whether an agent can recognise a draft as AI-generated and check it against the ticket. The PM should ensure these questions shape the product decision; relevant specialists and authorised owners determine and approve the controls within their remit. A principles diagram is a prompt for work, not proof that a feature is safe to ship.
Make a decision legible, not merely assigned
Suppose a stakeholder asks to send AI summaries automatically, without agent review, to reduce handling time further. “Who owns this?” is less useful than a short record of what must be true before anyone decides.
A PM could state the proposal and intended benefit, then ask design and research what agents need to verify; ask AI and engineering specialists how omissions will be detected and measured; and ask privacy and security specialists whether the proposed data flow is permitted. The PM can recommend retaining agent review if the time benefit of automatic sending does not justify the potential harm from an unchecked omission. If a stakeholder still wants full automation, the PM should escalate the explicit trade-off to the person authorised to accept that risk—not quietly turn it into a delivery requirement.
Add a small decision-rights note to your portfolio initiative. Spend about eight minutes recording four decisions: the problem/outcome, AI versus a simpler approach, data permission, and pilot release. For each, name (1) your proposed PM contribution, (2) the evidence or specialist input needed, and (3) who would have final authority if it is not the PM. Mark this as a proposed product approach, not a claim that you held these decision rights in your past delivery role.
Conclusion
An AI PM typically leads product direction and prioritisation: which problem matters, what outcome to seek, and which response is worth testing. They do not unilaterally choose model architecture, certify data use, or approve risks beyond their authority. Effective ownership means making the trade-off clear, gathering cross-functional evidence, and securing the right approval.
Next, you’ll use this broader view of product ownership to evaluate which AI product domains would make credible and feasible starting points for your portfolio.