# How to Write a Product Requirements Document as a Non-Technical Founder
I once reviewed a PRD that a founder had sent to a development agency. It was 80 pages long, full of detailed UI descriptions, pixel measurements, and color specifications. The agency sent back a proposal for $340,000. The founder was shocked by the price.
I read the PRD and found the real problem: 80 pages on how the product would look, and almost nothing about what problems it actually needed to solve. The agency had to guess at the business logic and priced in maximum uncertainty.
We rewrote the PRD in 12 pages focused on outcomes and user goals. The revised proposal came back at $140,000 - and that product actually got built.
A good PRD is not about describing every pixel. It's about communicating what you want the product to do clearly enough that a developer can make good decisions without constant clarification.
What a PRD Is Actually For
Non-technical founders often think a PRD is a document for developers. That's only partly true.
A PRD is primarily a forcing function for your own thinking. Writing down what you want forces you to resolve ambiguities you didn't know existed. "Users can search for products" seems clear until you try to write it precisely: search by what fields? What happens when there are no results? Do we search partial matches? Is search case-sensitive?
The act of writing the PRD is where you discover the hard product questions. Discovering them in a document is cheap. Discovering them after 8 weeks of development is expensive.
A PRD also serves as a shared reference that prevents the "telephone game" that degrades clarity as a project goes on. When your developer makes an assumption three months into the project, you can both refer to the PRD to check whether that assumption is right.
The Structure That Works
Skip the templates with 20 sections. Here's the structure that works for most startup PRDs.
The Problem Section
One to two paragraphs describing the problem you're solving and who has it. Not the solution - the problem. "Small construction companies lose track of which subcontractors are on-site, which causes timesheet errors and billing disputes" is a problem statement. "We are building a mobile app for construction site management" is a solution statement.
The problem section should be so clear that a developer who reads it understands why you're building this, not just what you're building.
User Stories
This is the core of your PRD. User stories follow the format: "As a [type of user], I want to [do something] so that [I achieve a goal]."
Write one user story for every meaningful thing a user can do in your product. Group them by user type if you have multiple types (buyers and sellers, managers and workers, etc.).
User stories should describe behavior from the user's perspective, not technical implementation. "As a buyer, I want to receive an email when my order ships so that I know when to expect it" is a good user story. "The system should send an SMTP notification to the user's registered email address when the order_status field changes to 'shipped'" is an implementation specification, not a user story.
Keep each user story to one sentence. If you can't describe a feature in one user story sentence, it's either too complex (break it down) or too vague (make it more specific).
Acceptance Criteria
For each user story, write the specific conditions that must be true for you to consider it done.
"As a user, I want to reset my password" needs acceptance criteria like: user receives a reset email within 2 minutes, reset link expires after 24 hours, old password stops working immediately when new password is set, user is redirected to login after successful reset.
These criteria eliminate ambiguity. Your developer doesn't have to guess what "password reset" means - it means exactly what the acceptance criteria describe.
Edge Cases and Error States
This section is what separates a complete PRD from an incomplete one, and it's what non-technical founders most often skip.
For every major feature, ask: what happens when it goes wrong? What if the user enters invalid data? What if a third-party service is unavailable? What if the user tries to do something they're not allowed to do?
"User can't log in" leads to: wrong password (how many attempts before lockout?), account doesn't exist (show error? suggest registration?), account is deactivated (what message?), server error (what message?).
Edge cases and error states are often 30-40% of the total development work on a feature. If you don't specify them, your developer will handle them inconsistently - some will get good error messages, some will get crashes, some will silently fail.
Out of Scope
Explicitly list what you are not building in this version. This prevents scope creep and protects you in fixed-price contracts.
"Out of scope for V1: mobile apps, internationalization, user-to-user messaging, bulk import of historical data." This tells your developer not to architect for these things now, and it gives you a clear answer when someone asks why a feature isn't included yet.
Common Mistakes That Cost Months
Specifying UI instead of behavior. Non-technical founders often describe their product in terms of what it looks like: "there should be a button here, and it should be blue, and when you click it a modal opens." This tells your developer nothing about what the button does. Describe behavior, not UI. The UI is something to design together once the behavior is agreed.
Writing requirements as features instead of problems. "Add a notification system" is a feature. "Users need to know when someone replies to their comment so they don't miss important feedback" is a problem. Problems give your developer context to make good implementation decisions. Features don't.
Mixing must-haves with nice-to-haves. Every requirement in your PRD should be marked as either mandatory for launch or optional. If you can't ship without it, it's mandatory. If it would be nice but you can validate your idea without it, it's optional. Unmarked requirements will be treated as mandatory by default, which inflates your cost and timeline.
Writing it once and never updating it. A PRD is a living document. As you learn more about your users, as you get developer feedback on feasibility, as you change your mind about priorities - update the PRD. A PRD that diverges from what's being built becomes useless.
How Long Should It Be
For most early-stage products: 8-15 pages. Not 2 pages (that's a pitch deck, not a spec). Not 80 pages (that's over-engineering the documentation).
The right length is the minimum that resolves all meaningful ambiguities. If two developers could read your PRD and independently build the same product, it's long enough. If they'd build two significantly different products, it needs more detail.
One practical test: after you've written it, have someone who doesn't know your product read it and list the three questions they have. Answer those questions. Repeat until a new reader has no questions about core functionality.
That document is ready to share with developers.
Book a 30-minute call: https://calendly.com/alpsf/zoom-with-aleksandr