Prepare for the judgments each round grades, then for the questions

An AI PM loop grades a short list of judgments: whether AI fits, whether it is good enough to ship, what it costs, how it fails and who decides. Map each round to the judgment it tests, then prepare one worked case per judgment instead of memorising hundreds of questions.

LESSON 1 OF 20 · 14 MIN ESTIMATED STUDY

TL;DR: Questions vary without end, but the judgments behind them repeat. List the judgments an AI PM loop grades, map each round to them, and prepare one worked case per judgment that you can adapt on the spot. That beats memorising answers, because the follow-up questions are where loops separate candidates.

Where you are. In Read the loop. Start here if you are preparing for an AI product management loop and want a plan before you open the question bank.

The problem with preparing question by question

A question bank is useful for practice and a poor plan. Two prompts that look unrelated, "design an AI feature for expense reports" and "should our support agent issue refunds", test the same judgment underneath: when may software act without a person, and what evidence would let it? A candidate who prepared two separate answers has two scripts. A candidate who understands the judgment has one method that also handles the third prompt they never saw.

Prepare for follow-ups that change a constraint ("now legal says EU data cannot leave the region"), ask for the number behind a claim, or ask what would make you reverse your decision. Your preparation should let you revise the decision and explain what changed.

The judgments that recur

We organise preparation around seven decisions a PM owns. This is our editorial synthesis from the question bank and public employer guidance, not a published scorecard from any employer.

JudgmentThe question underneathWhere it tends to appear
FitShould this use AI at all, and which kind?Product sense, strategy
QualityIs it good enough to ship, and how do we know?Evals and launch, system design
EconomicsWhat does a successful outcome cost, and is it worth it?Metrics, strategy, system design
FailureHow does it fail, and what does the user see?UX, system design, agents
AuthorityWhat may it do without a person, and who decides?Agents, safety, governance
BuildingCan you get from idea to a tested prototype quickly?Live build rounds
OwnershipWhat did you decide, and what changed because of it?Behavioural
rendering diagram…

The mapping is loose on purpose. A system design round can probe economics, and a behavioural round often asks about a launch you stopped. What matters is that each judgment gets prepared once, deeply.

Turn the job description into a preparation brief

Do this before assigning yourself a level. Fictional posting: “Own evaluation and adoption for a document API used by finance teams.” Extract the user, product surface, decisions and evidence. Prepare a document-quality case, an adoption diagnosis and an API migration discussion. A job post suggests priorities; it does not establish the interview format.

Scope to clarifyEvidence to prepare
PM or APM owning a bounded featureUser evidence, a testable first version and a metric you can explain
Senior PM owning a product areaSeveral trade-offs across delivery, quality and commercial outcomes
Staff or lead influencing multiple teamsShared standards, dependencies and investment choices beyond one roadmap
Director managing a portfolio and peopleResource allocation, operating rhythm, hiring and accountable risk decisions

Titles vary by company. Ask the recruiter which decisions the role owns, whether people management is required, what each round assesses and which AI tools are allowed. For compensation, ask for the approved range, currency, location basis and breakdown of base, variable pay and equity; do not treat a generic salary table as your offer.

Applied PMs usually need a specific customer workflow to discuss. Platform/API PMs need developer adoption and compatibility evidence. Model or research-adjacent PMs need capability evaluation and transfer into a useful product. Integrity PMs need evidence about harmful outcomes and review effectiveness. These are preparation lenses; one job can span several.

Keep the traditional PM work visible

The AI questions still need a customer choice, a credible alternative and a business outcome. Add one plain-language question to each case: whose job changes, why would they switch, and how would you know the change helped? Evaluation depth cannot compensate for choosing a problem nobody needs solved.

Build a short employer brief with three evidence labels. Record product behavior you observed, claims from dated official sources, and your own hypotheses. If you cannot access the product, say so and use public documentation to frame questions. Do not invent a trial experience or repeat a rumored metric as fact.

