Pre-coding product definition

The PRD Prompt to Run Before You Write a Single Line of Code

One prompt that forces a product to be defined before it is built. You paste it, replace [project name], and get a requirements document that names the problem, the user, the journey, the smallest feature set, one success number, the constraints, and the decisions still open — then pressure-tests every feature against priority, effort, and the journey it serves.

Purpose

Why you run this before any code

The cheapest place to cut scope is a document, not a codebase.

Decide before you build

The prompt makes you commit to the problem, the user, and the single journey to first value up front — so the build has a target instead of a guess.

Make scope explicit

It forces an out-of-scope list and one 30-day success number, turning “what should we build?” into a bounded, testable set of choices.

Price every feature

Each feature carries a priority, an effort estimate, and the journey step it serves — so trade-offs are visible before engineering time is spent.

Catch scope creep early

A final check flags anything that sounds like a phase-2 feature wearing a phase-1 label, before it quietly enters the first build.

Paste-ready

The prompt

Copy it as-is and replace [project name] with your project. Change nothing else until it has answered every field.

PRD prompt

Create a Product Requirements Document for [project name].

Include:
- Problem statement: the exact user pain this solves in one sentence
- Target user: one specific persona (not "everyone")
- Core user journey: what the user does from signup to first value, step by step
- MVP feature list: only features required for that core journey. Nothing else.
- Out of scope: explicitly list what we are NOT building in v1
- Success metric: one number that tells us if this worked in 30 days
- Tech constraints: stack, integrations, third-party APIs required
- Open questions: things we need to decide before dev starts

For each feature in the MVP list, add: priority (P0/P1/P2), estimated complexity (S/M/L), and which user journey step it serves.

Flag anything that sounds like a phase 2 feature disguised as a phase 1 requirement.

Field map

What each field must answer

Every required field, and the test a good answer has to pass.

Problem statementThe exact user pain, in one sentence. If it needs two sentences, it is not sharp enough yet.

Target userOne specific persona — not “everyone”. The journey and features are only valid for this one user.

Core user journeyStep by step, from signup to first value. This is the spine everything else is measured against.

MVP feature listOnly the features required for that journey. Nothing else earns a place in v1.

Out of scopeAn explicit list of what you are NOT building in v1, so the exclusions are decisions rather than omissions.

Success metricOne number that tells you whether it worked in 30 days. One — not a dashboard of them.

Tech constraintsStack, integrations, and third-party APIs required — the real boundaries the build lives inside.

Open questionsThings that must be decided before development starts, named now instead of discovered mid-build.

Structural check

The gate: everything traces back to the problem

Read the finished PRD as one chain. If a link breaks, the scope is wrong — not the code.

Problem→ Journey→ Feature→ Priority→ Effort→ Metric

Every journey step exists to move the user through the stated problem toward first value.

Every MVP feature maps to a journey step. A feature that serves no step does not belong in v1.

Every feature carries a priority and an effort estimate, so its cost is visible next to its value.

The whole set has to be able to move the one 30-day success number. If it cannot, the scope is off.

Decision guide

Priority (P0/P1/P2) & effort (S/M/L)

Tag every feature on both axes. Priority says whether it ships; effort says what it costs.

Priority

Required for the core journey to reach first value. Without it, there is no product to test.

Strengthens the journey but is not required to reach first value. Build only if capacity remains.

Deferrable without blocking the journey. Explicitly parked, not silently dropped.

Effort

Small — well understood, contained, few unknowns.

Medium — moderate scope or a dependency to coordinate.

Large — significant unknowns or surface area. A P0 tagged L is the risk to plan around first.

Rule of thumb: a P0 marked L is where scope conversations should start — it is both required and expensive.

Final pass

Phase-2 disguised as phase-1

Before locking the MVP list, run every feature through these questions.

Scope check

Does it serve a step in the core journey to first value?→ If it maps to no step, it is not phase 1.

Would first value still be reachable without it?→ If yes, it is P1 or P2, not P0.

Is a “small addition” hiding a larger system?→ If the honest effort is L, treat it as phase 2 until proven otherwise.

Is it justified by scale you do not have yet?→ Needs that only appear at volume belong to a later phase.

Does it widen the surface area beyond the one journey?→ New platforms or audiences are phase 2 — prove the one loop first.