Prompt Engineering for Product Managers: Before and After

Before: The Weak Prompt

Picture this: you're a product manager at a 60-person startup, it's 4:45pm on a Thursday, and you need a PRD draft before tomorrow's roadmap review. You open your AI tool and type:

Write a PRD for a new notification settings feature.

Ten seconds later you have two paragraphs of generic filler about "improving user engagement" and a bulleted list that could describe literally any feature ever built. You paste it into your doc anyway because it's 4:47 now, and you spend the next 40 minutes rewriting it from scratch. Sound familiar?

Why It Fails

This prompt fails for the same reason a one-line Jira ticket fails: it has no constraints, no context, and no definition of done. The model doesn't know your user segments, your current notification system's limitations, or what "success" looks like for this specific feature. So it fills the gaps with the most generic PM-speak it can generate.

There's also no mention of format. PRDs at different companies look wildly different — some want user stories, some want a problem statement and acceptance criteria, some want a full RICE score breakdown. Without specifying which shape you need, you get whatever shape is statistically average across every PRD template on the internet, which is to say, none of them well.

⚠️ Common mistake: PMs often assume the AI "knows" their product because they've discussed it in previous chats. Unless you're in the same conversation thread with that context still active, every new prompt starts from zero.

A product lead at a B2B marketplace ran into this exact issue after switching between two different chat sessions — she'd spent an hour earlier that week explaining her platform's architecture, then opened a fresh chat the next day and got a PRD suggesting a feature that directly contradicted a technical limitation she'd already flagged. Nothing was wrong with the model. It genuinely didn't have that context anymore, and she'd forgotten it wouldn't carry over.

The fix isn't complicated, but it's easy to skip when you're in a hurry: paste the relevant context back in every time, even if it feels repetitive. A short "reminder" paragraph at the top of your prompt — two or three sentences about the product and its current constraints — costs you thirty seconds and saves you from a PRD built on stale assumptions.

After: The Improved Prompt

Here's the rebuilt version, based on a template a senior PM at a logistics SaaS company now uses for every first-draft PRD:

Act as a senior PM drafting an internal PRD (not customer-facing docs).

Context: [PRODUCT], used by [USER SEGMENT, e.g. "warehouse ops managers checking shipment status 10-15x/day"].
Current problem: [SPECIFIC PROBLEM, e.g. "users miss critical delay alerts because all notifications look identical"].
Constraint: [e.g. "must ship within existing notification infrastructure, no new backend service"].

Structure the PRD as:
1. Problem statement (2-3 sentences, cite the specific user pain above)
2. Goals and non-goals (explicit — what this feature will NOT do)
3. User stories (3-5, format: "As a [user], I want [goal], so that [benefit]")
4. Success metrics (specific, measurable, with a rough target number)
5. Open questions for engineering

Keep it under 600 words. Flag any assumption you're making with [ASSUMPTION: ...].

What this does: it gives the model a real constraint to reason within (existing infrastructure, specific user segment) instead of an open-ended blank page, and the "flag assumptions" instruction surfaces the model's guesses instead of letting them hide inside confident-sounding sentences nobody double-checks before the doc ships.

⚡ Pro tip: The non-goals section does more work than people expect. Explicitly telling the AI what the feature won't do prevents scope creep from sneaking into your user stories.

Breaking Down Each Element

The "act as a senior PM" framing isn't magic, but it does bias the output away from marketing copy and toward internal documentation tone, which matters when this doc is going straight into engineering's backlog. A director of product at a healthtech company said dropping this line from her prompts caused the AI to slip into "here's why this feature is exciting" language that had no place in an internal spec.

The context block — product, user segment, current problem — is what actually eliminates the generic filler. Notice it's not "users want better notifications." It's "warehouse ops managers checking shipment status 10-15x/day miss critical delay alerts." That specificity gives the model something real to write user stories against, instead of a vague benefit statement it has to invent supporting detail for.

The constraint line matters more than most PMs give it credit for. A product lead at a fintech company told me her team's biggest recurring problem was AI-drafted PRDs proposing solutions that ignored existing technical debt — new services, new vendors, things her engineering team would immediately reject. Naming the constraint upfront stops the model from suggesting a rebuild when you need a patch.

⚡ Pro tip: If you already have a rough success metric in mind, include a target number even if it's a guess. "Reduce missed-alert support tickets by roughly 30%" gives the model an anchor; "reduce missed alerts" gives it nothing to reason about.

⚡ Pro tip: Ask for open questions for engineering as a required section. It turns the AI into a checklist generator for gaps in your own thinking, which is often more useful than the PRD text itself.

Variations for Different Contexts

For a growth PM validating a smaller experiment rather than a full feature, drop the full PRD structure and ask for a one-page experiment brief instead: hypothesis, target metric, sample size consideration, and rollback plan. The same context-block habit — real user segment, real current problem — still applies, just compressed.

For a technical PM writing specs that go straight to a backend team, add a line requesting explicit API or data model implications: "Note any new fields or endpoints this would require, without designing them." This keeps the PRD in scope while still giving engineering a head start on scoping their own estimate, instead of discovering the data model gaps midway through a sprint.

⚠️ Common mistake: Copy-pasting the same PRD template across a consumer feature and an enterprise B2B feature. The audience section needs a genuinely different shape — "casual weekend users opening the app 2x/month" reasons completely differently than "IT admins provisioning accounts for 200 employees," and a template that doesn't account for that difference will quietly produce user stories that sound fine but solve the wrong problem for that particular buyer.

A third variation worth building: for a platform PM writing specs consumed by other internal teams rather than external users, swap the "user stories" section for "consumer team stories" — "As the billing team, we need X exposed, so that we can Y." It's a small rewording that keeps the same structure useful even when your actual customer is another engineering team down the hall rather than someone paying for the product.

⚡ Pro tip: Keep a running note of which bracketed inputs you reuse across specs — user segments, common constraints, standard metrics — so filling in the template becomes closer to copy-paste than fresh thinking every time.

Save and Reuse This

The PM at the logistics company mentioned earlier now keeps three versions of this template — one for full PRDs, one for experiment briefs, one for technical specs — and fills in the bracketed sections in under two minutes before every draft. That's the real win here: not that the AI writes a perfect PRD on the first try, but that the blank-page problem disappears, and the second and third drafts get faster because engineering stops sending back specs full of "wait, what does this actually mean" comments.

She also tracks a small metric of her own: how many rounds of engineering clarifying questions each PRD gets before it's accepted into a sprint. Before the rebuilt prompt, the average was four rounds. After, it dropped to one, mostly because the "flag assumptions" line surfaces ambiguity before an engineer ever has to ask about it in a comment thread that stalls the whole sprint planning meeting.

There's a broader lesson buried in this teardown that applies well beyond PRDs: the weak prompt and the improved prompt aren't asking the model to do different things. They're giving it different amounts of real information to work with. Product management is fundamentally a job of turning fuzzy problems into specific decisions, and it turns out prompting an AI well requires exactly the same skill — you're just doing the specificity work up front instead of in a review meeting.

If your team writes PRDs often enough that you're rebuilding this prompt from memory every time, save the template somewhere versioned rather than in a random doc — PromptABCD is built for exactly this, letting you keep a library of working prompts your whole product team can pull from instead of everyone starting at 4:45pm with a blank cursor.