How I Use AI as a Product Owner at EXANTE: From Research to Release

Hello, my name is Nastya. At EXANTE I have worked my way from Junior QA to Product Owner, and I often write about how we develop features. Today I want to share how I restructured my routine and learned to complete tasks faster and more efficiently with AI tools.

A product owner's work involves many stages: discovery, design, writing requirements and specifications, supporting delivery, collecting feedback after release, and a great deal of communication. Each stage has its own rhythm, artefacts and points of friction. Almost every one of them, including competitor analysis and benchmarking, feature specifications, mockups and prototypes, and transcription of user interviews, used to start from a blank page.

After months of working with AI, I can say it excels at one thing: turning a blank page into a draft. Not a final answer or a ready solution, but a draft. This understanding helps me use AI in a way that makes it useful rather than dangerous.

• Caveat 1. This is not a "Top 10 AI Tools for Product Managers" review, nor a collection of ready-made prompts. Every product owner has their own stack, and what works for me may not work for you as described. But it may give you food for thought about where and how you can apply this logic to your own tasks.
• Caveat 2. AI does not replace me in my work. It takes on the routine and helps redistribute my time.

What follows is an account of which tasks I have delegated to it and how.

How I Use AI for Discovery

Building the foundation for competitor analysis
Work on any new product begins with competitor analysis. Before AI, this meant a week of digging: hundreds of browser tabs, screenshots, PDF tutorials, a dozen open platforms across different devices, observation notes, and pages of results in Confluence.

AI changed that. I define what needs to be compared, for whom and in what way. For instance, a registration flow, how multiple accounts are handled, calculation mechanics, or the implementation of a complex feature. A specific request looks something like this: "Compare the asset manager registration flow for competitors X, Y, Z. Cover which steps a client goes through, which documents are requested, whether video verification is required, how long the process takes, and how client accounts are linked. Return the result as a table with competitors in rows and stages in columns. If no data is available from public sources, mark that explicitly." The result is a structured matrix covering all competitors in one pass.

Two points are critical here.

• First, AI output cannot be trusted blindly. It can describe a feature that does not exist with complete confidence, and in regulated products that is a real risk. I open every source it references and verify the data.
• Second, what AI generates is a foundation for work, not a finished result. I add the structured competitor comparison to my document as a draft, then manually add comments, observations, screenshots and descriptions from the sources I find myself.

AI reduces the time from "I need research on topic X" to "I have solid arguments for or against the proposed solution" from a week to a day, including manual research and verification.

Understanding user needs
Client interviews are part of the foundation on which discovery and subsequent decision-making are built. They are also hours of recordings that must be turned into something readable. Previously, converting recordings consumed nearly as much time as the interview itself: reviewing the recording, extracting the key points, converting them into tasks, and prioritising by user pain.

The process now looks like this. I first send the meeting recording to a transcription service, which returns a text transcript. I then feed it into AI along with a prompt template that specifies what to extract:

• pain points and user problems;
• direct quotes in the user's own language, word for word, without paraphrasing;
• workarounds, meaning what the client currently does to get around the problem;
• explicit and implicit requests, what they ask for directly and what they only imply;
• user segment and usage context.

The output is not a summary but a structured table with these columns. Each row is a separate insight from the interview. From there I convert it into action items and wrap them as tasks in Jira.

What matters here:

The template means data is processed consistently. AI turns each interview into a table using the same logic. Those tables can later be processed together to draw conclusions for backlog prioritisation. When I have accumulated 10 to 15 interviews, I upload their summary tables into AI and ask for a top-level analysis. My requests are standard and usually follow a sequence.

• Frequency of problems. "Across all these tables, identify problems that are mentioned most often. Show the number of mentions and which interviews they came from." This gives a first cross-section of what is causing widespread pain.
• Clustering similar pain points. "Group problems that are similar in meaning into clusters, even if they are worded differently." The same problem may be described ten different ways across ten interviews. Without this step, frequency analysis understates the real picture.
• Segmentation. "Break down the problems by user segment: which are characteristic of which group." This helps identify who is affected and allows priority decisions to be made not "on average" but in relation to a specific segment.

