How to write a product requirements document (PRD) with AI

How do you write a product requirements document with AI?

The fastest way to write a product requirements document (PRD) with AI is to treat the model as an interviewer, not a ghostwriter. Explain your idea in a paragraph, ask it to raise the questions you have not answered, then have it fill a fixed template that you review section by section. In one session you end up with a document that says who uses the app, what it does, what data it stores and what will not make it into version one.

Why bother when you could just tell an agent to build a booking app? Because a short request forces the AI to guess, producing features you did not want and missing ones you needed. A PRD turns guesses into written decisions and surfaces contradictions before they become code.

If you have not tested the idea with real customers yet, start with validating your app idea and come back. If you plan with ChatGPT or Claude, this guide complements planning your app with AI.

A good PRD does not describe everything; it describes enough that everyone stops guessing.

What sections does a PRD for a small app need?

You do not need thirty pages. For a small app or an MVP, two to four pages are enough as long as they cover the sections below. This same template is what you will ask the AI to fill in.

Step by step: writing the PRD with AI

1. 1
   Write the idea paragraph in your own words

   Five to eight sentences: the problem, who has it and how they solve it today. Dialect and shorthand are fine.

2. 2
   Ask for questions before any writing

   Tell the model: do not write the PRD yet, ask me up to ten questions first. This surfaces cancellations, refunds, permissions and edge cases.

3. 3
   Answer with examples, not generalities

   Instead of 'the customer books', say 'Sara books a facial on Thursday at 7 pm in Al Narjis and pays a SAR 50 deposit'. Real examples produce sharper requirements.

4. 4
   Request the draft in the fixed template

   Ask for the sections in the order of the table above, with numbered features labelled must-have now, important later, or future idea.

5. 5
   Review and cut

   Read critically. Delete any feature you did not ask for and flag anything the model invented, such as user numbers, prices or legal requirements you have not confirmed.

6. 6
   Ask for acceptance criteria per feature

   For each must-have feature, request three to five testable criteria in the form: when X happens, Y must happen.

7. 7
   Freeze a version

   Save it as version 1.0 with a date and log later changes as new versions.

A copy-ready prompt for your PRD

Paste this into any AI assistant, or straight into Fanann, and replace the bracketed parts with your idea. Notice that it blocks writing until the questions are answered and requires an out-of-scope section.

If you write the PRD inside the Fanann Agent, it stays in the project's context and you can simply say: build feature 1 from the PRD. For more phrasing patterns, see how to write prompts that build better apps.

User stories and acceptance criteria: the part that makes the difference

A user story says what someone wants; an acceptance criterion says how we know the app actually does it. AI is excellent at generating user stories, but it needs a push from you to write precise criteria instead of generic ones.

Gulf requirements everyone forgets

• Payment methods: mada and Apple Pay, possibly STC Pay (now part of STC Bank), or Tabby and Tamara for instalments.
• Phone-number sign-in with OTP, and whether you need national identity login such as Nafath or UAE PASS.
• Addresses: the National Address in Saudi Arabia or Makani in Dubai if you deliver.
• Invoices: VAT and a QR code, and whether you fall into an e-invoicing wave; check with ZATCA or the FTA.
• Seasons: Ramadan hours, both Eids, National Day and Founding Day, and the Friday–Saturday weekend in Saudi Arabia.
• Channels: WhatsApp for confirmations and links that share well on Snapchat and TikTok.
• Privacy: a privacy policy and consent flows aligned with personal data protection law.

Common mistakes when writing a PRD with AI

• Accepting the first draft: a polished-looking document can still be generic.
• A PRD for everything: if your must-have list runs past 8 to 10 items, you are specifying a full product, not a first version.
• Forgetting roles: who sees what, who changes prices, who can cancel an order? Leaving this out creates security gaps later.
• Data without relationships: write that a customer has many appointments and each appointment has one service and one stylist. That is what gets the database right from the start.
• A long PRD in a long chat: as a conversation grows, the model can lose earlier details because of context window limits. Keep the PRD in a file and re-attach it when needed.

To describe data in a way a database understands, see prompts for database design.

From PRD to a working app

The PRD is not the goal; it is the build map. The most stable approach is to turn each must-have feature into its own request and test it before moving on, which we cover in detail in build one feature at a time.

1. Attach the PRD at the start of the project and ask the agent for a build plan ordered by feature.
2. Start with the data model and roles, then the first user story end to end.
3. After each feature, test it against the written acceptance criteria, not against your impression.
4. Add payments and notifications once the core flow works.
5. Update the PRD with every significant change so it remains an honest reference.

Next step: write your idea paragraph today and ask for the ten questions.

Frequently asked questions

Terms in this article