> Canonical source: <https://helloaristotle.com/ai-training/product-managers/>

# AI training for product managers

Turn customer insight into better products, with AI that helps you research, prototype and keep everyone building from the same context.

[Book a free 20-minute call](<https://helloaristotle.com/contact/?from=%2Fai-training%2Fproduct-managers%2F>)

![From insight to a useful test, beside an illustrated Aristotle animal mascot.](<https://helloaristotle.com/media/commercial-artwork/pm1-960.webp>)

## Give your ideas a shorter path to real feedback.

AI can help with a product brief. It can also help you make the first version, learn from the response and carry that learning into the next decision.

### Hear the pattern behind the requests.

Bring interviews, support conversations and product data together. Have AI group the evidence, keep links to its sources and surface disagreements worth investigating.

### Put a small version in someone’s hands.

Turn an agreed product question into a clickable prototype or an MVP you can test. Learn what people do with it before committing to the full build.

### Keep the reasoning with the work.

Give design and engineering the customer problem, decisions and edge cases behind a requirement. Their questions become context the product team can use too.

## A feature request becomes a useful product test.

An illustrative example: people sign up for a team planning app, but some never invite a colleague. They ask for better onboarding. What should you actually change?

1. ### What is getting in the way?
   What AI helps prepare
   An evidence map distinguishes a reported worry about access from an untested idea that the invite button is hard to find. Each claim keeps its source.
   What you decide
   Which explanation deserves a closer look? A repeated request is a clue, not proof that one feature will solve it.
2. ### What is the smallest useful test?
   What AI helps prepare
   Two rough options: make the invitation easier to find, or show a preview of the teammate’s access. A short product brief captures the assumptions behind each.
   What you decide
   Pick the question you need answered. Decide what a useful user response would look like before building.
3. ### Can someone try it now?
   What AI helps prepare
   A simple prototype of the chosen flow, using sample data. AI helps draft the screens and a test guide so you can watch someone use it.
   What you decide
   Does the person understand the invitation? Check what they actually do, then revise the idea or stop pursuing it.
4. ### Will the next team understand why?
   What AI helps prepare
   An updated brief carries the test evidence, chosen behavior and unresolved cases, such as expired invitations or changed access, into design and engineering.
   What you decide
   Confirm the rationale and ask the team to challenge missing cases. A testable prototype still needs engineering review before release.

**The foundation for this example** A shared product workspace holds the current goals, source evidence, decisions and constraints. Approved updates go back there so the next task can use them.

You keep more than a draft PRD: a traceable path from a customer problem to a test, with the reasoning ready for the next person.

**Try this workflow yourself**

### Try it on a product question you’re already facing.

Use notes you have permission to share. Replace the brackets in this prompt with your own product, sources and constraints. A chat is enough for this first exercise; saved workflows and prototypes need the appropriate workspace and tools.

### A small fictional evidence set

- S1 · Interview: “I found Invite, but I wasn’t sure whether my colleague would see all my projects.”
- S2 · Support note: “The invitation expired. Where do I send another one?”
- S3 · Event coverage: sign-ups and sent invitations are tracked; views of the invitation controls are not.
- S4 · Product rule: a teammate sees only the shared project. The owner can resend an expired invitation.

### A brief you could challenge

- Supported observations: one interview raises access uncertainty (S1); one support note raises a resend question (S2). Neither establishes how widespread the problem is.
- Open question: do people fail to find Invite? S3 cannot answer that. Keep discoverability as a hypothesis, not a research finding.
- Possible test: show a prototype that previews what the invited teammate can access (S4). Ask a participant to predict who can see what, then observe whether they can invite someone. Decide whether that is the right question to test before building.

Hello Aristotle

### Find the product question worth testing

```
Help me investigate [product problem] for [users]. Our goal is [goal], and our constraints are [constraints]. Use only these supplied sources: [notes, feedback, data and current product rules].

Ask up to three questions if essential context is missing. Separate observations from interpretations. For each pattern, cite the source and flag contradictory or missing evidence. Do not invent user quotes, counts or causes.

Suggest two plausible explanations and one small test that could distinguish them. For the test, describe the smallest prototype, the behavior to observe, and what would make us reconsider. Include relevant access and failure cases.

Finish with a short decision brief: evidence, options, open questions and the choice I need to make. Stop for my decision before building, changing shared files or contacting users.
```

### Before you use the result

1. Open the cited sources. Does each observation say what the AI claims it says?
2. Keep competing explanations alive. Missing data should stay missing, not become a confident story.
3. Check that the test can change your mind. A polished screen is not evidence of customer demand.

#### Let new evidence challenge the plan.

Add a fresh interview that disagrees with your first explanation. Ask AI what it would change and why. Review the answer before saving a revised decision.

## Build the foundation once. Keep expanding what it can do.

We work through your product problem together and help you understand the setup behind it. Start with something small enough to use, then build on what works.

1. ### Make the product context usable.
   Organize who you’re building for, what you know, what you’ve decided and what is still uncertain. AI can interview you to fill gaps. You review what becomes the source of truth.
2. ### Turn a useful task into a repeatable skill.
   Practice a task such as comparing research findings or drafting a testable product brief. Save the instructions, examples and quality checks, then try them on a different product question.
3. ### Connect the next piece when it earns its place.
   Add a prototype builder, an approved feedback source or a recurring evidence review. With the right connections and schedule, AI can prepare new findings for you to assess. Choose what it may do and where it should stop.

![Sydney at a cafe table with laptops](<https://helloaristotle.com/brand/assets/photography/sydney-cafe-640.webp>)

Sydney Liu, founder of Hello Aristotle

## Learn with someone who has built products from the ground up.

Sydney Liu has led product at the companies he founded. At Commaful, he designed and built an interactive storytelling experience where more than 20 million people read a story.

At CharacterHub, he led product from the earliest work through a platform with 800,000+ users and over 3 million monthly visitors, including more than 1,000 user interviews. That experience informs the training: understand the person, make a product choice, and put something useful in front of them.

[Meet Sydney Liu →](<https://helloaristotle.com/insights/authors/sydney-liu/>)

### What our learners say.

Lucas describes his own experience learning to build AI workflows with Hello Aristotle.

> “Before Hello Aristotle, AI was something I had to sit down and drive every time. Now it runs entire workflows on autopilot. I get my time back, and the results are better than when I did it by hand.”

**Lucas Garvin** Co-founder &amp; CEO · ThoughtFlow.ai

## Give your next product question a better starting point.

This free starter library helps you organize reusable context. Begin with your users, product goals, constraints and decisions.

[![Hello Aristotle: Your AI starter library](<https://helloaristotle.com/editorial-covers/resource-ai-workspace-starter-53b3e455ca8b-1200.webp>)](<https://helloaristotle.com/resources/ai-workspace-starter/>)

### [Your AI starter library](<https://helloaristotle.com/resources/ai-workspace-starter/>)

Give your AI a useful starting point. Set up a private workspace with personal and company context, then let a guided interview help you fill in what matters.

## A few questions before you start.

**I already use AI for PRDs. What would be different?**

We can connect that brief to the work around it: the evidence behind a requirement, a prototype someone can try, and the decisions design and engineering need. You’ll practice building a reusable setup so each task has a better starting point.

**Do I need to know how to code?**

No coding background is needed to start organizing evidence or directing a prototype. Tools such as Codex and Claude Code can also help with hands-on building. We’ll match the task to your experience and agree how generated work will be checked. A production release needs the right technical review.

**Can we use the tools and documents my team already has?**

Yes, that’s a useful place to start. Tell us what your company allows and where your product information lives. We’ll confirm which connections are available. Plan requirements and access vary; you can begin with a few approved files rather than connecting everything.

**What will I be able to keep building on afterward?**

The aim is a product workspace you understand: organized context, a useful workflow, and checks that help you judge its output. We’ll agree the first deliverable together. You can then use those foundations for another product question or add a new capability.

**Could product, design and engineering learn together?**

Yes\! Bring a shared problem and the different perspectives around it. We can work on what needs to pass between you, where details get lost, and how each person can build on the same decisions. Group size and format are flexible.

**How long does it take, and what does it cost?**

Start with the free 20-minute call to discuss your product work. The paid individual follow-on session is one hour; team engagements begin with at least one hour and can extend from there. We’ll agree the scope, duration and price before you book paid training.

**Is there a product-management qualification?**

We offer Aristotle Certificates for proficiency milestones tied to practical work. They aren’t accredited qualifications or employer certificates. The focus here is being able to use what you learn on a real product problem.

**Is this the right kind of product training for me?**

This is practical help with your product work and the AI systems behind it. We can start with a familiar task or explore a different way to build.

**For your current workflow.** Improve discovery, requirements, research synthesis, prototypes or the handoff to another team.

**For a bigger change.** Explore how agents could support the whole product cycle, or how an AI-powered feature might work. We’ll choose a tractable first version and agree the technical scope.

## What would you build if you could test the idea sooner?

Bring a product challenge to a free 20-minute conversation. We’ll suggest where AI could help and discuss what working together could look like.

[Book a free 20-minute call](<https://helloaristotle.com/contact/?from=%2Fai-training%2Fproduct-managers%2F>)
