Have you heard? My new book Continuous Discovery Habits is now available. Get the product trio's guide to a structured and sustainable approach to continuous discovery. 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.
This is how we chose a private social collaboration/learning tool! We created a social learning user scenarios and shared the document with various vendors. We intentionally did not create a huge excel spreadsheet of required features – it is too easy to check off all those boxes as a vendor and we felt like once we had created our scenarios that we would know the right product when we saw it. We cared more about finding a company that was in line with our strategy and point-of-view as opposed to the one that ticked off all the boxes. It was interesting to see how the vendors responded to the document. Some took the time to read and customized a ‘sandbox’ environment for us based on the stories we told. It was clear that others had not read the document.
That’s great, Keeley! And it sounds like it worked out really well for you. It’s a great way to evaluate whether or not a vendor truly understands your context.
There’s another reason. User stories can be managed in something like Greenhopper and can be easily repriorised, categorised, etc. It’s much harder to do that with a document.
Yes, absolutely agree.
A really nicely decomposed explanation of the parts, functions and purpose of user stories. Well done and thanks.
Like many others, I am for the most part happier using bite-size stories and managing them in Greenhopper than I was building 40-page (or longer) PRDs, but I do miss two things from that larger document.
First, I there is the overall context of the project that the introductory section of the PRD covered – the why are we doing this, who are the buyer and user personas, what are the high-level goals of the project and how do they support the overall goals of the business information. As you say, the team may only read this once, but that one -time event sets the stage for the whole effort. Greenhopper has no place for this info, but I’ve found that you can cover it well in under 10 slides at a product kickoff meeting. In fact, I think this approach is more effective than a PRD because you can never be sure people didn’t skip over that part of the PRD!
The second thing that Greenhopper doesn’t help with is prioritization against project or company goals. It allows you to set high-medium-low type priorities or even to rank stories in order by hand, but it doesn’t allow you to do any kind of scoring against objective criteria or cost vs. benefit calculation. I find I am still doing this in a spreadsheet as I did back when I wrote PRDs. (Post if you’d like a copy of my template.)
Hi Bruce,
Thanks for the thoughtful comment. I agree that as PMs we still need to include the big picture or overall product direction and that that can be hard to capture in user stories. Like you mentioned, I usually do this in a vision document that also acts as a living document.
I’m not familiar with Grasshopper (I’m old-fashioned and write user stories in Excel / Google Spreadsheets). But as for prioritization I use organize user stories according to broad product themes that are tied to business goals. Perhaps that’s another blog post down the road.
Cheers,
Teresa
What’s PRD?
a Product Requirements Document
I’ll offer a different perspective of the benefit of user stories.
As a casual user of technology, I appreciate it when someone takes the time to describe the benefits in addition to the name of the software or app. I like to know why this suggestion is faster, better, cheaper than what I currently use in order to evaluate its adoption. A brand name and a “it’s so cool” endorsement doesn’t move me to change.
Thanks for the detailed description. As you might imagine, I enjoyed it!
HI Teresa, great post. I found your blog in my search for “letting engineers write their own user stories”. I really liked your argument on why 50 stories may be better then 15 page PRD. And realizing that not all stories may be critical for solving the customer problem, having an overall context captured either in PRD or Vision document makes sense.
I would be curious to know your thoughts on: should the engineers write their own user stories based out of a PRD? My perspective remains that it may hurt the collaboration and return the teams back to the contract based model. But then I see some big companies and technology brands following this model. What in your opinion, would be the rationale to justify that? Also would that perspective differ depending upon the product being B2C or B2B