The output is a weighted list of themes, to which I then add my own judgement about business priority and implementation cost.

Quotes must be checked against the original. AI tends to rephrase slightly. For summarising client ideas in a report that is acceptable, but quotes must be verbatim.

Action items are a list of what now needs to be acted on. I compile the plan myself, looking across all interviews together.

AI reduces the time between "we conducted the interview" and "we will do X with this over Y sprints" from days to hours.

Investigating the reasons behind user behaviour
After one module was released, I had raw statistics: number of users, number of their actions, and how often each optional setting was enabled. I needed to decide which options would remain and be expanded functionally, and which were edge cases not worth investing development resources in.

The numbers alone did not indicate what to do. At first it seemed that 29% usage for one option was low and it was a candidate for removal. A deeply buried setting that was rarely used also looked like an edge case.

I then fed the same table into AI with the prompt: "These are my conclusions about this data. Challenge me: what alternative interpretations are possible, and what might I have missed?" The counter-arguments I received changed the picture. AI suggested that 29% might not be low but actually high for a feature designed for professional traders. And that low usage of a deeply buried setting does not necessarily mean it is unimportant: users simply may not reach it, and before removing it, it makes sense to test a hypothesis by moving it somewhere visible and monitoring the trend.

The decision remained mine. But I made it with a broader set of arguments in hand.

Two points matter here.

• Tell AI explicitly that you want your view challenged. Otherwise it will agree with you and reinforce your existing arguments.
• Apply critical thinking to AI's points. They can sound highly convincing while lacking any business logic.

This is how AI helps you see the situation from a different angle. Being invested in your product and wanting to develop it is a good and useful trait for a product owner. But if an idea that seems brilliant would potentially improve the interface only from a UI perspective without increasing net revenue, AI will help you take off the rose-tinted glasses.

How I Use AI for Requirements Gathering and Design

Turning an abstract idea into a prototype
At EXANTE the full discovery phase ends with a set of artefacts: a product description, technical specifications, mockups and a dynamic prototype that can be clicked through to understand the logic of both the overall concept and specific cases. Dynamic prototypes are where AI saves me the most time.

When a complex module needs a prototype and there are already established market solutions for it, the work goes through several stages. Here is how those stages looked before AI and how they look now.

Defining requirements. Previously, formalising requirements involved several discussions with the designer. I would arrive with an idea in general terms, we would work through it together, asking each other clarifying questions, sketching initial ideas on a whiteboard, talking through what the feature should include. Each cycle took days, and formalised requirements only emerged after several iterations.

Now I describe the concept to AI in text. I provide five things: what the feature is, which user problem it solves, how competitors have addressed similar challenges (with specific links or screenshots), what must definitely be included in our case, and which edge cases matter. I then ask it to formulate functional requirements, describe the user flow step by step, and identify non-standard scenarios. Within minutes I have a draft to review and adjust.

Creating a visual mockup. Previously the designer would go and produce a mockup in Figma over several days, and the result was a designer output: considered in composition, built on system components. Now I do not replace that stage. Instead I move the first visual render to before the designer is involved: I feed AI the finished requirements and ask it to build an interactive HTML prototype using simple components, without pixel-perfect styling or brand visuals, but with working logic and response to input. Within minutes I have a clickable draft to check how the feature behaviour feels in practice.

Creating the design in Figma. Previously revisions needed to be made to the designer's mockup. Now all major revisions are already reflected in the generated visual, and the designer's task is simply to rebuild the concept in Figma using the components from our projects.

Documenting the concept as product documentation. Previously this had to be written by hand from scratch. Now AI writes the product documentation in Confluence.

What remains is to align the design with management and discuss its implementation with the team. AI cannot and should not accelerate that part of the work.

As a result, design can be completed in a few days rather than one to three weeks.

There is an additional advantage: the AI prototype is dynamic, meaning parameters within it can be changed. For example, at the early delivery stage the QA team analyses the requirements and asks: "Will the chart recalculate if we change this parameter here?" QA tests it immediately, records the answer, and moves on.

