---
title: "User Story"
description: "A short description of a feature from the user's perspective, in a standard format."
category: "Frameworks & Strategy"
canonical: https://featureos.com/glossary/user-story
markdown: https://featureos.com/glossary/user-story.md
source: FeatureOS (https://featureos.com)
---

A **user story** is a one-sentence description of something a user needs, written from their point of view. The standard format is: "As a [type of user], I want [to do something], so that [I can achieve a goal]."

So instead of "Build export to CSV," you write: "As a team admin, I want to export feedback to CSV, so that I can share it with stakeholders who don't have product access." Same feature, but now the whole team knows who it's for and why it matters.

## Why the format holds up

User stories force you to think about the person using a feature before thinking about the implementation. The "so that" clause is especially important. It tells engineers what problem they're actually solving, which gives them room to find a better solution than the one you described.

## Common mistakes

Making stories too big is the most common one. "As a user, I want to manage my account" is an epic, not a story. Break it down until each story can ship in a sprint.

Forgetting the "so that" is the second. Without it, engineers are guessing at intent. Writing stories for the business instead of the user is the third: "As an admin, I want to see revenue metrics" is usually a business need wearing a user story costume.

User stories work best when they're backed by real customer feedback. If you can link a story to a specific request or quote, every item on your [product roadmap](/roadmaps) becomes easier to defend.

---
Source: FeatureOS — https://featureos.com/glossary/user-story
FeatureOS: product feedback, roadmaps & changelogs — https://featureos.com