Why I Hate User Stories (And You Should Too)

Let’s start with this: I hate user stories. Not because I hate the idea of understanding users or capturing their needs. I hate what user stories have become.

That awful “Madlib” template—As a [user], I want [thing], so that [reason]—has turned a good idea into a ritual. A checkbox on a Jira ticket. A masquerade of understanding.

Here’s the real problem: we’ve reduced a thoughtful practice into syntax. And it’s making things worse.

The problem with user stories is that they are not stories.

Customers Don’t Actually Know What They Want

One of the most important lessons in product management is this: customers don’t actually know their true problems—or the ideal solution. That’s your job. Your job is to discover the problem, not just write down what someone asked for.

When customers describe a solution, they are almost always wrong. When customers describe a problem, they are almost always right.

If a customer says, “I need a shovel,” and you write a user story that says, As a homeowner, I want a shovel so that I can clear my driveway, congratulations: you’ve just formalized a misunderstanding. You’ve defined a shovel.

Nobody wants a shovel. They want to get their car out of the driveway when it snows. So maybe the right answer isn’t a shovel—it’s a plow. Or heated asphalt. Or a teenager with a Venmo account and no fear of frostbite.

Good product managers don’t just take orders. They step back and ask: “What’s the real problem here?”

The Curse of the Template

Kent Beck, the creator of Extreme Programming, originally coined the term user story as a simple, flexible tool. “Tell me the stories of what the system will do,” he said. “Write down the name of the story and a paragraph or two.”

That’s it. That’s a user story. I love it.

Dan North, creator of Behavior-Driven Development, introduced the User Story Template, which is the most common format in use today:

“As a [user], I want [feature], so that [benefit].”

Mike Cohn of Mountain Goat Software made it popular by referencing it in his book User Stories Applied.

And then, over time, the user story format became dogma.

Here’s a typical user story:

As a user, I want to log in so that I can use the system.

No, you don’t. Nobody wants to log in. They want to access their stuff. They want security with a minimum of friction.

That’s not a story; that’s an implementation detail. This is just playing Mad Libs with a backlog.

The “3 Cs” of Stories

Ron Jeffries, one of the original founders of the Extreme Programming methodology, gave us the “3 Cs” of stories: Card, Conversation, Confirmation.

• Card. A brief story from the user's perspective; a story is an invitation for a discussion.

• Conversation. A discussion about the context of a story—the persona and the problem.

• Confirmation. A completed story should meet all expectations (called acceptance criteria).

This isn’t about writing requirements in a poetic format. It’s about communication. Understanding. Shared purpose.

Stories Aren’t About Features

Here’s the hard truth: good stories don’t describe features; they describe problems.

What’s needed is a problem story. That’s something your team can rally around. That’s the start of a real conversation.

Here’s what I teach:

1. Start with the problem. What’s going wrong for your customer or your business? What is causing friction in their lives?

2. Describe the personas. Who has this problem? What do we know about them?

3. Articulate the impact. Why is this worth solving? What’s the risk of doing nothing?

4. Collaborate on the solution. Bring in your designers, developers, and product marketing managers. Brainstorm solutions. Test ideas. Validate with potential customers.

5. Write stories after you understand. Don’t start with the template. End with it—if you use it at all.

   
   

A Template for a Problem Story

This problem story template has two parts:

On the left is information about the problem. On the right is the information about the solution.

Begin with a label or a short name for the problem to be solved.

Identify the personas who are concerned about this problem.

Document one or more usage scenarios that occur when someone experiences the problem. Describe how frequently the problem occurs in what circumstances. As much as you can, use the words your customers would use to describe it.

What market evidence do you have? Consider both qualitative and quantitative examples, such as 30% of your customers or the top 5 customers in your market segment.

Which customers can the product team contact for more context? Provide 3-5 names and email addresses of people who have experienced this problem.

That’s the detail on the problem… now let’s explore the characteristics of a possible solution.

The items on the right side are written with the creation team, those who are responsible for designing and developing the solution. You may find that they offer some helpful revisions to the left-side items as well. Participate in a discussion about what you might do to address this problem.

Discuss Acceptance Criteria. What MUST or MUST NOT occur when addressing this problem? For example, a personal scheduling tool must support multiple calendars and must not allow double-bookings.

Document the outcome. How will this capability improve the customer’s situation? After all, if it doesn’t affect the outcome, why do it? And how will you measure that you’ve achieved that outcome? For a scheduling tool, you might track how many appointments were scheduled without requiring a call to a receptionist. Which means you’ll need a way to capture this information.

That’s the problem story. Clearly focused on the problems and guiding the discussion on one or more ways to solve the problem.

Stories don’t have to be boring. A meaningful story can be motivating or even humorous. They tell an actual story with real-life scenarios. Good stories focus on the WHAT and WHO, not HOW and WHEN. They should not dictate specific implementations.

Best of all, they involve the people who will do the work.

Problem stories provide your teams with the context necessary for winning solutions. The point is not simply to write a lot of stories. The point is to communicate.

We’ve found that providing more context leads to better outcomes. The team understands the problem and becomes passionate about solving it.

Let’s stop pretending that templated user stories are a substitute for thinking. Your team deserves better. Your customers do too.

You’re not a story writer. You’re a problem discoverer, a truth-teller, a guide.

Now go find the real problem.