How to write your first PRD as a new PM

The hardest part of your first PRD usually isn't the writing. It's not knowing which of the fifteen things you could say actually need to be said — and which ones are just there because a template told you to include them.

A good PRD does three jobs at once: it gets everyone aligned on what you're building and why, it gives engineering enough to start scoping, and it gives you something to point back to when the inevitable "wait, I thought we were doing X" conversation happens in week three. If a section doesn't serve one of those three jobs, it's probably padding.

Start with the problem, not the solution

The single most common mistake in a first PRD is opening with the feature instead of the problem. "We're building a saved-filters panel" tells the reader what, but not why they should care or how to judge whether it's the right call.

Instead, open with what's actually broken today: who's affected, how often, and what it costs them (time, money, churn, support tickets — whatever's measurable). One or two tight paragraphs is enough. If you can't state the problem without mentioning your solution, you probably haven't separated the two yet.

The sections that actually matter

Every team's template looks slightly different, but underneath the formatting, these are the parts that carry real weight:

• Problem statement — what's broken, for whom, and how you know (data, quotes, support volume).
• Goals and non-goals — what this specifically will and won't solve. Non-goals are the most skipped and most valuable section in the whole document; they're what stops scope from quietly growing in every design review.
• Success metrics — the number that moves if this works, and roughly by how much. Vague success criteria are how "ship it and see" projects happen.
• User stories or scenarios — a handful of concrete "as a ___, I want to ___" cases, grounded in real usage patterns rather than hypothetical ones.
• Scope and out of scope — the explicit line. This is what engineering will actually scope against, so vagueness here costs you later, not now.
• Open questions — the things you genuinely don't know yet. Listing them isn't a weakness; pretending you have no open questions usually is.

Mistakes that are easy to make early on

A few patterns show up again and again in first-time PRDs:

• Writing solutions into the goals section. "Goal: build a dashboard" is a solution wearing a goal's clothes. The goal underneath is usually something like "reduce time-to-insight for weekly reporting."
• Skipping non-goals entirely. Without them, every stakeholder assumes their pet feature is in scope until someone tells them otherwise, usually mid-sprint.
• Success metrics that aren't measurable. "Improve user satisfaction" isn't a metric until it's attached to a number, a source, and a timeframe.
• Over-specifying the how. A PRD that dictates exact UI states and technical implementation usually means design and engineering had no room to do their actual jobs.

A simple structure to start from

If you're staring at a blank page, this order works for most first PRDs:

1. Problem statement
2. Goals and non-goals
3. Success metrics
4. User stories / key scenarios
5. Scope and out of scope
6. Open questions and risks

You don't need every section to be long. A tight, honest PRD that's two pages beats a comprehensive one that's twelve and unread. Write enough that someone who wasn't in the room could still make a reasonable decision from it — that's the actual bar.