PRD in product manager interviews

Why PRDs show up on PM interviews

A PRD (Product Requirements Document) is the load-bearing artifact of a product manager's week — the thing engineers, designers, and analysts read before they touch a feature. In an interview loop, asking you to write one in 30–40 minutes is the cheapest way to test whether you can hold a feature end-to-end: goals, user paths, edge cases, metrics, dependencies, and what you are explicitly not doing.

The exercise is not about formatting. PMs at Stripe, Linear, Notion, and Airbnb grade the clarity of thought, not the polish. They want to see whether you start from the user, connect actions to outcomes, and refuse to ship vibes-based goals. A good PRD lets engineering start without a single follow-up question. A bad one becomes a five-times-a-week Slack thread.

Three flavors of PRD task come up most often in product manager loops:

• Write a PRD for an abstract feature in 30–40 minutes (live exercise or take-home)
• Critique a pre-written PRD and find what is missing
• Defend a PRD verbally in front of a mock engineering team

The PRD skeleton interviewers expect

There is no universal template — every company writes its own — but the bones are stable across Google, Meta, and the late-stage startup crowd. The skeleton below is what you should reach for when an interviewer says "you have 30 minutes, go."

1. Title and owner — feature name, PM, date, status
2. TL;DR — three to five lines: what we are building, for whom, expected impact
3. Background and motivation — why now, what data justifies it
4. Goals — the desired change in state
5. Non-goals — explicit scope cap
6. Success metrics — primary, secondary, guardrail
7. User stories — scenarios in the "as a X, I want Y, so that Z" format
8. Detailed requirements — functional and non-functional
9. Acceptance criteria — what "done" means
10. Out of scope — what this release does not cover
11. Dependencies and risks — what you need from other teams, what could break
12. Open questions — anything still undecided

Not every section is mandatory for every feature. A small UX tweak fits on one page. A big bet — multi-quarter, multi-team — runs 5–10 pages. The skeleton is a checklist, not a quota.

Goals and success metrics

Goals

Goals are written as a change in state, never as a process. "Improve onboarding" is not a goal — it is a vibe. "Lift activation rate from 45% to 60% by end of Q3" is a goal: it has a number, a baseline, and a deadline.

Strong PM goals share three properties:

• Measurable — there is always a number
• Time-bound — there is always a deadline
• Strategy-linked — it serves a quarterly or yearly bet, not a personal hobby

A favorite interviewer probe: "What if two of your goals conflict?" The expected answer is to rank them explicitly — primary beats secondary — and, in the case of conflict, optimize the primary while keeping the secondary above its floor.

Success metrics

Goals and metrics are not the same. Goals are what you want; metrics are how you will know you got it.

A common failure mode is picking a primary metric that is trivially gameable — adding more cards on a screen and calling card impressions a "win." Interviewers will press on this. The defense is to pair the primary with at least one conversion or retention guardrail that catches the gaming behavior.

User stories and acceptance criteria

User stories follow the "as a [role], I want [action], so that [outcome]" format. The format is a scaffold, not a law — what matters is that every story makes the outcome explicit, not just the action.

A strong story:

A weak story:

The weak version has no outcome. It describes a UI element, not a user reason. Every user story should have acceptance criteria and a clear link to a success metric. If the link does not exist, either the story is filler or the metric is wrong.

Acceptance criteria — Given/When/Then

Acceptance criteria are the testable conditions for a story being done. The standard format is Given/When/Then:

Given a new user has just signed up
When they open the home screen for the first time
Then the app shows 5 recommendations
And the recommendations are based on the onboarding answers
And if no answers exist, the app shows popularity-based defaults
And the screen renders in under 200 ms on the median device

Interviewers grade three things on acceptance criteria:

• Edge case coverage — what if data is missing, what if the API times out, what if the user has no history
• Concreteness — never "fast response," always "under 200 ms"
• Testability — a QA engineer should be able to write a script for each line

The cheapest interview win is adding one edge case the candidate before you forgot — empty state, error state, or first-session-no-data.

Out of scope, dependencies, and risks

Out of scope

This is the list of things this release explicitly does not include. It is not laziness — it is the defense against scope creep, which is the single biggest reason features ship late or never. In a PM interview, a PRD with no out-of-scope section is graded as junior, period.

For a recommendations feature, a clean out-of-scope list looks like:

• No personalization based on social graph in v1
• No offline support in this iteration
• Not launching for the B2B segment

Dependencies and risks

Dependencies are what you need from other teams before you can start or ship. Naming them in the PRD is how you avoid the "we're blocked on ML" surprise the day before launch.

• ML team: ranking model ready by [date]
• Backend: /recommendations endpoint ready by [date]
• Design: final UI by [date]

Risks are paired with mitigations. A risk without a mitigation is just complaining.

