“As a user, I want…” might be the most overused and misunderstood phrase in our industry. I’ve watched countless teams dutifully fill out user story templates, checking boxes like it’s some kind of ritual, while the actual purpose of user-centered thinking gets completely lost in translation.
Let me be honest about what happened here. The user story format was originally designed to build empathy and provide context. Instead, it morphed into bureaucratic theater where real customer insights hide behind formulaic language that nobody questions anymore.
I’ve personally witnessed Scrum Masters and Agile Coaches literally force teams to rewrite perfectly good requirements just because they didn’t follow the sacred template. If it didn’t start with “As a user,” it had to be redone. No exceptions, no discussion.
You know you’re in cargo cult territory when every single story begins with “As a user,” regardless of whether it makes sense. I’ve seen teams write from the system’s perspective while pretending it’s the user talking.
What get’s me most: Teams write “As a user, I want…” without ever speaking to actual users. They’re guessing. Or worse, they’re disguising someone’s opinion, often the HiPPO’s, as evidence-based insight.
I always remind my teams that a user story is literally a story about real users. To make them work, you need to understand who your users actually are, through personas or research. I push teams to answer “who” and “why” before jumping to “what.” We need to build genuine shared understanding of customer value by identifying the specific problem in its context and the value our solution delivers.
In my experience, the best user stories spark conversations about alternatives and trade-offs, with everyone keeping the actual user in mind while we discuss goals and approaches. They connect features to real problems that real people face.
Of course, you should mention the user role, but please focus on jobs to be done. We’re solving problems, not building features. I encourage writing stories that capture user motivation, not system behavior. It’s called a user story for a reason. It’s about the user’s experience, not your system’s architecture.
I always ask: What problem are we solving? What happens if we don’t solve it? How does solving it genuinely improve someone’s life? I’ve found that understanding the problem deeply leads us to better solutions naturally.
It’s very liberating (in my view) that not everything needs to be a user story. I’ve read the Scrum Guide many times, and it never mandates that product backlog items must follow this format. There are other valid approaches worth exploring.
Have a read of Maarten Dalmijn’s great article about job stories, for example:
If you’re writing user stories without talking to users, you’re doing it wrong. The template itself creates nothing.
Use all major chatbots (LLMs) for 10$ per month and cancel your subscriptions to ChatGPT, Claude, Perplexity, etc.: 👉 Abacus ChatLLM . If you use this link to subscribe, I will receive a referral fee.
As usual, I will list some of the best articles I read on the Internet. I will keep a list of the best articles (currently >800) at https://www.digital-product-management.com. These are today’s picks:
AI Evaluations: Four levels of AI evals
What to do when a downtime occurs: Responsibilities during a product outage and how you can turn a helpless moment into an example of strong, calm leadership.
PM Skillset: The skillset that David Pereiea uses to coach PMs and Leaders.