I love user stories. I hate PRDs. And I love this blog post, because it explains why user stories are superior.

User stories don’t just communicate to engineers what they should build, they communicate why. This is a unique advantage of user stories over PRDs. Yes, there’s nothing stopping you from writing the why into your PRD. And yes, many people write bad user stories, where they forget to clearly define the actor or leave the benefit off altogether. But let’s focus on what we, as product managers, can control.

Suppose I create a great PRD. It doesn’t just explain what the engineers should build, but it provides all the requisite customer knowledge to set the context. Let’s say it ends up at 15 pages. I hand it off to my engineers. What happens?

They might read it through once. After that, they probably will refer to screenshots, or skim for relevant technical bits as they build. What do they ignore? All the reasons why.

Now let’s suppose that instead of writing a 15 page PRD, I write 50 user stories. I hand them to my engineers. What happens? They may read through the list of 50 once. That’s fine. Because what happens next, they start with the first user story and ignore the rest. But if each and every user story, communicates information about the actor, explains the desired action, and the benefit to the user, as the engineers implement each story, they have the why right there in front of them. They never lose sight of the content of why they are building what they are building.

Read on…