The User Story cargo cult: How we turned empathy into bureaucracy

Your team may be following the format but missing the entire point

“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.

The warning signs

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.

What user stories should actually do

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.

---

---

The shift in thinking

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.

Breaking free

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:

Use Job Stories To Hook Users

The reality check

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.

---

What I Read

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.