Project Planning - PRDs and Requirements
development project-planning prd requirements
Why Planning Matters
Even for solo projects, writing down what you’re building before you build it prevents scope creep, wasted effort, and the classic “I’ll just figure it out as I go” spiral. A lightweight planning document forces you to think through the problem, define what success looks like, and set boundaries on what’s in and out of scope.
The bigger the project, the more this pays off — but even a 30-minute planning session for a weekend project saves hours of rework.
Common Planning Documents
| Document | Purpose | When to Use |
|---|---|---|
| PRD (Product Requirements Document) | Defines what to build and why — the problem, goals, users, and success criteria | Starting a new product or major feature |
| RFC (Request for Comments) | Proposes a technical approach and invites feedback before committing | Architectural decisions, new patterns, breaking changes |
| Design Doc / Technical Spec | Details how to build it — system design, data models, API contracts | Complex features requiring upfront architecture |
| User Stories | Captures requirements from the user’s perspective | Breaking features into implementable chunks |
| Acceptance Criteria | Defines when a story or feature is “done” | Attached to each user story or task |
How They Relate
Idea / Problem
│
▼
PRD ────────── "What are we building and why?"
│
▼
RFC / Design Doc "How should we build it?"
│
▼
User Stories ─── "What does the user need to do?"
│
▼
Acceptance Criteria "How do we know it's done?"
Anatomy of a PRD
A PRD doesn’t need to be a 20-page corporate document. At its core, it answers these questions:
| Section | What It Covers |
|---|---|
| Problem Statement | What problem are we solving? Who has this problem? |
| Goals | What does success look like? (measurable if possible) |
| Non-Goals | What are we explicitly not doing? (prevents scope creep) |
| User Stories | Key user workflows this feature enables |
| Requirements | Functional (what it does) and non-functional (performance, security) |
| Success Metrics | How we’ll measure if this worked |
| Scope & Timeline | What’s in v1 vs. later, rough milestones |
| Open Questions | Unresolved decisions that need answers |
Example: Minimal PRD Template
# PRD: [Feature/Project Name]
## Problem
[1-3 sentences describing the problem]
## Goals
- [Goal 1]
- [Goal 2]
## Non-Goals
- [What we're NOT doing]
## User Stories
- As a [user type], I want [action] so that [benefit]
## Requirements
### Must Have
- [Requirement]
### Nice to Have
- [Requirement]
## Success Metrics
- [How we measure success]
## Open Questions
- [Unresolved decisions]Writing Effective User Stories
User stories follow a simple format:
As a [type of user], I want [goal/action], so that [reason/benefit].
Examples
| Story | Why It Works |
|---|---|
| As a new user, I want to sign up with my email so that I can access the platform | Clear actor, action, and motivation |
| As an admin, I want to export logs to CSV so that I can audit activity offline | Specific and testable |
| As a developer, I want CLI output in JSON format so that I can pipe it to other tools | Technical but user-focused |
Tips
- Keep stories small enough to complete in one sprint (1-2 weeks)
- Each story should be independently valuable — not just “part 1 of 5”
- Attach acceptance criteria to each story: specific conditions that must be true for it to be considered done
Acceptance Criteria Example
Story: As a user, I want to reset my password via email.
Acceptance Criteria:
- User receives reset email within 60 seconds
- Reset link expires after 24 hours
- Password must meet complexity requirements
- User is logged in automatically after reset
Discovery Process
The typical flow from idea to implementation:
1. IDENTIFY Spot a problem or opportunity
│
2. RESEARCH Understand users, constraints, existing solutions
│
3. DEFINE Write the PRD — scope, goals, non-goals
│
4. DESIGN Technical spec / RFC — how to build it
│
5. VALIDATE Review with stakeholders, poke holes
│
6. BUILD Break into stories, start sprints
│
7. MEASURE Check against success metrics, iterate
Key principle: Steps 1-5 are cheap. Building the wrong thing is expensive. Invest time in discovery to build the right thing.
Applying to Solo / LLM Projects
You don’t need a full corporate PRD process for personal projects, but a lightweight version pays off significantly — especially when working with LLMs.
Why It Matters Even More with LLMs
- LLMs work better with clear context. A PRD gives the AI the same “big picture” you have in your head.
- Scope control. Without written boundaries, it’s easy to let the AI keep adding features you never planned for.
- Session continuity. When you start a new chat, you can paste the PRD and the AI picks up where you left off.
Lightweight Solo Workflow
- Write a mini-PRD (even just the problem, goals, and non-goals — 10 minutes)
- Iterate with the LLM — ask it to poke holes in your requirements before writing code
- Break into user stories — use them as individual prompts/tasks
- Keep a living doc — update the PRD as the project evolves
Template: Solo Project PRD
# Project: [Name]
## Problem
[What am I solving?]
## Goals (v1)
- [Keep it to 3-5 goals max]
## Non-Goals
- [What I'm NOT building yet]
## Key Features
- [ ] Feature 1
- [ ] Feature 2
## Tech Stack
- [Language, framework, key tools]
## Open Questions
- [Decisions I haven't made yet]Put this in your project repo (as PRD.md or in a docs/ folder) and reference it at the start of LLM sessions.