As of 29 October 2026, Atlassian's employer-published PM handbook emphasizes influence, craft, outcomes and communication. Amazon's PM-T preparation guide includes segmentation, business models and metrics. These descriptions support the breadth of preparation; they do not identify the questions you will receive.

Ask what this team expects the PM to decide, who owns release approval and how customer evidence reaches the roadmap. Evaluate the role for yourself too. Working conditions, compensation and accommodations are legitimate topics to clarify with the appropriate contact.

A preparation plan built on judgments

For each judgment, prepare one worked case you know well enough to change on the fly. Use the same product for several judgments if you can, because continuity lets you answer follow-ups with real detail. Recurring examples use Ledgerline's fictional AI assistant, which categorises expenses and answers finance questions for small businesses. The closing mock switches to Tripwell, a fictional travel-expense assistant, so you can test whether your method transfers to a new product.

A two-week plan for someone with a full-time job might look like this:

DaysJudgmentOutput
1 to 2FitA one-paragraph case for or against AI in one feature, with the simpler alternative named
3 to 4QualityA launch call from a pass rate, with its interval and the failure types that block
5 to 6EconomicsCost per successful task for one feature, with the arithmetic written out
7 to 8Failure and authorityA failure-mode table and an autonomy decision for one agent action
9 to 10BuildingOne forty-minute timed build that ends in an evaluation script
11 to 12OwnershipThree stories, each with a decision, evidence and a measurable result
13 to 14Mock loopThe final mock-loop capstone, aloud, with a partner

The schedule is a suggestion. The rule underneath is not: produce an artefact for each judgment, not a feeling of familiarity.

Use company pages for emphasis, not scripts

Employers weight the judgments differently. A frontier lab may spend longer on evaluation and model behaviour; a large consumer company may probe metrics and experimentation; an AI-native startup may run a live build. Our company pages state what public sources support for each employer and mark the confidence level. Use them to decide where to spend an extra day. Do not use them, or anything else, as a list of questions a company will ask; nobody can honestly promise that.

Rehearse for the job's actual constraints

Take two postings with the same title and compare the decisions they name. A platform role that owns billing controls needs a different worked example from an application role serving disconnected field staff. Keep your shared product fundamentals, then add one case that matches the technical and commercial constraints of the vacancy.

For each case, write the promise in ordinary language: “new usage stops at this budget,” “the worker can save a draft offline,” or “this paid pilot will test a specific workflow.” List the facts that must hold for that promise to be true. This makes the follow-up concrete: change one fact and revise the promise.

Use the role-evaluation questions to investigate decision rights and support. Record unanswered questions as uncertainties, not negative facts about the company. Keep the latest recruiter instructions beside your practice plan, especially permitted AI use and which artifacts you may bring.

Do this before moving on

Pick one AI product you know well, from work or from daily use. For each of the seven judgments in the table, write one sentence stating the decision you would make about that product and one number you would need to defend it. Leave a blank where you do not know the number; those blanks are your preparation list for the rest of the course.

Check every rate and average you wrote: what is the denominator, and how would you collect it? If you cannot answer, add that measurement task to your preparation list. The quality and economics lessons show how to define those quantities; the system-design lessons connect them to failure handling.

Go deeper

Key takeaways

  • Questions vary; the judgments behind them repeat.
  • Prepare one deep worked case per judgment, not one script per question.
  • Follow-up questions are where loops separate candidates, so practise changing constraints.
  • Company pages tell you where to add emphasis, never which questions will come.

Check yourself

Answer out loud first, then reveal. Retrieving it yourself is what makes it stick; reading ours and agreeing does very little.

  1. 1Which preparation approach best survives a changed constraint in the interview?

  2. 2Name the judgment underneath 'should our support agent issue refunds?'

  3. 3What belongs in an employer research brief?

  4. 4Two AI PM roles have the same title. What should change in your preparation?

Sign in to track which lessons you have finished.