Looking back at it now, for years my workflow was a mess.

User stories in Sheets, flows in FigJam, wireframes in Figma, random notes dumped into Obsidian, specs in Word or Notion. Basically every app under the sun.

It worked… kinda. But honestly it was chaos. Half my time was just flipping tabs trying to piece together what I actually meant last week.

A couple years ago I started messing around with AI-powered IDEs like Cursor, and I kept running into the context problem (admittedly AI was in a different place back then). I realised that all this stuff had to live in one place, not spread across 6 tools, but in a single doc that could act like the backbone of a project.

That’s when I realised the power of the Product Requirements Document (PRD).

What’s a PRD anyway?

Think of it as the anchor for the whole build.

For AI it’s the context it needs so it doesn’t go off and build a bunch of stuff you didn’t ask for.

For humans it’s the shared language between design and dev.

When your PRD lives inside the repo, you can always point the AI back to it. For little prototypes or side experiments this is insanely powerful. For bigger projects, it stops things going off the rails and keeps everyone aligned.

When I was at my last agency I showed our tech lead what I was doing in Cursor with PRDs. He was kinda blown away by what I was building as a designer, and before long it became the backbone of the whole dev team’s process.

What actually goes into one?

Here’s how I break mine down:

Product Overview

• Purpose
• Target users
• Success metrics

Scope

• In scope
• Out of scope

User Stories

• As a , I want , so that .
• Acceptance criteria

Functional Requirements

• Each feature with description, impact, flows, requirements

Non-Functional Requirements

• Performance
• Reliability
• Security & privacy
• Accessibility
• Internationalisation

Data Models

• Entities, properties, relationships, retention

APIs and Integrations

• External services, endpoints, rate limits

UI and UX

• Key screens, wireframes, states

Analytics and Telemetry

• Metrics to track, logging

Risks and Assumptions

• Risks, assumptions, open questions

Rollout Plan

• Environments, feature flags, migrations, monitoring

Timeline and Milestones

• Milestones with goals and dates

Stakeholders

• DRI, approvers, reviewers, dependencies

Why it matters (especially now)

Most dev teams are AI-powered or at least AI-augmented already. The PRD becomes the linchpin of context. Without it, AI just guesses. With it, you’ve got a single source of truth that both humans and AI can work from.

For me it stopped being a boring doc and became one of the most creative parts of the process. It’s where design intent meets technical reality.

That’s the gist. If you’re experimenting with AI tools like Cursor, start writing PRDs. Trust me, it’ll save you from a lot of pain later.