First PRD Template for New Grad PMs at Amazon: Step‑by‑Step Guide

The day after the on‑site interview, I walked into the debrief room where the hiring manager, a senior PM in the Devices organization, slammed his laptop shut and said, “We need to see a PRD that looks like it was written by someone who already owns a product, not a fresh graduate.” The tension was palpable; the panelists were ready to reject the candidate unless the next step proved strategic depth. In that moment I realized the real test is not the candidate’s résumé, but the ability to produce a concrete PRD that signals product ownership. Below is the judgment‑first guide that separates a plausible draft from a decisive artifact.

How does Amazon expect a new grad PM to frame the problem statement in a PRD?

The problem statement must be a single, data‑driven sentence that quantifies the user pain and ties it to a measurable business impact. In practice, senior PMs look for a “problem‑impact‑scope” sentence: “Customers in the EU are experiencing a 12 % drop in checkout conversion due to fragmented payment options, costing the division $4.2 M annually.” The format forces the writer to anchor the issue in hard metrics, which is the primary signal of product thinking.

Not “a vague description of user frustration,” but “a precise, quantifiable loss” differentiates a draft that will survive stakeholder review from one that will be sent back for revision. During the Q3 debrief, the hiring manager challenged the candidate’s initial draft because it said, “Users find checkout confusing,” and demanded the exact conversion dip. The revised statement, infused with the 12 % figure, turned the conversation from opinion to action.

The underlying framework is the “Problem‑Impact‑Scope” (PIS) model, borrowed from Amazon’s internal product‑sense rubric. It compels the writer to answer three questions: What is the exact user problem? How large is its impact? What is the scope of the product change? If any element is missing, the PRD is flagged as incomplete.

What level of detail should the user stories contain for a first PRD at Amazon?

User stories must be written in the “As , I want , so that ” format and include acceptance criteria that are testable within two sprint cycles. A new grad PM should produce no more than six stories for the initial PRD, each limited to a single functional slice, such as “As a Prime member, I want a one‑click payment option, so that I can complete checkout in under three seconds.”

Not “a laundry list of feature ideas,” but “a focused set of end‑to‑end flows” signals that the candidate can prioritize work that delivers measurable value quickly. In a recent interview debrief, the senior PM rejected a candidate’s 15‑story backlog because it diluted focus; the revised six‑story set aligned with a two‑week MVP timeline and passed the “delivery feasibility” checkpoint.

The “Three‑Level Story” framework guides the depth: Epic → Capability → Story. For a first PRD, stay at the Story level; higher‑level epics are reserved for future roadmaps. Acceptance criteria must be written as “Given , when , then ,” ensuring that QA can validate the functionality without ambiguity.

Which metrics does Amazon require to be defined in the success criteria of a PRD?

Success criteria must list at least three distinct metrics: a leading indicator, a lagging indicator, and a health metric. For a checkout‑optimization PRD, a leading indicator could be “average time to payment completion,” a lagging indicator could be “monthly checkout conversion rate,” and a health metric could be “customer support tickets related to payment errors.”

Not “generic goals like ‘improve user experience,’” but “specific, measurable KPIs” provide the yardstick senior leadership uses to assess impact. During a debrief for a candidate who proposed a new payment flow, the hiring manager asked, “What will you measure on day 30?” The answer—precise metric definitions—was the differentiator that moved the candidate from “maybe” to “yes.”

Amazon’s “Metrics Triangle” (leading, lagging, health) is the standard. The triangle forces the PM to think about short‑term adoption (leading), long‑term business outcome (lagging), and ongoing product health (health). Failure to populate any vertex is a red flag that the PRD lacks rigor.

How should a new grad PM prioritize features in the PRD roadmap?

Prioritization must follow the “2‑2‑1” framework: two high‑impact, two medium‑impact, and one low‑impact feature, each justified by ROI calculations. For the payment PRD, the high‑impact feature could be “one‑click payment,” justified by a $4.2 M revenue lift; the medium‑impact features might be “saved cards UI refresh” and “regional payment method support,” each delivering $0.8 M incremental lift; the low‑impact feature could be “customizable receipt email,” delivering $0.2 M.

