Sitemap

AI for Product Owners, the Professional Way

8 min read4 days ago

--

Product Owner in Practice series · Article 7 of 7

Press enter or click to view image in full size

In my work with teams and leaders, almost everyone says they use AI at work. When I look at how, the answer is nearly always the same: “I ask questions”, “I look up what I don’t know”, “I ask it to explain a concept”. That is AI used to fill knowledge gaps on the spot. It helps the person, but it gets very little out of the tool: the team’s work stays exactly the same.

Throughout this series, each article ended with an optional block showing how AI can speed up that part of the work. This article brings together the foundation behind all of them: what separates professional use from using AI as an oracle, how to give AI context, how to handle company data and restrictions, how to turn one-off requests into routines, and how to review what AI produces.

Using AI professionally is not about knowing how to write prompts. It is about turning what you do every week into routines with context, review, and an owner. The prompt is just one piece of those routines.

The four levels of use

Press enter or click to view image in full size

Level 1 carries a specific risk for people who are just starting out: using AI as the source of truth on things they don’t know yet. The answer comes back confident, well written and sometimes wrong, and there isn’t enough experience to notice. Ask AI to learn, yes, but check what matters at the source and with people who know the business.

Three shifts to move past level 1

Moving up doesn’t depend on a new tool. It depends on changing how you use the one you already have.

  1. Swap the question for the task. Instead of “how do you write good acceptance criteria?”, hand over the real story and ask for its criteria. Instead of “what is WSJF?”, hand over your nine items and ask for the table. AI stops explaining the work and becomes part of it.
  2. Swap the loose chat for fixed context. Without context, every answer is generic and you spend more time fixing it than you saved. With a context kit, the answer already follows your product’s and your team’s standards.
  3. Swap hidden use for a team agreement. As long as only you know you used AI, the gain stays with you. When the team agrees that “the draft arrives 24 hours early and refinement starts with the open questions”, the ritual changes, and the gain belongs to the team.

A quick test: for every use of AI someone mentions, ask “what changed in our process because of this?”. If the answer is “nothing”, that use is still at level 1 or 2.

The context kit

The difference between a generic answer and a useful one is context. Keep a document of two pages at most, updated every quarter, that goes with every request:

  1. The product in one sentence: who it is for, what problem it solves, the goal for the period.
  2. Current OKRs: the objective and KRs, with the numbers.
  3. Personas or segments: two or three, with what they need and what bothers them.
  4. Domain glossary: the business terms and what they mean. It keeps AI from inventing names.
  5. The team’s story pattern: format, maximum size, and one good example already delivered.
  6. Definition of Ready and Definition of Done, the way the team really uses them.
  7. Constraints: business, regulatory, and technical rules every delivery must respect.

You write much of this material in month 2 of your first 90 days (article 2). If your tool supports project instructions, put the kit there; if not, paste it at the start of the conversation.

The data traffic light

Before any use, classify the data. Your company’s policy always takes precedence over this table.

Press enter or click to view image in full size

When in doubt, treat it as red and ask your information security team.

When AI is restricted

In many companies, use is limited by contracts, budget, or governance: a corporate assistant with guardrails, no access to the board, sometimes a usage quota. The most common reaction is not to stop using AI. It is to use it in secret. According to Microsoft and LinkedIn’s 2024 Work Trend Index, 78% of AI users at work bring their own tools (Microsoft). In a 2025 TELUS Digital survey of 1,000 employees at large US companies, 68% accessed AI through personal accounts and 57% admitted entering sensitive information into public tools (TELUS Digital).

Get Bruno Novaes’s stories in your inbox

Join Medium for free to get updates from this writer.

The professional path sits between the two bad options, which are to stop using AI or to use it without judgment:

  • Learn the actual rule. Ask security, in writing, what is allowed. The real restriction is often smaller than the rumor.
  • Get the most out of what is approved. Even with guardrails, the approved tool usually covers most of the routines in this series, which rely on text the PO writes.
  • Bring the question, not the data. When the data can’t leave, the question usually can. “How should I structure a theme analysis of 200 customer comments?” exposes nothing; the answer becomes a method you run inside the company’s environment.
  • Use measurement to open doors. After six weeks with the approved tool, you will have numbers on what it has delivered. That is the best argument for more access, and far better than copying company data into a free account.

From loose chats to routines: the workflow card

What separates professional use from occasional use is turning recurring requests into routines you can repeat and teach. For each routine, write a short card:

  • When: the trigger, such as every Monday, every new epic, or before the review.
  • Inputs: where the data comes from and its traffic light color.
  • AI does / you do: how the work is split, with the decision always staying with you.
  • Review: what to check before using the output.
  • Output: the format and where it is stored.
  • Base prompt: the starting point, adapted to your context.

Here is an example, for the routine of preparing refinement:

Press enter or click to view image in full size

Keep the cards that work in a shared team space and revisit them in the retrospective. Over time, they become the team’s working library, not one person’s. And newcomers learn the process from them.

How to spot a bad answer

Reviewing is hard when you don’t know what to look for. These are the most common signs that an AI output isn’t ready to go to the team:

Press enter or click to view image in full size

Rule of thumb: anything with a number, a business rule, or a quote gets checked at the source before you use it.

The map of routines in the series

These are the routines from the “With AI” blocks of each article. Together, they cover the PO’s whole week:

Press enter or click to view image in full size

Don’t start with all of them. Pick one or two that tackle your biggest bottleneck (often refinement or discovery synthesis), and add another only once the first is stable.

How to measure the gain

The question is not “how much time did AI save?” but “did the team’s work improve after the routine changed?”. Use the metrics from article 6 (items that come back because of questions, items ready at the start of the sprint, bugs caused by ambiguous criteria, PO hours spent writing and preparing) and note when each routine started. Compare after six weeks, with the same control metric as always: production bugs and rework.

If the only thing that improved is your feeling of productivity, AI is still at level 1 or 2. And don’t measure the number of prompts, stories generated, or time spent in the tool: those numbers go up easily and say nothing about value.

Pitfalls

  • Outsourcing your thinking. AI writes convincing stories for any idea, including bad ones. Deciding what is worth building is still the PO’s job.
  • Invented business rules. AI fills gaps with plausible rules. Values, deadlines, and regulatory rules always get checked at the source.
  • An inflated backlog. Generating stories became cheap; maintaining them didn’t. Generate only what goes into the next two or three sprints.
  • Leaving the team out. If the PO arrives with everything ready and the team only approves it, shared understanding is lost. The draft is where the conversation starts.
  • Company data in a personal account. No productivity gain justifies it. When the approved tool isn’t enough, use your measured results to ask for more access.

Closing the series

Across these seven articles, the idea has been a single one: being a PO means deciding, with evidence, what is worth building, defending that decision, and showing through results whether it was right. The role and the product grammar give you the foundation; the first 90 days build understanding; discovery brings evidence; the path from backlog to delivery turns evidence into value; the dashboard and the forecast bring transparency; and growth comes one behavior at a time.

AI comes in as an accelerator at every one of these stages, not a replacement. It gives you back hours of writing and preparation. If those hours go back to customers, to the team, and to better decisions, you will see it in the metrics. If they go into writing more stories, nothing will have changed.

The Product Owner in Practice series ends here. Next up is the Scrum Master in Practice series, in the same format: the role seen from the inside, from joining a new team to handling delivery pressure, with scripts and examples you can apply.

References

--

--

Bruno Novaes
Bruno Novaes

Written by Bruno Novaes

Agile & Flow Specialist. Writing about product thinking, regulatory complexity, and how real-world constraints reshape flow, metrics, and delivery at scale.