Run a PM-led AI prototyping sprint before the PRD

Description

You are about to write a PRD for a feature you have not seen working yet, and the spec will lock the team into assumptions you have no evidence for. This runs a 3-day prototyping sprint where the PM uses AI tooling to build a clickable prototype, hand it to 5 users, and rewrite the PRD against actual reactions, not imagined ones.

You are a PM running a 3-day AI prototyping sprint for {{feature_name}}. Target user: {{target_user}}. Tooling available: {{ai_tooling}}.

## Day 1. Frame and prototype
Morning (3 hours):
1. Write the one-paragraph problem statement, the user, and the outcome you want
2. List the 3 core moments in the user flow (entry, key interaction, exit)
3. Sketch the screens (paper or whiteboard, not Figma yet)

Afternoon (3 hours):
4. Open an AI prototyping tool and build a clickable version of the 3 core moments
5. Hardcode realistic content (not Lorem Ipsum). The prototype must feel like a real product
6. Make sure the entry, the key interaction, and the exit each work end to end

End of day: prototype is clickable on a phone or laptop and your PM partner can use it without your help.

## Day 2. User test 5 people
Schedule 5 sessions of 30 minutes. For each:
1. Ask the user to do the task in the prototype with no setup
2. Stay silent for the first 60 seconds (let them stumble)
3. Note where they hesitate, where they expect something different, where they finish satisfied
4. End with: what would make this a 10 out of 10 for you?

After 5 sessions:
- List the 3 most repeated frictions
- List the 2 features users tried to use that the prototype did not have
- List the 1 thing every user lit up about

## Day 3. Rewrite the PRD against reality
Now write the PRD with evidence:
1. The problem statement (validated or revised based on Day 2 reactions)
2. The user flow (revised to remove the 3 frictions)
3. The features the prototype promised that the team must build
4. The features users wanted that we are deferring (with the reason)
5. The success metric, with the prototype's user test as the baseline
6. The killable risk: the one thing that, if it does not test better in beta, kills the feature

## Output
1. Clickable prototype URL
2. 5-session user test report (3 frictions, 2 missing features, 1 unanimous win)
3. Rewritten PRD anchored on Day 2 evidence
4. The killable risk and the test that would resolve it
5. The single feature most likely to be cut after engineering reviews scope

Customize This Prompt