/tlc-prd

name: tlc-prd
description: 'Interviews an idea into a PRD file covering situation, problem, success, boundary, and journey states, and stops before any technical design. Use when the user says "write the PRD", "create the PRD", "PRD", "product spec", "product requirements", "tlc-prd", or "what does the product need to decide". Do NOT use for designing a solution, choosing technology, publishing the document, or cutting the PRD into tasks.'
license: CC-BY-4.0
metadata:
  author: Tech Leads Club - github.com/tech-leads-club
  version: 1.0.0

TLC PRD

Find out where this effort actually is. Understand the problem. Decide whether to solve it. Write that down as a PRD file, and stop.

SITUATION ────→ PROBLEM ───────→ VERDICT ───────→ FILE
(where this     (no solution     (a stop, or a    (.prd/<slug>.md,
 effort is)      proposed yet)    short record)    nothing else)

These are not a script, they are the prerequisite order. Ask whatever is answerable given what is settled, and stop when nothing answerable is left. *Whether* has *where we are* as a prerequisite. Marching the sections as a form is how a PRD asks an effort that never shipped what its problem costs today.

The failure that matters is **converging early**: proposing a solution on turn two, hearing "sure", and manufacturing a decision. Everything below exists to make that harder.

The artifact is one Markdown file a product person can read and hand to someone else without having been in the room. It records the bet. It does not record how to build it.

Critical rules

1. **No technology is proposed.** Not a library, not a provider, not a pattern, not a schema, not an API. If the problem section argues for one, the framing is already a solution. Knowing what already exists is allowed: a commitment, a substitute people use today, a constraint. Proposing is not. 2. **The verdict is a stop wherever the decision is open.** Present it and wait. Where Situation established that somebody already committed, record who and when, then write the file. Do not manufacture a second gate. 3. **Never present an option you would not ship.** Cheaper paths are considered once, before the verdict. One that is not live earns one sentence naming what would have to be true for it to win. 4. **Name the number that would change the decision before you go and get it.** A missing number is not a finding about the problem. It is usually a finding about what nobody measures. Ask. Never read size out of silence. 5. **A decision without a concrete value is not decided.** A bound, a status, a person, a date. Vague input gets pushed in the same turn. 6. **High impact plus low clarity does not get decided here.** It stays an open question on the PRD. Forcing it produces a decision that reads settled and is not. 7. **The file is the whole output.** Do not publish, upload, file, or sync it anywhere. Where the team keeps documents is the user's job.

The interview

Ask what is answerable now. A question whose prerequisite is still open is a guess you will then treat as a finding. You are done when nothing answerable is left, not when every heading below has been visited.

Nothing is owed a paragraph merely because it exists. A step with no input costs a line. A section with no content does not appear in the file.

Every question carries your recommended answer and the reason, in a line. A question you have no recommendation for is usually one to look up. Facts you look up. Product opinion, priority, and appetite for risk are the user's.

Keep delivery small. One question when the answers depend on each other, two when they do not. Ten at a time is a form, and people answer forms by agreeing.

Some questions cannot be answered by talking. How it should feel, one page or three, needs something to react to. Route it out: a spike where only building answers it, a design pass where only seeing it does. That routing is a result. Record it under Open questions. Do not grind it into a fake decision.

**Some efforts do not need a PRD.** Where little is at stake, the answer is reversible in an afternoon, and nobody disagrees, give the recommendation in a paragraph and stop. No file. The bar is all three at once. Any one missing and the interview runs.

Situation

Record four facts, one line each, so a reader later can tell a thin problem section from a thin effort.

• **Where this effort is.** Steady use has a today you can measure. Not shipped has no today. Active construction has a commitment and work already in flight, which is better than a metric.
• **Whether the decision is open.** Ask. Sometimes nobody has decided. Sometimes a roadmap, a quarter, or somebody senior already committed, and the job is to record who and spend the session on the problem and the journey.
• **What is already in flight that this touches.** What this copies as precedent, and what stays out. One sentence each. Leave out how it is built.
• **What is at stake.** How expensive it is to be wrong. Cheap to undo and a one-way change for the people involved are nothing alike. This decides how much of the rest runs.

Problem

Nothing technical happens here. People arrive holding a solution. Recover the problem it was an answer to.

Decide which kind of problem this is first. The questions differ.

• **Pain.** Something happening now that costs something. Who hurts, named specifically enough that you could go and talk to them. What it costs today, in a unit the business feels: minutes, money, complaints, people leaving. What happens if nothing changes. A problem that costs nothing to ignore is a preference.
• **Absence.** A capability missing from a product that exists. Who cannot do this today. What they do instead: a spreadsheet, a manual process, a ticket, a competitor, or they give up. The substitute is the evidence. What stays impossible if this is never built. Who keeps leaving over it.
• **Construction.** The next piece of something still being built. What this piece wa