📝 User Story Writing

Draft a User Story From a Feature Request

Converts a raw feature request into a well-formed user story with role, outcome, and motivation. Designed for PMs processing inbound requests from sales, support, and customers.

This prompt takes an unstructured feature request and drafts a Connextra-format user story (As a... I want... so that...) with clear outcome and motivation. It also flags requests that are too vague to convert and prompts the user for a specific clarifying question.

When to use this prompt

Use this whenever a request arrives in unstructured form: a sales call note, an email from a customer, a Slack ping from leadership. You will need the raw request text and a rough idea of who the affected user is. The prompt assumes you understand your primary personas; if they are undocumented, provide a 1-line description per persona. It is intentionally strict about motivation because feature requests with unclear 'why' are the single most common source of wasted engineering effort. If the raw request is solution-first, the prompt will reverse-engineer the underlying problem.

The Prompt

Role: Product Manager Variables: {{raw_request}}, {{requester}}, {{personas}}, {{product_area}}

You are a product manager drafting a clean user story from a raw feature request. Your output must use the Connextra format with a clear role, outcome, and motivation.

Raw request:
{{raw_request}}

Requester: {{requester}}
Known personas: {{personas}}
Product area: {{product_area}}

Steps:

1. IDENTIFY PROBLEM — If the request is solution-first ("add a button to..."), reverse-engineer the underlying problem the user is trying to solve. Write it in 1 sentence.

2. IDENTIFY USER — Match the request to one of the known personas. If no match, propose a new persona with a 1-line description.

3. DRAFT THE STORY — Write a Connextra-format user story:
As a [role], I want [outcome], so that [motivation].
The outcome must be a capability, not a UI element. The motivation must be a real user benefit, not an internal metric.

4. CONTEXT — Add a 2-3 sentence context paragraph explaining why this matters now and any relevant constraints.

5. ALTERNATIVES CONSIDERED — List 1-2 alternative interpretations of the request. Explain why you chose the primary.

6. CLARIFYING QUESTIONS — If any part of the request is too vague to write confidently, ask the minimum number of questions that would resolve it. Never invent details.

Keep the story under 30 words. Avoid jargon in the motivation clause.

Example Output

PROBLEM: Billing admins cannot tell at a glance which invoices need their attention, so they miss overdue ones.

USER: Finance admin (matches existing persona).

USER STORY:
As a finance admin, I want to see overdue invoices highlighted in my dashboard, so that I can chase payment before month end close.

CONTEXT: The requester runs a 50-person accounting team at a mid-market customer. They currently export all invoices to Excel and sort manually each morning, which takes 20 minutes and misses edge cases. Month-end chasing is time-critical.

ALTERNATIVES CONSIDERED:
- Add a separate overdue page: adds a navigation step the admin already struggles with.
- Send daily email digest: easier to build, but admins already filter out digest emails.

CLARIFYING QUESTIONS: None; request is clear enough to proceed.

Recommended Tools

Productboard preserves the link from the originating customer request to the final user story, which matters for evidence trails during quarterly reviews. Jira and Linear both have user story templates that match the Connextra format directly. Use Productboard for capture, then push the finalized story into Jira or Linear for execution.

Productboard73/100 Jira Software75/100 Linear74/100

Frequently Asked Questions

When should I use this prompt?

Use it every time a feature request arrives in unstructured form, especially from non-PM sources like sales calls or customer emails. Running it immediately prevents the original context from decaying. If your team already uses a structured request form with role and motivation fields, you only need this prompt for exceptional cases like an exec request that bypassed the form. For high-volume request streams, consider batching weekly rather than running it for every ping.

What if the request is solution-first?

Solution-first requests ("add a button to export CSV") hide the real problem underneath. The prompt explicitly asks you to reverse-engineer the underlying problem before writing the story. Go back to the requester with the inferred problem and confirm it before committing. Often the real problem opens up better solutions than the original suggestion. For example, the CSV export request may actually be a reporting problem solvable with a scheduled dashboard email, which is cheaper and more valuable.