User Story Prompt for Product Managers

What this prompt does

A user story prompt turns a one-line feature request into a written story with a named user, a stated outcome, and acceptance criteria a second person could test without asking you what you meant. This one works on a single story at a time. You give it the raw request, who asked for it, and what that person was trying to do when they hit the wall. It returns the story, the criteria, the non-goals, and the questions it couldn't answer from what you gave it.

"As a user, I want a dashboard, so that I can see my data" fails all three. "User" means everyone and therefore nobody. Seeing data isn't an outcome anyone wants for its own sake. And nothing there can be tested, so engineering builds one interpretation and you find out which at demo.

The output also runs an INVEST check on its own story and names the letters it fails. A story that admits it isn't Small beats one that pretends.

It writes one story. Splitting an epic into twelve is a different job, and asking for both at once gets you twelve vague ones.

The prompt

Write one user story from the request below. One story, not a set.

**The raw request, quoted exactly as it reached me:** [PASTE THE TICKET, SLACK MESSAGE, OR SALES NOTE VERBATIM]
**Who said it:** [ROLE AND CONTEXT, e.g. "ops manager at a 40-person logistics customer, 2 years on the product"]
**What they were doing when they hit the problem:** [THE TASK THEY WERE MID-WAY THROUGH]
**Their workaround today:** [WHAT THEY DO INSTEAD, or "none, they give up"]
**What already exists in the product that's close:** [NAME THE EXISTING SCREEN OR FEATURE, or "nothing"]
**Explicitly out of scope for this story:** [WHAT I ALREADY KNOW I'M NOT BUILDING]

Return exactly these sections:

1. **Story.** One sentence: As a [specific role, never "user"], I want [capability], so that [outcome they'd notice]. If my inputs don't identify a specific enough role, say so instead of inventing one.
2. **Acceptance criteria.** 4 to 7 criteria in Given / When / Then form. Each one must be checkable by someone who has never spoken to me. Cover at least one empty state and one failure path.
3. **Non-goals.** What this story does not do, including anything a reader might assume it covers.
4. **Open questions.** Every decision you had to guess at, phrased as a question for me. This section is not optional. If it's empty, say why.
5. **INVEST check.** Score the story against Independent, Negotiable, Valuable, Estimable, Small, Testable. For each letter, pass or fail plus one line of reasoning. If it fails Small, propose where the split goes.

Rules: use only what I gave you. Do not invent user research, usage numbers, or company names. Do not estimate effort. Where the request is ambiguous, put it in Open questions rather than resolving it yourself.

How to use it

1. Paste the request verbatim. A paraphrase means you've already decided what the person meant, which is the exact judgment the story exists to make explicit. Their wording carries the frustration and the vocabulary.
2. Fill in the workaround field. What someone does instead is the strongest evidence you have of what they need. A customer exporting to a spreadsheet every Monday is telling you the shape of the feature.
3. Read the open questions before the story. They're what you're about to commit engineering to without having decided. Most take a minute to answer and one usually doesn't, and that one is the real work.
4. Treat the INVEST check as a review, not a grade. The acronym is Bill Wake's, from 2003: Independent, Negotiable, Valuable, Estimable, Small, Testable. A model applying six criteria in order catches what you skim past on your own story at 6pm.
5. Rewrite the story sentence yourself. Keep the criteria and non-goals, but the one-sentence story is what the team quotes back at you for three weeks. It should sound like you.

Criteria come back in Given/When/Then because that's what the tooling already reads. Gherkin's reference documents the syntax automated test suites parse, so a criterion written this way becomes a test without a rewrite.

Example output (partial)

Raw request: "I've got 37 open invoices and no idea which ones are actually late. Every Monday I export the whole list and colour-code it by hand."

Who said it: ops manager, 40-person logistics customer, two years on the product.

Story. As an ops manager tracking outstanding payments, I want open invoices sorted by how far past due they are, so that I can chase the worst ones first without rebuilding the list by hand each week.

Acceptance criteria.

• Given I have open invoices with due dates in the past, when I open the invoices list, then overdue invoices appear first, ordered by days overdue descending, each row reading "14 days overdue" rather than the raw due date.
• Given none of my invoices are overdue, when I open the list, then I see the standard list with a line confirming nothing is past due, not an empty screen.
• Given the invoice service is unavailable, when I open the list, then I see a retry state rather than a silent empty list.

Non-goals. No reminder emails. No partial-payment handling. No change to how due dates get set. Nothing about paid invoices.

Open questions. (1) Is "overdue" measured from the due date, or from the invoice date plus terms? (2) Should the ops manager's teammates see the same ordering, or is this per-user? (3) You said 37 invoices. Does the sort need to hold at 3,700?

INVEST check. Independent: pass. Negotiable: pass. Valuable: pass, it removes a weekly manual step. Estimable: fail, because open question 1 changes how much data-model work this is. Small: pass. Testable: pass.

That third open question is the one worth ten minutes. Sorting 37 rows in the browser and sorting 3,700 on the server are different stories, and the request didn't say which.

Variations

For a bug rather than a feature

"This is a defect, not a new capability. Skip the As a / I want form. Give me current behaviour, expected behaviour, reproduction steps as Given/When/Then, and who else hits this. Keep the open questions section."

When the story is too big

"You flagged this as failing Small. Split it into the smallest slice a real user would still notice, plus what's deferred. The first slice must ship on its own, not as a back-end-only phase."

For a story blocked on design

"List what this story needs from design before engineering can start, and mark each acceptance criterion that can't be finalised until those decisions land."

Common pitfalls

• Don't let it invent the persona. Given "user," a model will happily produce "As a busy professional," and now a made-up person sits in your backlog. The prompt tells it to flag a thin role instead. When it does, go find out who actually asked.
• Don't accept criteria you can't check. "The list should be fast" and "the UI should be intuitive" are opinions with a Then in front of them. Send them back with a number attached or drop them.
• Don't confuse a story format with a process. The 2020 Scrum Guide never uses the phrase "user story" at all. It says Product Backlog item, thirteen times, and leaves the format to the team. Stories are one convention, not a rule you break when a plain task fits better.
• Try instead: run the prompt, then read only the acceptance criteria aloud to the engineer who'll build it. Any question they ask that the criteria should have answered is the thing to fix before the story enters a sprint.

Once stories are in flight, the daily standup prompt turns the day's progress into an update and the project status report prompt rolls a sprint up for people who don't read the board. ChatGPT and Claude both run this prompt unmodified. Gemini returns longer criteria, so add "keep each criterion under 25 words" if that bothers you.

Who uses this prompt

• Product managers: turning tickets and sales notes into backlog items that survive refinement. More in the prompts for product managers collection.
• Project managers: writing the work up when a team runs stories but nobody owns the writing. See prompts for project managers.
• Designers: reading the non-goals to learn what a story assumes about the interface before the first mock exists.

You'll know it worked when refinement stops being the meeting where somebody explains what the story meant.