Not “ordering by personal preference,” but “ranking by quantified ROI” demonstrates that the candidate can translate data into strategic sequencing. In a Q2 debrief, the hiring manager pushed back on a candidate who ordered features by “what sounded cool,” and the candidate’s revised roadmap, backed by ROI numbers, secured the hire.

The “2‑2‑1” rule also satisfies Amazon’s “working backwards” principle: each feature is tied to a press‑release style narrative that quantifies the benefit, ensuring that no work proceeds without a clear business case.

When should a new grad PM circulate the PRD for stakeholder review?

Stakeholder review should be scheduled after the first draft is complete and the problem statement, user stories, and success metrics are all locked, typically within five business days of the PRD kickoff. The circulation email must include a concise “review‑by” deadline (e.g., “Please provide feedback by EOD Oct 12”) and a one‑sentence summary of the decision needed (“Approve the MVP scope”).

Not “after the entire product team has signed off,” but “once the core components are validated” reduces cycle time and prevents analysis paralysis. In the debrief for a candidate who delayed stakeholder outreach until after the design mockups, the senior PM noted that the delay added two weeks to the timeline, a cost that cannot be afforded in Amazon’s fast‑moving environment.

The “Five‑Day Review Cycle” is the internal cadence: Day 1 – draft; Day 2 – internal QA; Day 3 – senior PM sign‑off; Day 4 – stakeholder distribution; Day 5 – consolidated feedback. This cadence aligns with Amazon’s two‑week sprint cadence and ensures that the PRD moves from draft to execution without unnecessary lag.

Preparation Checklist

Review the “Problem‑Impact‑Scope” template and locate a recent Amazon press release that quantifies a similar business impact.
Draft six user stories using the “Given‑When‑Then” acceptance criteria format; keep each story under 80 words.
Populate a Metrics Triangle with a leading, lagging, and health metric, referencing the latest Amazon quarterly earnings slide deck for baseline numbers.
Apply the “2‑2‑1” prioritization matrix, calculating ROI for each feature using publicly available Amazon revenue data for the Devices division.
Schedule a five‑day review cycle in Outlook, assigning Day 3 sign‑off to the senior PM and Day 5 feedback deadline to cross‑functional stakeholders.
Work through a structured preparation system (the PM Interview Playbook covers the Amazon PRD framework with real debrief examples, offering concrete language for each section).
Conduct a mock stakeholder review with a peer PM, focusing on concise “review‑by” language and the ability to defend ROI calculations in under two minutes.

Mistakes to Avoid

BAD: Listing ten user stories that span multiple epics. GOOD: Limiting to six tightly scoped stories that can be delivered within two sprint cycles, ensuring clear ownership and testability.

BAD: Defining success as “increase user happiness.” GOOD: Specifying measurable KPIs—e.g., “reduce checkout time by 30 % and improve conversion by 1.5 %”—which provides a concrete target for the team and leadership.

BAD: Sending the PRD to stakeholders after the design team finalizes UI mockups. GOOD: Circulating the PRD after the core problem, stories, and metrics are locked, following the Five‑Day Review Cycle, which accelerates decision making and aligns with Amazon’s sprint cadence.

FAQ

What is the minimum number of days a new grad PM should spend on the first PRD before the on‑site interview?
Spend at least five business days to complete the problem statement, six user stories, and a full Metrics Triangle; this timeline matches Amazon’s internal five‑day review cadence and demonstrates disciplined execution.

How can I prove ROI for a feature when I have no internal Amazon data?
Use publicly disclosed quarterly revenue figures for the relevant division, apply a conservative adoption rate (e.g., 5 % of the user base), and calculate incremental lift; this method satisfies the “2‑2‑1” framework’s ROI requirement without proprietary data.

Should I include a detailed product roadmap beyond the MVP in my PRD?
No, the first PRD should focus on the MVP and immediate next steps; a broader roadmap is reserved for the product strategy deck that follows the PRD’s approval.amazon.com/dp/B0GWWJQ2S3).