Writing a PRD

Before building an app, product teams write down exactly what they plan to build. This document is called a PRD. It's the single best thing you can give an AI builder.

What is a PRD?

Think of a recipe card. It lists who the dish is for, the ingredients, the steps, and what it should look like at the end. Anyone can follow it and get the same dish.

A PRD (product requirements document) is a recipe card for your app. It describes the problem, the users, and the features, in plain words. It doesn't describe code.

• It makes you think clearly before you build.
• It gives the AI one clear source of truth to follow.
• It stops "feature creep", which is when an app keeps growing until it never gets finished.

The parts of a PRD

• Problem — what pain or need does this app solve?
• Users — who will use it? Describe them simply.
• Features — the list of things the app must do. Keep version 1 small.
• User stories — short sentences describing what a user wants to do and why.
• Out of scope — things you are deliberately not building yet.
• Success — how you'll know the app works and is useful.

Writing user stories

A user story describes a feature from the user's point of view. It follows a simple pattern:

As a [type of user], I want to [do something], so that [benefit].

For example: "As a busy student, I want to check off a habit with one tap, so that tracking takes no effort." The "so that" part reminds the AI why the feature matters, which helps it make better design choices.

A full example PRD

For example, here is a complete PRD for a simple habit tracker app. You can use it as a template for your own idea.

# PRD: Habit Tracker

## Problem
People want to build small daily habits, but they forget or lose motivation.
Most habit apps are cluttered and full of features they don't need.

## Users
- Students and young professionals who want 2 to 5 simple daily habits
- Beginners who want a clean, simple app, not a complex planner

## Features (version 1)
1. Add a habit with a name and an optional emoji
2. Edit or delete a habit
3. Check off each habit once per day
4. Show the current streak (days in a row) for each habit
5. Show a simple weekly progress chart
6. Save data so it is still there after a refresh

## User stories
- As a user, I want to add a habit in a few seconds, so that getting started is easy.
- As a user, I want to check off a habit with one tap, so that tracking takes no effort.
- As a user, I want to see my streak, so that I stay motivated.
- As a user, I want to see my week at a glance, so that I know how I'm doing.

## Screens
- Home: today's habits with checkboxes and streaks
- Add/Edit habit: a simple form
- Progress: weekly chart

## Out of scope (not in version 1)
- User accounts and login
- Reminders and notifications
- Sharing with friends
- A mobile app (web only for now)

## Design
- Clean and calm, lots of white space
- One accent color (green)
- Works well on phones and laptops

## Success
- I can add a habit and check it off in under 10 seconds
- Streaks update correctly after a day is missed
- I use it myself every day for one week

Let's break this down:

• The features list is short and numbered, so you can build them one at a time.
• "Out of scope" removes login and reminders. That makes version 1 much easier.
• The success section is something you can actually test.

Let AI help you write it

Describe your idea and ask the AI to interview you first. This uses the "ask before assuming" guardrail.

You are a product manager helping a beginner plan their first app.
My idea: a simple web app to track daily habits and streaks.
Ask me up to 8 questions, one at a time, to understand the app.
After I answer, write a PRD in Markdown with these sections:
Problem, Users, Features (version 1), User stories, Screens,
Out of scope, Design, Success.
Keep version 1 small enough to build in a weekend.

Common mistakes

• Putting 20 features in version 1. Start with 4 to 6, and add more later.
• Describing how to code it ("use a useState hook"). Describe what it does instead.
• Skipping "Out of scope", then watching the AI add features you didn't want.
• Vague success goals like "people like it". Make them testable.

What's next?

The PRD describes what to build. Next, you'll write notes that tell your AI builder how to build it, every time.