User Stories Are Better Than PRDs

In the previous post, we focused on how product managers share customer knowledge with engineers. We discussed how user personas are an effective way of  telling the customer's story. We also looked at how some teams share artifacts (videos, audio, written reports) from usability tests to help communicate customer pain points. But I left out a critical mechanism for how product managers share customer knowledge with engineers - the user story.

Historically (let's say before the internet), product teams wrote Product Requirement Documents (PRDs), long documents that outline every nook and cranny of a product. Some teams still work this way. But many have moved to writing product requirements in the form of user stories. User stories have the following format:

As an actor, I can take some action for the following benefit.

Let's look at each of these parts in turn. First, the actor. More often than not, I see users stories start like this, "As a user …", but this is pointless. The point of the actor is to take on a perspective. For example, if I'm writing user stories for an event site like eVite or Facebook events, I might have stories that begin with:

• As an event host …
• As an event invitee …
• As an event attendee …
• As someone who cannot attend an event ...

This tells engineers who will be using the functionality. It might seem trivial, but I can't tell you how many times the wrong functionality was built because the actor was misunderstood.

Next, let's look at, "...I can take some action …" this is the part of the user story that most resembles what goes in a PRD. For the same event site, we might have:

• I can invite my friends to my event
• I can RSVP to an event invite
• I can map the location of the event
• I can view photos from the event

This tells engineers exactly what new functionality is needed. Finally, let's look at "…for the following benefit." More often than not, I see this part of the user story just left off. It's true, you technically don't need it, to know what to build. But by leaving it off, you lose just about all the context of why you are building what you are building. Continuing with our event example, we might have the following benefits:

• so that I can easily manage who is attending.
• so that I can let the host know whether or not I am coming
• so that I can easily get to the event.
• so that I can live vicariously through the people who did attend.

This event example is pretty straightforward. But in more complex products, the benefit can often clear up misunderstandings about why you are building specific functionality. It also helps to keep the focus on the actor. You aren't building functionality just because, you are building functionality to serve a need.

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.

Looking back at some of the concepts discussed in the prior two posts, a user story is a great example of a boundary object. A boundary object facilitates knowledge sharing between two groups that have little overlap in their own knowledge.  A product manager has a wealth of customer knowledge, an engineer has a wealth of technical know-how, a user story allows a product manager to communicate bite-sized knowledge about the customer to the engineer, within the context of what they are building.

Everybody wins. Moral of the story: write good user stories, clearly specify the actor, and pay special attention to the benefit.