Working on one feature for three interfaces
Our product is cross-platform, so the same feature typically appears on desktop, web and sometimes elsewhere, such as a client portal or mobile application. Previously this required three separate specification iterations, three design sign-offs and three conversations with development. It also produced almost inevitable inconsistencies in behaviour between interfaces, since each platform is handled by a separate team with its own processes, release cycles and priorities.

With AI I now do this almost independently. I describe the core logic of the feature once, and AI helps me expand it into three versions of the specification, accounting for the characteristics of each platform. A request to AI looks roughly like this:

Describe the implementation of the feature [brief description] on three platforms: desktop, web and mobile application. The core logic is the same across all platforms: [user flow]. For each platform, specify which interface elements are used, which edge cases apply, and which interaction specifics apply, such as keyboard shortcuts on desktop, touch gestures on mobile, and screen and block width constraints. Format: three separate sections, one per platform.

The output is three versions of the specification. I then check them against a simple checklist: does the user flow match across platforms, is the terminology consistent everywhere (names of buttons, fields, statuses), and are real platform specifics accounted for, such as shortcuts appearing on desktop and the UX being restructured for one-handed use on mobile. If something is missing or something irrelevant has appeared, I iterate on the request. One or two rounds are usually enough.

The same applies to prototypes: one concept becomes three clickable versions that can be shown to the team, management and clients in interviews simultaneously.

In practice this produces consistency across interfaces. The same feature behaves the same way across different products. For example, placing an order through the trading panel works the same way across all three terminals: colours and button names, order submission confirmations and error handling are identical down to the last detail. When all three versions come from the same source simultaneously, consistency is built in at the documentation stage.

The designer and development team are still involved. The prototype does not replace review, but the conversation begins from a more developed starting point.

Translating documentation
EXANTE is a multinational company, so for universal access we translate documents into English. The development team may speak a different language, and some nuances are easier to convey in it. Specifications therefore frequently need to be written in multiple languages.

Previously I spent an hour or more translating a document through an online translator. It handled financial terminology poorly: "order" became a food order rather than a trading order, "position" became a job title rather than a trading position. After machine translation the document had to be read in full to find such instances. Now translation takes 10 to 15 minutes. AI produces a sufficiently good draft translation. I read it quickly, check the terminology and its application in specific places carefully, and the document is ready.

Bilingual documentation stops being a separate task that requires finding a free hour.

How I Use AI for Planning and Delivery

"List the pros and cons"
Not every resource management decision can be made with confidence. Sometimes it is unclear what potential a new direction has: whether to assign it a full team immediately or first run a pilot with three volunteers. Sometimes existing teams need to be reorganised around newly approved products. These questions are not supported by benchmarks or statistics. They are management judgements about people, priorities and resources.

In such cases I again use AI to see what options it suggests, and then select one or several suitable ideas. I describe the existing structure and the new tasks, specify the constraints that must be considered, and ask for organisational options with their advantages and disadvantages.

For example, I recently worked through this situation: the company needed to launch several new directions simultaneously without additional hiring and without fully stopping the current work of existing teams. In my request to AI I described which teams exist, what they are working on, what our new directions are, and what timelines we need to meet. The output was three organisational options: distributing the new work across existing teams, forming temporary feature teams by seconding people from their current work, and a matrix model with shared developers. Each came with explicit advantages and disadvantages.

The result is a structured brief and arguments, over which I think and then make the decision myself.

"Draft a Confluence page"
Documentation is where every product owner quietly dislikes themselves. AI helps write the draft. I feed it the specification, links to the design or prototype, a transcript of an interview, or any other artefact I need to turn into a document, and ask it to write a first version. I receive a structured draft that follows the patterns used at EXANTE. After that I usually rewrite 20 to 40 per cent of the text, but I no longer start from nothing.

My first merge request
I participate in delivery not only as a PO who signs off on the result, but as someone who opens merge requests, which surprised me as much as anyone.

It works like this: for small, reasonably isolated tasks I handle the work myself through Claude Code. The process is as follows.

• I describe the task with the most complete set of conditions and inputs.
• It writes code to solve the task.
• I ask it to create a local branch with the proposed solution and build locally from that branch.
• I check what the result looks like in the interface.
• I send it back for revision if I find bugs.

