Skip to content

AI in Requirements and Product Collaboration

How engineers can use AI to help gather requirements, turn them into structured user stories, and validate acceptance criteria before a single line of code is written. The SDLC starts before implementation, and AI can make the engineering-to-product handoff much more structured and less lossy.

  • 2 min read
  • Theory and practice
  • Day 7 of 7

Theory

Requirements and user stories are the foundation of any software project. The problem is that this phase is often slow, inconsistent, and information gets lost between product discussions and the backlog. As AI makes coding faster, the bottleneck shifts upstream: if you can generate code in minutes, weak or vague user stories become the real bottleneck.

AI is good at several things here. It can turn stakeholder interview notes or meeting transcripts into structured user stories, generate acceptance criteria from existing stories, evaluate stories against quality frameworks like INVEST, and help build user personas. It also bridges the communication gap between business needs and technical specifications.

But humans still need to stay in the loop. AI cannot replace actual user interviews or stakeholder conversations. It cannot validate whether a story makes real business sense, and it can produce plausible-sounding but wrong requirements. The real value is using AI to raise your baseline: generate a first draft, evaluate it, and then refine with human judgment. Think of it as a collaborator that handles the tedious drafting work while you focus on what actually matters to the people using your product.

Practice

Run this in a repository you already know, not a toy project. The point is to feel where the practice helps and where it gets in the way on code that has history.

Pick a real feature you are working on or planning. Then run this exercise.

Give an AI model (ChatGPT, Claude, etc.) a short description of your product and ask it to generate a user persona for your target user. Review the output and note anything surprising.

Next, ask the AI to write user stories for that persona using this format: "As a [role], I want [what] so that [why]." Pick one functional area to keep it scoped.

Then ask the AI to add acceptance criteria to each story, first as a simple list, then in Gherkin format (Given / When / Then).

Finally, paste the stories back and ask the AI to evaluate them against the INVEST criteria: Independent, Negotiable, Valuable, Estimable, Small, Testable. Ask it to flag only the criteria each story fails and suggest one concrete fix.

At the end, compare the output to what you would have written on your own. What did the AI catch that you missed? Where was it wrong? That reflection is the most useful part of the exercise.

The rest of day 7

  1. 01AI in Requirements and Product CollaborationYou are here
  2. 02AI as the Bridge Between Design and Development
  3. 03Testing with AI
  4. 04AI for Documentation
  5. 05Continuous AI: AI in Your CI/CD Pipeline
  6. 06AI for Debugging and Incident Response
  7. 07AI for Your Custom Workflows in the SDLC
Where this comes from

This path is the shortest route to the ideas. AI-Native Software Engineering (O'Reilly Media) is where each one is worked out in full, with the patterns, the trade-offs and the failure modes. The pillars cover the foundations one long essay at a time.