AI-native product management training starts with a decision.

Use a fictional internal knowledge assistant as the exercise. Employees struggle to find the current version of a procedure. Before choosing a model, describe the existing search and verification steps. Decide whose task you are improving, what counts as a correct answer, and how the person recognizes an outdated source. Keep confidential company material out of the exercise by using invented procedures.

The learner's first artifact is one page: the user, the difficult moment, a proposed improvement, the evidence needed to judge it, and a condition for stopping. If the proposed benefit is faster answers, include the time someone spends checking citations and correcting mistakes. Set a proposed target for the experiment and label it as a target, not a result.

Cagan names value, usability, feasibility, and business viability as distinct product risks. Use that vocabulary to separate unanswered questions. Product, design, and engineering should investigate together, with clear responsibility for the decisions. The training exercise below is our application of that framework to the fictional assistant.

Teresa Torres describes continuous discovery as a regular habit of customer contact and small research activities in pursuit of an outcome. For a training cohort, rehearse that habit through a short observation, a stated assumption, and a small test. A role-play can develop interview technique, but its invented answers cannot establish real customer demand.

Ask learners to preserve the original observation beside their interpretation. AI can help organize notes or propose competing explanations; a plausible summary still needs checking against the source. The useful discussion is what would change the decision. If every possible answer supports building the same feature, the exercise has not exposed a meaningful uncertainty.

Give the assistant an ordinary question, a question with two conflicting sources, and a request it cannot answer from its material. Write the desired behavior for each before running it. This makes the product manager's judgment concrete enough for engineering to test and for another reviewer to challenge.

Anthropic's evaluation guidance distinguishes a system's final result from what it says it did, and describes code, model, and human graders. The product manager should be able to explain which behavior each check measures. An assistant claiming it found the current procedure is not sufficient evidence that it selected the right document. Inspect the selected source and the response together.

End the exercise with a decision review. The developer demonstrates a success and a failure; the product manager explains their significance; the delivery lead identifies the next dependency. Each participant first writes an independent recommendation. Compare the reasoning, decide what to revise, and retain the rejected alternative with its explanation.

Then change one condition: the procedure owner leaves, two documents disagree, or checking takes longer than expected. Ask the product manager to update the outcome contract and recommendation. That second decision shows more than a polished first presentation because it reveals whether the learner can adapt the method when the evidence changes.

Look for assignments that connect discovery notes, acceptance examples, evaluation results, and a decision. Ask to see how feedback leads to a revision and how an individual contribution is distinguished from the team's work. A tool tutorial can strengthen one part of this chain; it should not be mistaken for the whole product management role.

LockedIn Labs' product manager path brings relevant authored lessons into a role-specific sequence. Its public tour shows how that practice can connect to a shared team mission. Use those surfaces to inspect the method and decide which capability your team should test first.