Why 'write a PRD for a notifications feature' gives you garbage

I've shipped three products as a solo founder, and the last one crossed $40k MRR before I hired anyone. For most of that I wrote PRDs alone, at 11pm, after support tickets. So when I say the way most people prompt an LLM for a PRD is broken, I'm not theorizing. I did it the broken way for a year. The broken way looks like this: 'Write a PRD for a notifications feature.' That's the prompt. The model dutifully returns four pages — goals, user stories, a wireframe description, success metrics, the works. It looks like a PRD. It reads like a PRD. And it's useless, because the model invented your users, invented your scope, invented whether this is in-app or email or push, and invented success metrics for a product it has never seen. A PRD prompt generator's actual job isn't to write more PRD. It's to force the decisions you've been avoiding to the surface before the model writes a word. Who is this for — the admin or the end user? Is the v1 in-app only? What's explicitly out of scope? What does 'done' look like in a number? When those answers are in the prompt, the model stops guessing and starts drafting something your team can actually build. I tracked this on my own backlog in February 2024: prompts with that structure cut my PRD-to-engineering-approved time from about three days of back-and-forth to under half a day.

The six things every PRD prompt has to contain

Here's the skeleton I put into every PRD prompt now. Skip any line and the model fills the gap with a confident guess: - The problem in one sentence — not the solution, the problem the user has - Who the user is, specifically (the billing admin, not 'the user') - The one success metric that decides if this shipped or failed - Scope: three bullets of what's in v1 - Non-goals: three bullets of what is explicitly NOT in v1 - The riskiest assumption you're making That's six lines. The generator asks for them up front, then assembles a prompt that produces a spec instead of an essay. Does writing the non-goals feel like wasted effort when you're in a hurry? Every single time. But the non-goals are the most valuable lines in the whole document, because a PRD without non-goals is an invitation for scope creep, and scope creep is how a two-week feature becomes a two-month one. I learned that the expensive way on a feature I called 'simple search' that ate six weeks because I never wrote down what search would NOT do.

The mistake that costs you a sprint: confusing the problem with the solution

This is the one that actually burns money. A founder writes 'PRD: add a Kanban board' and hands it to the model. The model writes a beautiful Kanban spec. Three weeks later engineering ships a Kanban board and nobody uses it, because the real problem was 'users can't tell what's blocked' — and a Kanban board was just the first solution that came to mind at 11pm. The model can't catch this for you if you've already baked the solution into the prompt. Garbage problem statement in, polished garbage out. I think this is the single most expensive prompt mistake in product work, more expensive than any hallucination, because hallucinations get caught in review and bad problem framing ships. The PRD prompt generator pushes back here in a way a blank ChatGPT box never will. When I paste a solution-shaped request, it asks: what problem does this solve, and how do you know users have it? That question alone has killed two features for me before I wrote a line of code — features I was excited about, which is exactly why I needed something to ask. The generator made me write the problem first and the solution second, and twice the solution I'd assumed turned out to be wrong. Here's the honest trade-off, though: this won't work if you lie to yourself in the answer. The tool can only ask the question; it can't know your users better than you do, and a confident wrong answer produces a confident wrong PRD. So treat its questions as a forcing function, not an oracle. The act of separating problem from solution, on paper, before engineering reads it, is worth more than any template. The PRD prompt generator can't make you honest, but it can make you write the problem down where you'll have to look at it — and most of the time that's enough to catch yourself.

PRD tools I tried before building my own prompt workflow

I ran through about six tools before I settled on a prompt-first workflow. Quick honest notes, because the marketing pages won't tell you this. Notion AI is fine for turning a doc into prose, but it doesn't ask you anything — it just expands whatever you give it, so a vague input becomes a vague three-pager. Linear's project docs are great for tracking but they're not opinionated about PRD structure. I tried two dedicated AI PRD startups in 2023; both produced generic specs that read like they were written for a company that doesn't exist, because they didn't pull in my context. Jira's Confluence templates are structured but soul-crushing, and nobody on a two-person team fills out fourteen fields. What actually worked was treating the PRD as a prompt-engineering problem. The value isn't a fancy editor — it's the questions asked before the writing starts. That's a contrarian take, I know. I'd rather have a plain text prompt that forced me to name my non-goals than a beautiful Notion template I fill in on autopilot. Is a dedicated PRD app worth $20 a month if it doesn't ask better questions than a free prompt? In my experience, no.

The prompt structure that makes a model write like a senior PM

A good PRD prompt reads like a brief, not a wish. The structure I use, and the one the generator produces: 1. Context: what the product is, who uses it, in two sentences 2. The problem and the evidence it's real 3. The single success metric 4. In-scope, ranked 5. Out-of-scope, explicit 6. Open questions the PRD should flag, not hide Notice point six. Most generated PRDs pretend everything is decided, which is a lie that costs you in the build. A senior PM surfaces the open questions instead of papering over them. The generator bakes that in: it asks the model to end the PRD with a 'decisions still needed' list rather than inventing answers. You front-load the thinking, the model front-loads structure, and what comes out is something an engineer reads and says 'okay, I can build this' instead of 'wait, what about...'

A small benchmark: vague PRD prompt vs structured one

I ran this last month because I was tired of guessing whether the structure actually helped or whether I just liked typing more. Feature: 'add team billing so a workspace owner can pay for everyone.' I generated a PRD ten times from a one-line prompt, and ten times from a structured prompt (same model, Claude). I scored each on whether an engineer friend could estimate it without asking me a clarifying question. Vague prompt: 2 of 10 were estimable without questions. The rest left seat counting, proration, and what happens when a member leaves completely undefined — the model just didn't mention them. Structured prompt: 9 of 10 were estimable. The structured prompt named the proration behavior, the seat model, and the downgrade edge case, because the non-goals and scope lines forced those decisions out of me before the model wrote anything. The difference wasn't the model getting smarter. It was me being forced to decide proration before drafting instead of discovering the gap in sprint planning. That gap, found in planning, is a five-minute conversation. Found in a sprint, it's a re-estimate and an awkward standup. I'll spend the four extra lines every time.

Worked example: a vague Slack thread became a real PRD in 10 minutes

This is where the generator earns its keep, because the rawest PRD input on earth is a Slack thread where three people half-agreed on something. Real input I pasted in March: a thread where my cofounder, a customer, and I went back and forth about 'letting people export their data.' No structure, three opinions, one angry customer. The PRD prompt generator refused to spit out a PRD from that. It asked four questions: who is asking for export — all users or just enterprise, what format do they actually need, is this a compliance requirement or a nice-to-have, and what happens to exports of deleted data? When I answered — 'enterprise admins, CSV and JSON, it's a SOC 2 blocker, deleted data is excluded' — it built a prompt that produced a PRD with the compliance framing front and center and a clean non-goals list. Total time from messy thread to a spec my engineer estimated without a single follow-up: about 10 minutes, most of it me answering the four questions. The questions were the work. The generator just made me answer them before the thread turned into a half-built feature nobody had actually specced. Could I have asked myself those four questions? Sure. Did I, the dozen times before this? No — that's the whole point of having something that asks.