What AI actually does well in product and requirements work

Few topics in product work attract as much confident commentary as AI. Depending on who you ask, it either makes business analysts obsolete or produces output so unreliable that it isn’t worth the time it saves.

Both positions are easy to defend in the abstract. After a few months of using these tools on real work, the picture becomes less clear-cut.

My own introduction to this was fairly hands-on. 

On one project, my task was to improve the quality of AI-generated user stories. The method was unglamorous: I would write a user story myself, compare it with the model’s version of the same requirement, and explain the differences, including what it should have paid attention to. Over many iterations, the output improved noticeably.

What stayed with me was less the result than what the process revealed. Many of the corrections drew on context I had never written down: knowledge about the product, the team, or what a developer on that project needed in order to start work. The model had no trouble expressing a requirement. The difficulty was accounting for knowledge that lived in my head and nowhere else.

That gap helps explain both where AI is useful in requirements work and why a well-written draft can still be a long way from ready to build.

Where AI genuinely helps

Drafting and restructuring

The distance between rough meeting notes and a properly structured ticket often involves a fair amount of mechanical work. Reformatting acceptance criteria, rewriting a requirement for a different audience, or turning a bulleted outline into a usable draft – these are tasks where AI can save time, provided the underlying decisions are already clear.

Breadth when you need it

Asking what a specification might be missing usually produces a long list, much of which is irrelevant. But reviewing thirty suggestions to find three worth investigating can still be useful. The distinction is that these are possibilities to examine, rather than requirements to accept. The model can broaden the discussion; someone who understands the product still needs to decide what belongs in it.

Translating between audiences 

A technical constraint explained to a business stakeholder and a business rationale explained to an engineering team may describe the same decision in different terms. Moving between them quickly is useful, and it was something the model handled well early on. When the reasoning was clear and the relevant context was available, it could help express that reasoning for the person who needed to understand it.

Where human judgement still matters

It does not know what was not captured 

Some of the most valuable signals in a discovery workshop never make it into the notes. A hesitation before an answer, two stakeholders describing the same process in incompatible ways, or a topic everyone politely avoids may all warrant further investigation. Someone still needs to notice the uncertainty, ask the follow-up question, and establish what it means for the requirement. A model receives the words, but the meaning was in the room.

It can produce plausible output without getting the requirement right 

A badly written requirement often draws attention to itself. A well-written but incorrect requirement may not. This inverts an instinct most teams have developed, where sloppy writing was a reasonable proxy for sloppy thinking. Fluent output can therefore invite less scrutiny precisely when it still needs checking. Clear language and consistent formatting make a story easier to read. They do not establish that the business rules are correct, the exceptions are covered, or the behaviour has been agreed.

It cannot take responsibility for the decision. Prioritisation involves deciding what the business can afford to delay, leave unresolved, or get wrong. AI can help organise the options and make trade-offs easier to examine. Making the decision requires people who understand the constraints and are accountable for the consequences.

The bottleneck moves rather than disappears

When the effort involved in producing requirements falls, the constraint does not necessarily vanish. It can move to the part of the process that was already the least formalised.

Most teams have a reasonably familiar way of writing requirements. Fewer have an equally explicit way of checking them. When drafting takes time, questions may surface and get resolved during the writing itself. Producing a draft faster can leave more of that work for the reviewer.

Review can then become the bottleneck. Checking a plausible-looking requirement may take considerable effort, because the reviewer has to distinguish agreed information from assumptions that happen to sound reasonable. A ticket can appear complete while still containing decisions nobody has made.

This helps explain why the same tool can produce different results across teams. Those with an agreed definition of ready, clear standards for acceptance criteria, and a shared understanding of what a complete requirement contains have a stronger basis for reviewing the output. They know what they are looking for and which questions must be resolved before development begins.

Teams without those things may get more drafts without gaining the capacity to assess them. Existing gaps in the process become harder to manage as the volume increases.

The tools amplify an existing process. They do not supply one.

How to work out where AI belongs in your process

A practical sequence, rather than a set of principles:

Map how a requirement actually travels

Follow the real path from the moment a need is raised to the moment someone starts building. Look beyond the process diagram to the conversations, documents, and decisions involved. Pay attention to where context enters the process and whether it survives the next handover.

Find where quality is lost

The problem may sit in one or two specific places: a translation between business and technical language, a decision that never reaches the ticket, or a point where context is assumed rather than recorded. These handovers deserve attention even when they are not the slowest steps.

Assess how easy the output is to check

For each task, ask what happens if the result is wrong. Can the reviewer compare it with an agreed source and spot the error immediately, or would the mistake emerge three sprints later in testing? Consider both the effort required to review the output and the consequences of missing something. Time saved in drafting is only part of the calculation.

Start where errors are visible 

Drafting from agreed notes, restructuring existing requirements, and generating options for discussion give the team something concrete to review. Immediate feedback helps people develop a realistic understanding of where the tool is useful and where it needs more guidance.

Write down what good looks like before you scale

If the team cannot explain what separates a strong ticket from a mediocre one, increasing output will not resolve the disagreement. Agree on the criteria and use examples to make them concrete. Recurring corrections are particularly useful here: they often reveal expectations that the team has never made explicit.

Help people use it properly

Within our own team, a lot of the value came from sitting with colleagues who were unsure how to approach these tools. We worked through how to structure a prompt, what context to supply up front, and how to refine a result without burning through attempts. Giving people access leaves those practical questions unanswered. Working through them together helps establish a shared understanding of how to get useful results.

Keep accountability with a person

Someone needs to own the decision that a requirement is ready for development. That means checking its substance, resolving open questions, and confirming that it reflects what has been agreed. Approval needs to mean more than accepting a document that looks complete.

Where Vega IT fits in

These are the questions we work through with clients: how requirements currently move through an organisation, where quality is lost, what a good requirement needs to contain, and which tasks are sensible candidates for AI. The review process needs just as much attention as the drafting process, particularly if the team expects to handle more output.

That work provides a basis for deciding where tooling will help and how to assess its value. A faster draft is useful when it reduces the effort required to reach a requirement the team can confidently build. If it leaves reviewers or developers with more uncertainty to resolve, the apparent saving may simply move elsewhere.

My experience with user stories brought me back to that distinction. Improving the output meant making previously unspoken knowledge explicit. The corrections helped the model, but they also revealed what our process relied on. Understanding that is a useful starting point for deciding what to accelerate.