Requirements brief
Inputs and assistance
Group related feedback from tickets, notes and messages; draft the problem, evidence and open questions.
Review before action
Verify sources, affected users and interpretation before creating backlog items.
How I use AI across discovery, delivery, and product operations
Although AI has opened up many new possibilities, the basic questions I ask as a Product Manager remain the same. What are users trying to achieve? What is making it difficult for them? And how can we solve their problems in a way that also supports the goals of the business? Understanding these aspects, working closely with the product team and stakeholders, and checking whether a solution actually helps are still central to my work.
AI has changed how I approach many of these activities. I can bring together information from different sources, explore ideas through working prototypes, and automate repetitive tasks that previously required considerable manual effort. This gives me more time to investigate problems and discuss possible solutions with the team. It also brings new questions about accuracy, reliability and how much control to give an AI system. The following sections explain how I approach these decisions and use AI throughout the product management process.
Selected AI project · Pre-release beta
Interviews and shadowing showed real estate advisors switching between tools and relying on memory to keep track of follow-ups. I shaped a briefing assistant inside the CRM that brings relevant follow-ups, customer updates and appointments into one prioritised list.
Understanding customer needs involves bringing together feedback from various sources. Service desk tickets, stakeholder discussions, emails, internal communication channels and meeting notes often describe related problems from different perspectives. Reviewing these inputs together helps develop a clearer understanding of the problem and its impact on the users.
I utilise integrated AI agents and workflows to gather and structure this information, identify recurring themes and prepare initial problem statements. Depending on the available integrations and approved access, these workflows can bring together inputs from Jira, Confluence, shared mailboxes and other communication channels.
I review the findings against the original sources to understand what is supported by evidence, where assumptions have been made and which aspects need further clarification. Similar feedback from several channels may point to an important problem, but it is necessary to check whether these are independent experiences or references to the same issue.
The findings are then organised into a requirements brief that I can discuss with the product team and stakeholders. This provides a shared understanding of:
Approved sources
Evidence-linked brief
I use AI to explore different ways of understanding a problem, question proposed solutions and prepare for discussions with users, engineers and stakeholders. This helps me consider alternative approaches and identify questions that need to be answered before moving forward.
When comparing opportunities, I consider customer impact, strategic fit, urgency, risk, dependencies, implementation effort, technical feasibility and scalability. AI helps organise the available information against these factors and highlight gaps that need further investigation. I validate the findings with the people closest to the problem and work with the team to agree priorities.
This gives management a clearer understanding of the available options and the trade-offs involved. Involving engineering and design early also helps us assess whether an approach is useful, practical and sustainable before committing to its development.
Criteria I make explicit
A score is a discussion aid, not a substitute for judgement.
I use LLMs and generative AI tools such as Replit, ChatGPT and Claude to turn initial ideas into interactive prototypes that users and stakeholders can try before we commit to development. Alongside this, Figma helps me collaborate with designers and engineers to explore user journeys, refine interactions and gather feedback. Where suitable, plugins and integrations support this process within the team’s existing tools.
Before creating a prototype, I define the hypothesis we want to test and what we need to learn. For instance, can users complete a particular task, do they understand how the feature works, and does it offer enough value for them to change their current way of working? I use realistic fictional data and test with the intended users, documenting the findings and any questions that remain unanswered.
An interactive prototype gives the team something practical to discuss. It helps us identify usability issues, clarify requirements and explore technical constraints early. However, a prototype that works well in testing still needs further validation to establish demand and assess what is required for production. I also use AI to prepare research questions, explore possible user perspectives and analyse edge cases, while relying on feedback from real users to guide decisions.
Briefing Jane Doe · Tuesday
1 of 4 done
I create reusable AI instructions and workflows to support recurring activities such as requirements gathering, sprint preparation and stakeholder communication. Each workflow defines the inputs, the steps involved, the expected output and the points where I need to review the findings before proceeding. For tasks that require further investigation or choosing between different tools and sources, I use AI agents with clear boundaries and review checkpoints.
Using approved connectors, APIs, MCP servers or orchestration tools such as n8n, these workflows can bring together information from existing enterprise applications. This helps reduce the manual effort of collecting and organising information, while allowing the team to continue working with the tools they already use.
Inputs and assistance
Group related feedback from tickets, notes and messages; draft the problem, evidence and open questions.
Review before action
Verify sources, affected users and interpretation before creating backlog items.
Inputs and assistance
Review Jira carryover separately for frontend and backend; calculate availability from working calendars, leave and agreed allocations.
Review before action
Confirm unfinished work, capacity assumptions and estimates with the team.
Inputs and assistance
Bring together sprint progress, service desk themes and decisions; draft the intended outcome, delivered changes, blockers and stakeholder asks.
Review before action
Check what is actually delivered and confirm owners and dependencies.
Inputs and assistance
Combine verified release records, Jira items and supporting Confluence documentation into audience-appropriate drafts.
Review before action
Confirm deployment, feature availability, limitations and required user actions before publishing.
For instance, a scheduled workflow could help prepare for the next sprint by checking the availability of frontend and backend developers shortly before the current sprint ends. It could account for working hours, leave and existing commitments, then highlight missing information that needs clarification. The availability calculation would follow agreed rules, while AI could help explain exceptions and prepare the findings for discussion with the team.
Available hours alone do not tell us how many story points the team can deliver. I would use the team’s previous delivery experience, the work being considered and their input to agree on a realistic sprint commitment.
The workflow would first prepare a draft for review. Updating Jira tickets, sending notifications or publishing information would be separate steps, with approval where needed. Access would be limited to the information and actions required for the task, so the team could review important changes before they take effect.
Using AI in my own work and introducing AI into a product are separate decisions. I choose the approach based on the user’s task, the evidence available and the consequences of an error.
| Approach | When I would use it | Example |
|---|---|---|
| Rules-based software | When the requirements are clear and the same rules need to be applied consistently. | Checking permissions, calculating team availability or assigning leads according to agreed territory rules. |
| AI-assisted feature | When the task is difficult to define through fixed rules and involves understanding language, interpreting information or drafting content, with outputs that users can review, correct and improve. | Helping real estate advisors manage their assigned leads by summarising customer interactions, suggesting next steps and drafting follow-up messages for their review. |
| Hybrid workflow | When AI can help interpret information, while predefined rules control which options are eligible and how actions are carried out. | Using AI to understand a customer’s property requirements and suggest suitable exposés. Rules check budget, availability, access permissions and communication consent, while an advisor reviews the selection before sending it to the customer. |
I compare the expected benefit with a simpler alternative, including reliability, cost, latency, data requirements and maintenance. Even a repeatable model response can be wrong. Where an error would be unacceptable, I redesign the workflow, require review or choose conventional software.
For an example from my own work, where agreed rules set the priorities and AI helped prepare a daily briefing, see the AI briefing assistant case study.
When developing an AI feature, I work with design, engineering, security and the relevant business or legal specialists to agree on what the feature should do, how we will assess its performance and where its limits should be.
I start by identifying the user problem and the outcome we want to achieve. We establish how the task is currently performed and agree on what would constitute an improvement. Depending on the feature, this could include task completion, error rates, the effort needed to review the output, response times and operating costs.
I work with the team to prepare test cases that reflect how people would use the feature, along with the expected behaviour. These include everyday scenarios as well as ambiguous requests, missing information, different languages and the needs of relevant user groups.
We check whether the output is supported by the available information, whether important details have been missed and whether the feature helps users complete their task. For agents, this also means checking which tools they use, whether they respect permissions and what changes they make in the connected systems. Since AI can respond differently to the same input, we repeat tests to assess consistency.
I work with the relevant specialists to establish what information the feature needs and limit access accordingly. We review the provider’s data-handling and retention arrangements, use approved environments and confirm any necessary recording or data-processing permissions. We also test how the system handles malicious instructions in retrieved content and put controls around the actions it can perform.
Users need to understand when the system is uncertain or cannot complete a task reliably. I work with the team to provide ways to correct the output, ask for clarification or escalate the issue. Where needed, users should be able to continue through an existing process.
I would begin with a limited pilot to understand how the feature performs in everyday use, gather feedback and monitor failures and adoption. We agree on when to expand, pause or roll back the release, and repeat evaluations when changes to prompts, models, data sources or tools could affect its behaviour.
The aim is a feature that earns trust in everyday use. A promising demonstration is only the beginning.
AI can reduce repeated preparation and make information easier to discuss. Designers get clearer questions and earlier prototypes. Engineers get better-structured requirements and visible uncertainties. Stakeholders and management get updates linked to outcomes, decisions and dependencies.
I remain responsible for the quality of the evidence, the priorities we agree and the experience we deliver. I assess the benefit of AI through less rework, useful decisions and successful adoption, rather than the amount of content it produces.