The three PRD formats interviewers use

Format 1: Write a PRD in 30 minutes

Live or take-home. The prompt is usually "Write a PRD for feature X in product Y." The medium is a shared doc — Google Docs, Notion, or Linear.

What scores high:

• A visible skeleton — headings tell the reader the structure in one scroll
• Goals tied to metrics, metrics tied to user behavior
• User stories with concrete acceptance criteria
• An explicit out of scope
• Dependencies and risks, even guessed ones, with mitigations

You do not need to write a novel. One to two pages is plenty. Interviewers respect compression more than length.

Format 2: Critique someone else's PRD

You get a pre-written document and 15 minutes to comment. The typical defects are the same across every interview I have seen:

• Goals without metrics
• Metrics without guardrails
• User stories without acceptance criteria
• No out of scope (so scope is implicitly infinite)
• No dependencies (so blockers are hidden)
• No timeline

A strong critique groups defects by severity — load-bearing missing pieces first, polish second.

Format 3: Defend the PRD to a mock team

"You have 5 minutes. Explain to engineering why we are building this." The interviewer is watching how you talk about the product, not the doc. A strong pitch starts with the user and the problem, not the feature. A weak one starts with "we are going to build a button."

Common pitfalls

PRD without a TL;DR. Engineers read the first five lines and decide whether to keep going. If your reader cannot tell in 30 seconds what you are building and why, the document does not work. Always lead with a three-to-five-line summary that names the user, the problem, and the expected outcome.

Goals without metrics. "Improve the experience" is not a goal — it is a wish. Without a number, no one can tell whether you succeeded, and your launch retro becomes a vibes session. The fix is to attach a baseline and a target to every goal, even if the target is a rough estimate. A guessed number beats no number every time because it can be argued with.

Solutions disguised as requirements. "Use React Query" or "store user state in Redis" leaks implementation into the product layer. The PRD says "we need fast client-side updates"; engineering picks the tool. Crossing that line on an interview signals you do not trust your engineers — a red flag at senior levels.

No out of scope. Without this section, scope drifts and the feature triples in cost. Out of scope is not a list of things you forgot — it is the explicit fence you are building. Interviewers actively look for this section, and its absence is the most consistent reason mid-level candidates get dinged.

Ignoring non-functional requirements. Load time, accessibility, mobile constraints, internationalization. A feature can be "done" by every functional check and still be unusable on the median user's device. Always include at least one performance budget — for example, "p95 render under 300 ms on a 2019 Android device" — and one accessibility line.

Open questions hidden instead of named. Every non-trivial PRD has unresolved questions. Hiding them creates risk; listing them creates trust. A short "Open questions" section with three to five named uncertainties is a senior-PM tell — it shows you can sit with ambiguity instead of papering over it.

Related reading

• JTBD in product manager interviews
• Acceptance criteria — Given/When/Then for systems analysts
• Activation framework for product managers
• Guardrail metrics for A/B testing
• A/B testing for product managers

If you want to drill PRD critique and metric-design prompts every day, NAILDD is launching with 500+ PM interview cases built around exactly this pattern.

FAQ

How long should a PRD be?

Long enough that engineering can start without follow-up questions, and no longer. A small UX tweak fits on one page. A multi-team initiative may need five to ten. If your PRD exceeds ten pages, the most common cause is that you are smuggling implementation details or architecture diagrams into a product doc — push those into a separate technical design document and link to it.

Who writes the PRD — the PM alone or with the team?

The first draft is the PM's job — you cannot outsource the thinking. The final version comes after review with engineering, design, and analytics. A PRD that has not been reviewed by at least one engineer and one designer is almost always missing edge cases or constraints. Interviewers will sometimes ask "who did you write this with?" — name your reviewers if you have them.

How is a PRD different from a brief or a spec?

A brief is the one-page idea pitch, written before the PM has done discovery. A PRD is the detailed product document for engineering to build against. A spec, in the traditional sense, is the engineering design document that comes after the PRD and translates the product requirements into a technical plan. Some teams blur these lines, especially in early-stage startups, but in mature orgs the three artifacts have distinct owners and review cycles.

Should I include wireframes or mockups in a PRD?

Low-fidelity sketches that clarify the user flow — yes, almost always. High-fidelity Figma exports — sometimes, but link to the source rather than embedding heavy images. The rule is: include visuals only when prose cannot communicate the flow. A page covered in design crops with no commentary signals the PM did not think through the logic themselves.

What is the single biggest mistake junior PMs make on this exercise?

Spending 20 of the 30 minutes on background and motivation, then running out of time before acceptance criteria, dependencies, and risks. Reverse the budget: five minutes on context, twenty on goals/metrics/stories/criteria, five on out of scope, dependencies, and risks. The back half of the doc is where senior signal lives.