Agent-native product management: what PMs need to decide

Why should product managers care about agents as users?

Because people are starting to hand tasks to AI assistants that operate software for them. If an assistant cannot use your product, the person asking it will use a product it can. Agents are a new kind of user with their own needs: they cannot see your screen, they retry when something fails, and they act at machine speed.

Agents do not replace your customer. They act on your customer’s behalf. The customer still owns the goal and the decision, and the agent does the clicking.

How do you find the right agent use cases?

Start with jobs your customers already do repeatedly in your product and would happily hand off: lookups, reports, bulk edits, scheduling, approvals. Write each as a job story, then check whether an agent could finish it without seeing a screen.

1. List the ten most repeated tasks from support tickets, analytics, and customer calls.
2. Write each as a job story: “When [situation], I want to [task], so I can [outcome].”
3. Sort each task into read-only, reversible change, or irreversible change.
4. Decide who approves anything that is not read-only, and how fast they can respond.
5. Start with the read-only tasks. They are the safest and show you where agents get stuck.

Which agent use cases should you build first?

Build in order of risk: lookups first, then summaries, then reversible edits with a preview. Keep anything that moves money, messages customers, or deletes data behind human approval until you have evidence it works.

What should you ask your engineering team?

Ten questions that reveal how ready the product is. None needs technical knowledge to ask, and the answers map directly to the twelve-question scorecard on the home page.

1. Can everything a user does in the app be done without the screen? Which of our top five workflows cannot?
2. What happens if the same request is sent twice? Could a retry charge a customer twice?
3. Can an action be previewed before it happens?
4. When something fails, does the response say what went wrong and what to try next?
5. How do we give an assistant access without handing over a person’s full login?
6. Can we limit what an assistant may do, and how much it may spend?
7. Can we tell from the logs whether a person or an assistant did something?
8. How would we know an assistant is struggling with our product?
9. Are our docs readable by a machine (plain text), or only in PDFs and videos?
10. Who approves the risky actions, and how long can they take?

What should you measure?

Track whether agents finish tasks, how often they need retries, and whether they recover from errors. These are suggested starting metrics, not an industry standard.

What does a sensible roadmap look like?

Three stages: make the product readable, make it safely actionable, then make it conversational. Each stage is useful on its own, so you can stop at any point and still have shipped value.

1. Crawl: be readable. Publish plain-text docs and an llms.txt file, take the scorecard to set a baseline, and expose one read-only workflow to assistants.
2. Walk: be safely actionable. Add reversible changes with preview and undo, give each assistant its own limited access, set spending and rate limits, and record who did what.
3. Run: be conversational. Add approval cards inside conversations, track agent-specific metrics, test with real assistants before each release, and open access to partners.

What belongs in a PRD for an agent-ready feature?

Add a short “agent behavior” section to any feature spec. It answers who may act, what needs approval, and what happens when things go wrong.

• User goal: the job the person wants done.
• Allowed actors: people, assistants, or both.
• Permissions: which roles can do it, and what the default is for a new assistant.
• Preview: what can be shown before the action happens.
• Approval: which steps need a human, and who.
• Errors: the failure cases and what each response should tell the caller.
• Repeats: what happens if the same request arrives twice.
• Limits: rate, spend, and size limits.
• Audit: how we will see who did it and what changed.
• Success metric: how we will know it works.

What can go wrong, and who owns it?

The main risks are access that is too broad, actions that happen twice, content that tricks an assistant, and costs that run away. Each needs a named owner before launch.

• Too much access. An assistant that borrows a person’s full login can do everything that person can. Owner: product and security.
• Silent double actions. Retries without protection can charge or email twice. Owner: engineering.
• Tricked assistants. Text inside a message or web page can contain instructions meant to hijack an assistant that reads it. This is called prompt injection. Keep risky actions behind approval so a trick cannot cause harm alone. Owner: security.
• Runaway cost. Agents work fast and can loop. Set spend and rate limits. Owner: product and finance.
• Unclear accountability. Decide who answers for what an assistant did on a customer’s behalf. Owner: product and legal.

This section is practitioner guidance, not legal or security advice. Your own security and legal teams should review the high-risk items.

A plain-English glossary