How to write a product requirements document as a non-technical founder

A product requirements document (PRD) as a non-technical founder is a short, plain-English brief that tells an engineer what to build, who it's for, how you'll know it worked, and what's explicitly out of scope. Aim for 1 to 2 pages, written in user-story form, with success metrics tied to numbers your bank account or analytics tool will confirm. Skip the architecture; that's the engineer's job.

Most PRD templates online are written for product managers at Meta, not for a solo founder trying to ship by Friday. We'll fix that.

What a PRD actually is (and what it isn't)

A PRD is a one-way contract between you and whoever is writing the code. It says: here is the problem, here is the user, here is what "done" looks like. That's it.

A PRD is not an architecture diagram. It's not a Jira epic with 47 sub-tasks. It's not a Figma file. It's not your pitch deck. Each of those has a job, but none of them are a PRD.

Founders confuse PRDs with two adjacent documents:

A spec is what the engineer writes (or generates with Claude or Cursor) after reading your PRD. It includes the database schema, API contracts, and component tree.
A roadmap is the ordered list of PRDs you plan to ship over a quarter. The PRD itself describes one slice.

If your "PRD" includes a sentence like "we'll use PostgreSQL with row-level security", you've written half a spec. Delete the spec part. The engineer will do that better than you can, especially on Cadence where every engineer is AI-native by default and can spin up a working schema from your user stories in under an hour.

The seven sections every founder PRD needs

Your PRD has exactly seven sections. No more. If you can't fill one in, that's a signal you haven't thought hard enough about the feature, not that the section is unimportant.

1. Problem

One paragraph. What is the user currently doing, and why does it suck? Be specific. "Users can't track invoices" is not a problem statement. "Users invoice through Stripe but have to manually copy the invoice link into an email every time, which takes 3 minutes per invoice and they forget who they sent it to" is a problem statement.

2. User

Who has this problem? Name them. "Power users" is not a user. "Solo consultants who send 5 to 20 invoices per month and use Stripe + Gmail" is a user. If you can't name three real customers (by first name) who have this exact problem, you don't have a validated problem yet. Go talk to people before you write the PRD.

3. Success metric

How will you know it worked? Pick one number. Not three. One. "Increase invoice-send rate per active user from 1.2 to 2.0 per week within 30 days of launch." If the number doesn't move, the feature failed, regardless of how pretty the UI looks.

4. Scope

Bullet list. What's in. "User can click 'Send' on any draft invoice and trigger an email from our domain with the Stripe payment link and a thank-you message."

5. Non-goals

Bullet list. What's explicitly out. This section saves you more money than any other. "Not in scope: multi-recipient invoices. Not in scope: reminder emails. Not in scope: custom email templates per client." Every non-goal is a feature you've consciously decided to defer, which means the engineer won't quietly add it and bill you for the extra day.

6. Edge cases

What happens when something weird occurs? Bullet 4 to 8 cases. "What if the invoice is already paid? What if the email bounces? What if Stripe is down? What if the user clicks Send twice?" These are the bugs you'll otherwise file at 11pm on launch day.

7. Dependencies

What needs to be true for this to ship? "Stripe Connect must be set up. SendGrid or Resend configured for outbound email. Legal copy approved for the email footer."

That's the whole PRD. If you stay disciplined, it fits on one page.

How to write user stories without dev speak

User stories are how you communicate features without pretending to be an engineer. The format is older than Agile and still works:

As a [user type], I want to [do thing] so that [outcome].

Three rules:

No verbs from the codebase. No "click the button", "submit the form", "POST to /api/invoices". Those are implementation. Use "send", "approve", "review", "reject", real-world verbs.
Outcome is mandatory. "As a user, I want to send an invoice so that I can ship it without copy-pasting and get paid faster." The "so that" is the part your engineer reads twice. It tells them what to optimize for when they hit an ambiguous call.
One actor per story. If you find yourself writing "As a user or admin", you have two stories. Split them.

A good user story for the send-invoice feature looks like this:

As a solo consultant on our platform, I want to click Send on a draft invoice and have it emailed to my client from my own domain, so that I stop copy-pasting Stripe links into Gmail and so my clients see the email as coming from me, not from a SaaS tool.

Notice it's two sentences and contains zero technical decisions. Whether to use SendGrid or Resend, server-side send vs queue, React Email vs MJML, all of that is the engineer's call. They'll make it better than you would.

Where AI-assisted PRD drafting helps (and where it hurts)

Claude, Cursor, and ChatGPT are excellent at three PRD tasks and bad at a fourth.

Good at:

Generating edge cases. Paste your scope section and ask "what edge cases am I missing?" You'll get 15. Keep the 6 that matter.
Rewriting your dev-speak into user-stories. Paste your raw notes, ask for the user-story format. It does this in seconds.
Pressure-testing your success metric. "Is this success metric measurable in our existing analytics?" is a one-line prompt that surfaces gaps you'd hit two weeks into the build.

Bad at:

Defining the problem. The model will happily write a problem statement based on what sounds plausible. But you, the founder, are the only person who's talked to 30 customers. Don't outsource the problem definition. Outsource the formatting.

A workflow that holds up: draft the problem and user sections by hand, paste them into Claude, then ask it to draft scope, non-goals, edge cases, and dependencies. Edit aggressively. The first draft is 30% too long. Cut anything that says "comprehensive" or "robust".

If you don't have the patience for that loop, engineers on Cadence will write the PRD with you on day 1 of the booking. We've seen mid-tier engineers turn a 15-minute Loom into a complete PRD plus a working schema in the first afternoon. AI-native fluency (Cursor and Claude Code in the daily workflow) is the baseline of the platform, not a tier.

A working PRD: "Send Invoice" feature

Here's the entire PRD for the send-invoice feature, in the format we'd hand to an engineer on Monday morning.

PRD: Send Invoice from Draft

Problem. Users (solo consultants) create draft invoices in our app but then manually copy the Stripe payment link, open Gmail, find the client's email, and write a message. 3 to 5 minutes per invoice. 8 of 12 users we interviewed last week mentioned this unprompted.

User. Solo consultants and small agencies (1 to 5 people) sending 5 to 20 invoices per month, already using Stripe Connect through our app, currently sending follow-ups manually from Gmail.

Success metric. Average invoices sent per active user per week increases from 1.2 (current baseline as of last Tuesday) to 2.0 within 30 days of launch.

Scope.

"Send" button appears on any invoice with status draft and a populated client email.
Clicking Send opens a modal with a pre-filled subject and body. User can edit both.
On confirm, we send an email from invoices@<user-custom-domain> (fallback: invoices@oursaas.com) containing the Stripe payment link.
Invoice status changes to sent and timestamp is recorded.
User sees a toast confirmation and a "Sent" badge on the invoice.

Non-goals.

Reminder emails to clients (separate feature, Q3).
Multi-recipient invoices.
Custom email templates per client.
SMS notifications.
Bulk-send across multiple invoices.

Edge cases.

Invoice was already marked paid before send (block, show explanation).
Client email bounces (mark invoice as delivery-failed, surface in dashboard).
User clicks Send twice (idempotency key, only one email goes out).
Stripe API is down when generating link (retry 3x, then queue and show toast).
Custom domain not yet verified (fall back to default sender, warn user).
User edits subject or body to be empty (require both).

Dependencies.

Stripe Connect already integrated (done).
Resend account with verified domains feature (need to set up).
Email templates approved by legal (1-page review, request by Thursday).

That's the entire PRD. 320 words. An engineer on the Mid tier ($1,000/week) can ship it in 3 to 4 days including tests, assuming Resend setup is parallel.

PRD format comparison

Founders ask which template to copy. The honest answer: none, write your own from the seven sections above. But if you want to see how that compares to other formats, here's the landscape.

Format	Length	Best for	Worst for	Effort to write
Founder one-pager (this guide)	1 page, ~300 words	Solo founders, fast iteration, AI-assisted engineers	Compliance-heavy features (HIPAA, SOC2)	1 to 2 hours
Amazon-style six-pager	6 pages, ~2,500 words	Decision meetings, big-org alignment	Solo founder MVP, weekly shipping	1 to 2 days
Lean PRD (Marty Cagan style)	2 pages	Product teams with a designer + PM + engineer	Solo founders without designers	Half a day
Jira epic with stories	Variable, lives in tracker	Teams already on Jira at scale	Greenfield projects, anything pre-PMF	Ongoing
Linear "Project" doc	1 to 3 pages	Modern startup teams using Linear	Teams not on Linear	2 hours
Notion template (any of them)	Variable	Async cross-team handoff	When you want to actually ship this week	30 minutes

For 90% of founder-led, pre-Series-A features, the one-pager wins. The other formats are correct in their context and overkill in yours.

Common founder mistakes when writing PRDs

Five mistakes from non-technical founders, in order of frequency.

Writing the spec instead of the PRD. Database tables, frameworks, API design. Stop. The engineer (fluent in Cursor and Claude) does this in 20 minutes once they read your user stories.
No success metric, or three of them. One number, or you don't know if it worked.
No non-goals section. The most expensive omission. The engineer guesses generously, you get billed for 3 features when you wanted 1. Writing non-goals down before work starts is the single best way to handle scope creep as a founder.
Vague user definition. "Power users" don't ship features. Specific personas backed by the first 5 customers you should look for ship features.
No edge cases. Five is fine. Zero means launch-day bugs.

What to do this week

If you have a feature you want to ship in the next 14 days, do this in order.

Today: write Problem and User by hand. 20 minutes. No AI yet.
Tomorrow: paste those into Claude, ask it to draft Scope, Non-Goals, Edge Cases, Dependencies. Edit aggressively.
Day 3: write the one success metric, verify your analytics capture it. If not, fix that first.
Day 4: send the PRD to the engineer. They'll return 4 to 8 questions; that's healthy.
Day 5: revise. Now you have a real PRD.

If you don't have an engineer, the booking flow on Cadence shortlists 4 vetted engineers against your PRD in about 2 minutes, with a 48-hour free trial so you can hand them the doc and watch them work before money changes hands. Engineers self-select tier; a "send invoice" feature is firmly Mid ($1,000/week), maybe Senior ($1,500/week) if you want email-deliverability infrastructure built to scale.

If you're stuck between hiring a full-timer and going freelance for a 2-week build, book a Cadence engineer for the first week. 48 hours free, weekly billing, and you keep the PRD even if you don't keep the engineer.

For founders earlier in the journey who are still deciding whether to hire, contract, or co-found, the trade-offs are mapped in our pieces on fractional CTO vs full-time CTO and how to find a technical advisor for your startup.

FAQ

How long should a PRD be?

One page for most founder-led features. Two pages if compliance or third-party integration adds material constraints. If you're past three pages, you're writing the spec, not the PRD.

Do I need a PRD for every feature?

No. Anything that takes less than half a day or that's purely bug-fix work doesn't need one. Anything that takes more than a day, touches user data, or changes a price should have a PRD before the engineer starts.

Should I write the PRD in Notion, Linear, Google Docs, or something else?

The tool doesn't matter. Pick the one your engineer reads. Most engineering teams we work with read whatever you send them. Linear and Notion are the modern defaults. Google Docs is fine. The PRD's value is in the thinking, not the tool.

Can I have AI write my entire PRD?

Not the problem statement. Not the user definition. Not the success metric. Those three sections require you to have talked to real customers, which is something the model cannot do. Use AI for scope, non-goals, edge cases, and dependencies after you've nailed the human-only parts.

What happens if my engineer rewrites my PRD?

That's a good sign, usually. A senior engineer often reframes your scope into something cleaner. As long as the problem, user, and success metric stay the same, let them. If they're changing those, you have a misalignment and should talk before they keep building.

How does AI-native engineering change the PRD?

Less, not more, than you'd think. A clear PRD still gets you a clean build. What changes is the spec stage that follows: AI-native engineers can turn a tight PRD into a working schema, an API draft, and a UI scaffold in hours instead of days. The bottleneck moves from typing to deciding, which means a good PRD is more valuable than ever.

All posts