After several such cycles, when successful, I push the commit and open a merge request. Claude also adds a description to the Jira task explaining what was done and what the QA team needs to check.

The merge request then goes through the standard code review from developers and is merged into the staging build, where the QA team runs its testing. If bugs are found during review or testing, my merge request goes back for revision. After all fixes the review cycle repeats.

The resolved task goes to production via exactly the same pipeline as any other merge request.

I do not make complex architectural changes. I only modify what is clearly understood and isolated. Everything that touches the core, interaction protocols and integrations with external systems remains the work of engineers.

This does not make me a developer. But small changes no longer sit in the team's backlog for weeks. I handle them myself.

This clears the backlog of small, low-priority tasks that collectively make the product noticeably better. It has also given me a much better understanding of how the parts of the product I describe in specifications actually work. Understanding code is not essential for a PO, but it helps in grasping dependencies within a project and the overall complexity of the structure. That in turn helps with planning and estimation for a sprint or an entire quarter.

Where I Deliberately Do Not Use AI

• I do not hand product decisions to AI. Priorities, scope reduction, "do we launch or not": these are my responsibility.
• I do not trust AI with final fact-checking. Regulatory details, instrument characteristics, exchange rules. If AI states that a competitor has a certain feature, I verify it before the information enters any document I am responsible for.
• I do not use AI instead of talking to users. AI helps process interviews that have already been conducted, but it does not replace the conversation itself. In a live discussion you can follow a thread: ask a clarifying question, ask again, read a pause and an emotional reaction. No questionnaire or AI form offers that. Clients also generally find it easier to open up with a person than with an automated interface, and that affects how much they will share next time.
• AI drafts do not replace review from designers and developers. Prototypes are quick drafts. Merge requests are entries into a shared pipeline. Polished results and architectural integrity remain a craft.

Key Principles for Product Owners Just Starting to Use AI

These are the things that have worked for me.

• Use AI to create first drafts and overcome the fear of the blank page. Do not treat what it produces as a finished result.
• Verify facts. Always. Particularly in regulated and technical domains, where a single error in a specification can cost the team weeks of revisions and the company its reputation.
• Build your own prompt templates for interviews, specifications and research. A good prompt produces results that are ten times more useful than a generic request. "Process this interview" is a poor prompt. "Extract pain points, direct quotes, mentioned workarounds and user segment from the transcript, and return the result as a table" is a good one. The difference in output is significant.
• Do not try to delegate all thinking to AI. Leave room for independent thought. If you begin to rely on AI too heavily, you will start to understand your own product less well, and you will notice this the first time someone asks you a difficult question in a meeting.
• Define for yourself what you want to control personally and where you can rely on AI. For example: I always check interview quotes against the original, I verify competitor facts manually, and I make final priority decisions myself. Everything else, including structuring, drafts, formatting and translations, AI can handle. When the boundaries are clear, any error has a clear owner and you can work out what went wrong and how to prevent it in future.
• Treat AI as a team member who may be right or wrong. Give it context. Challenge weak or suspicious answers. Do not accept the first version it produces as a basis for a final decision.

Conclusion

With AI in my work, the path from idea to feature release has become noticeably shorter. A feature that a year ago took one and a half to two months to complete now takes three to four weeks. The preparatory layer of work that previously stretched discovery and requirements across weeks now fits into days.

This is not because the team is working more intensively, though that plays a role too, since product owners are not the only ones benefiting from AI. The team simply engages with the work earlier, and by that point already has the most fully developed specification possible in hand.

AI has redistributed time across tasks. Less time now goes to blank pages, first drafts, transcriptions, translations and re-expressing the same content in different formats. More time remains for what genuinely belongs in a person's sphere of responsibility: selecting solutions, finding compromises and negotiating with real people. Without that, a team is left with a set of artefacts. With it, they have a product.

AI has also slightly blurred the line between "a product owner describes" and "a product owner does." In some cases I now reach production-level code, not in place of developers but alongside them. That shift is perhaps the most interesting thing that has happened to me over the past year.

P.S. Have AI tools brought real changes to your product routine? Where have you made a deliberate choice not to use them? Write in — it would be interesting to hear.