Start With a PRD: The Document That Saves Your Product Before You Build It
A Product Requirements Document sounds corporate. It isn't. It's the one thing that stops you from building the wrong thing, building too much, and losing months to confusion.
Every product I’ve seen go sideways — whether it was built by a team of twelve or one person with an AI and a weekend — had the same root cause. Nobody wrote down what they were actually building before they started building it.
The fix isn’t complicated. It’s a document. Specifically, a Product Requirements Document — a PRD. It sounds corporate. It isn’t. It’s two pages that answer the questions everyone on a project eventually argues about, written down before anyone writes a line of code or creates a single workflow.
If you’re building anything — an automation, an app, a product, a process — read this before you open your tools.
What a PRD Is
A Product Requirements Document is a written definition of what you’re building, who it’s for, what problem it solves, and what “done” looks like.
That’s it. Not a technical spec. Not a business plan. Not a wireframe deck. A clear, plain-English description of the thing you’re trying to create — before anyone touches anything.
The reason it matters: the moment you start building, you start making decisions. Small ones, fast ones, dozens of them per hour. Without a PRD, those decisions are made in the moment based on whatever feels right. They accumulate. Six weeks in, you’ve built something that sort of resembles what you intended but doesn’t quite solve the problem you started with.
A PRD gives every decision a reference point. When you’re not sure whether to include a feature, you check the PRD. When you’re debating how something should behave, you check the PRD. When someone asks what you’re building, you send them the PRD.
What Goes In It
A useful PRD doesn’t need to be long. Here’s the structure I use:
1. The Problem Statement
One paragraph. What problem exists right now, for whom, and why it’s worth solving? Not the solution — the problem.
Example (from building SendJob):
Field service businesses — HVAC, plumbing, electrical — manually send appointment confirmations, dispatch notifications, and payment requests for every job. A dispatcher or office admin does this by hand, dozens of times a day. Jobs get missed, customers go dark, payments are delayed. The cost is real but invisible because it’s been manual for years.
2. Who It’s For
Name the person. Not a demographic segment — a real type of person with a real job title and a real frustration. The more specific, the better your decisions downstream.
Example:
Small field service business operators (1–15 technicians) who manage dispatch themselves or with one office admin. They use a job management tool but nothing in it sends automatic notifications. They’re not developers. They want it to work without maintaining it.
3. What It Does
A numbered list of the things the product will do. Not features — behaviors. What happens when a user does X? What goes out when Y occurs?
Keep this to the core. If your list is longer than 8–10 items, you’re describing two products.
4. What It Does Not Do
This section is underrated. Explicitly listing what the product won’t do is one of the best tools for preventing scope creep. When someone says “but shouldn’t it also…” — you check this section.
Example:
- Does not replace a job management or CRM system
- Does not handle inbound customer messages
- Does not include a customer-facing portal
- Does not generate invoices
5. Success Criteria
How will you know it’s working? Be specific. Not “customers are happy” — what measurable thing changes?
Example:
- Confirmation text is sent within 60 seconds of a new job being created
- Payment link is delivered the moment a job is marked complete
- Zero manual touchpoints required for jobs that follow the standard flow
6. What’s Out of Scope (Version 2.0)
Every idea that came up during the PRD process that isn’t in version 1 goes here. Not rejected — deferred. This list is valuable. It’s your roadmap and your scope protection in one place.
Why Solo Builders Skip It (And Pay for It)
When you’re building alone, especially with AI, the PRD feels unnecessary. You know what you’re building. You don’t need to write it down for yourself.
Here’s the problem: your idea at the start of a project and your idea at week four are not the same idea. The build changes it. Decisions change it. New possibilities change it. Without a document anchoring what you originally intended, you drift — and you often don’t notice until you’ve built something much bigger and less focused than what you needed.
The other problem: building with AI is fast. That speed is the point, but it also compresses the time available for reflection. A PRD forces you to slow down once, at the start, so you don’t have to stop and rethink in the middle.
How to Write One With AI
The fastest way to write a PRD if you’ve never written one:
Open a conversation with Claude or your AI of choice and say something like:
“I’m building [describe your product in two sentences]. Help me write a Product Requirements Document. Ask me the questions you need to fill in the problem statement, who it’s for, what it does, what it doesn’t do, success criteria, and what’s deferred to version 2.”
Let it interview you. Answer the questions. It will draft the document from your answers. Read it carefully — especially the “what it doesn’t do” section, because that’s where it will surface assumptions you haven’t made explicit.
The PRD you get from that conversation will be better than the one you’d write from scratch. Edit it until it’s accurate. Print it or pin it somewhere you’ll see it every session.
The Rule
Before you build anything, answer these six questions in writing:
- What problem does this solve?
- Who has that problem?
- What will the product do?
- What will it explicitly not do?
- How will I know it worked?
- What am I deferring to version 2?
Two pages. One hour. It will save you weeks.
This is Part 1 of a 4-part series on building and launching your first product. Next: What Is an MVP — and Why Your First Version Should Disappoint You a Little.
Subscribe below to get each part as it drops.