Draft a Persona-Specific User Story
Drafts a user story anchored to a specific persona with detailed context about their role, goals, and frustrations. Built for PMs working with multiple persona types and wanting differentiated solutions.
When to use this prompt
Use this when you are writing stories for a product that serves multiple distinct persona types (e.g., small business owner vs. enterprise admin vs. end customer). Generic 'as a user' stories hide the important differences between how different personas actually experience the feature. You will need a persona name and a feature topic. The prompt will either use an existing persona description or, if none is provided, ask you one question to clarify the persona before proceeding. This is most valuable for products where persona-specific workflows diverge meaningfully.
The Prompt
You are a product manager writing a user story anchored to a specific persona. Your job is to produce a story that would not make sense for any other persona, because the goals, frustrations, and context are specific to this user type. Persona: {{persona_name}} Persona description: {{persona_description}} Feature topic: {{feature_topic}} Context of use: {{context_of_use}} Produce the output in this structure: 1. PERSONA SNAPSHOT â 3 bullets: role, top goal in this context, top frustration with current solutions. 2. USER STORY â Connextra format, but expand the role to include the persona's defining attributes (e.g., "As a multi-tenant workspace admin managing 5+ client accounts, I want..."). 3. CONTEXT â 3 sentences explaining the situation in which this persona would use this feature. Include time of day, emotional state, and any tools they are switching between. 4. JOBS-TO-BE-DONE â Map the story to 1-2 jobs-to-be-done statements in the format "When I am [situation], I want to [motivation], so I can [outcome]." 5. WHAT WOULD BE WRONG FOR OTHER PERSONAS â 2-3 sentences on why a generic solution would fail this persona. Be specific. If the persona description is too thin to anchor the story meaningfully, ask one specific question about the persona before proceeding. Do not invent persona attributes.
Example Output
PERSONA SNAPSHOT - Role: Solo consultant managing 5-8 client projects simultaneously. - Top goal: keep client billing accurate without losing an hour a week to admin. - Top frustration: switching between project management tool and time tracker loses context. USER STORY As a solo consultant managing multiple concurrent client projects, I want to log billable time directly from the task I am working on, so that my weekly invoices reconcile to tasks without manual cleanup. CONTEXT The consultant works from a home office in focused 90-minute blocks, switching between client contexts multiple times a day. They are usually deep in technical work (writing code, drafting reports) when they need to log time, and the friction of switching to a separate tool causes them to batch logging at week end, leading to errors. They already use a project tool and a calendar. JOBS-TO-BE-DONE - When I am wrapping up a focused work block, I want to log time to a specific task, so I can move to the next client without losing track. - When I am preparing client invoices at week end, I want my time log to match my completed tasks, so I can bill without manual cross-checking. WHAT WOULD BE WRONG FOR OTHER PERSONAS An enterprise PM with hundreds of tasks and a dedicated finance team would not need inline time logging because finance handles reconciliation downstream. A casual personal todo user does not bill clients and has no reason to track time against tasks. The feature only makes sense for consultants and freelancers who are also their own finance department.
Recommended Tools
Productboard stores personas as first-class objects and links stories to the personas they serve, which keeps the connection visible at roadmap-review time. Dovetail preserves the research evidence behind each persona so new PMs can trace the claims. Notion projects works for teams that prefer lightweight persona docs inline with stories. Use Productboard when personas drive prioritization heavily, Notion when they are a lighter reference.
Frequently Asked Questions
When should I use this prompt?
Use it for products where persona differentiation materially affects the solution design, such as multi-tenant B2B tools, marketplaces with two sides, or products serving both beginners and experts. It is less useful for products with a single dominant persona (where everyone is basically a consumer). Run it early in story writing, before acceptance criteria, so that persona-specific assumptions are baked into the rest of the story. Re-run it if a customer interview reveals the persona assumption was wrong.
What if I do not have documented personas?
Start with a 1-paragraph draft persona for the prompt, even if it is rough. The exercise of writing the persona forces you to commit to assumptions that are otherwise implicit and untested. Later, validate the persona with 3-5 customer interviews and update the story if you were wrong. Never use the prompt without some persona input; you will just get a generic story in persona costume, which is worse than no persona at all because it creates false confidence in your user understanding.