When it comes to building great products, you need to put your users first. That’s where user stories come in. As product managers, we can use user stories to understand how our products will provide value to our users.
So, what is a user story?
A user story is a simple description of something that a user of your product wants to achieve. It often involves one feature or aspect of your product, and is written from the user’s perspective. The objective is to facilitate discussion between your product team, dev team, and designers about how you can develop your product further.
User stories generally follow this format:
“As a certain type of user I want to achieve this goal for some particular reason.”
SaaS companies tend to have a fair number of user stories. These will often be written on index cards or post-it notes, where they will be arranged on walls or tables for further discussion.
There are a number of important reasons for writing user stories and including them in your product planning…
1. Focus on your users
It’s easy to get carried away when you’re designing a product, and you’ll often start adding extra, unnecessary features. User stories ensure that you’re always focused on what your users need to get value from your product.
Ultimately, this means you build a product that helps more of your users, and keeps them around for longer.
2. Focus on your problems
As any product manager worth their salt will tell you, designing a product is essentially a problem-solving exercise. The nature of a user story is that it clearly defines user problems that need to be solved.
This way you and your product team can focus on providing the best possible solution and avoid barking up the wrong tree.
3. Focus on flexibility
Most product teams work with an agile framework, so flexibility is crucial. Teams must be able to shift ideas around and change priorities on a monthly — and sometimes even weekly — basis.
User stories break epics down into more manageable chunks. These smaller chunks enable you to switch up the order of what you build.
Smaller steps offer far greater flexibility, perfect for fast-moving product teams.
User stories are designed to fit perfectly into agile workflows like scrum and kanban. They’re essentially the smallest building blocks of the overall plan, and as a result, you should work them in at the earliest opportunity.
There are slight differences to how user stories fit into scrum and kanban. For scrum teams, user stories are usually added to a sprint, and are then burned down over the course of that sprint. For kanban teams, user stories are pulled through into the backlog and then run through the workflow.
User stories can be written at any time and, in fact, should be continuously written so that you have a large bank of user stories to implement. Then, at the start of each sprint, you and your product team can decide which user stories you want to tackle next.
In their most basic form, user stories are a few sentences long. They basically outline what the user is seeking to achieve with your product. As time goes on, you can start adding solutions and more detailed requirements. But to start off with, user stories follow a certain formula:
“USER wants to X, so they can Y.”
Let’s explore this formula further…
The USER is who you’re building the product for. It’s likely that you’ll have several different user personas. If that’s the case, then you should write a user story for each specific persona. That might well mean writing several similar user stories.
X is the initial outcome that the user wants. This is what they’re trying to achieve. Eventually, you’ll figure out how your product can help them achieve X, but for now you need to focus purely on the user’s goal.
Y is the underlying reason for your user’s goal. This is higher-level and provides the bigger problem that users are facing. Sometimes a problem can’t be solved with just one user story.
A real-world user story might go a little something like this:
“James wants to better understand his spending habits, so he can budget better.”
The user is James. X is understanding his spending habits. Y is wanting to budget better.
User stories and use cases are very similar in that they both focus on providing a solution to a user’s goal. However, there are some key differences you should be aware of:
Both user stories and use cases can, and should, be used in conjunction with your overall framework.
Due to the similarities between user stories and use cases, there will inevitably be crossover. That said, both user stories and use cases serve slightly different goals, so it’s important to keep them as separate entities.
To write a great user story, lots of preparation and research is required. It isn’t as simple as writing a few sentences out.
Most user stories are written by product owners or product managers. These are the people most familiar with the product and are ultimately in charge of deciding which direction the product is taken in.
It makes sense to have a product owner or manager review any user stories, either as they come in, or in bulk at set intervals. Once the user story is written and has been approved, you need to add further details. The responsibility for developing the user story generally falls on the wider product team.
That being said, there’s no real reason why you can’t open user stories so that anyone in your organization can contribute.
User stories are all about — you guessed it — users. Thus, it’s important to involve them as much as possible. While users won’t be responsible for providing you with actual user stories, they are a great source of information.
This is where conducting user research comes in.
Take the time to listen to have conversations with and really listen to your users. Listen to what they say, how they say it, and any common problems they bring up. Oftentimes, users may not have an accurate understanding of their problems, needs, and potential solutions that may help solve them. It’s your job to dig deeper and get to the bottom of it.
You should also seek information about users from unconventional sources, such as your support and customer success teams. They’ll hear the same problems and gaps in your product over and over. This information is gold when it comes to gaining a comprehensive understanding of your users, and will certainly help when it comes to writing user stories.
If you get the research part right, you’ll have all the information you need to start writing great user stories. If you don’t have enough research, not to worry. You can still put yourself in your user’s shoes, and try to understand the kind of problems they’ll have.
Stick to the formula we covered earlier:
“USER wants to X, so they can Y.”
Choosing the user persona is either really easy (because you only have one or two) or fairly difficult (because you have several). Make sure you write a range of user stories that cover all of your user personas.
X is the user’s intention. This is what they want to do. This should be one action that the user wants to complete. It also shouldn’t be specific to your product or mention any product details.
Y is the underlying reason for the user’s intention. This is what drives them to act in the first place. It’s useful to keep your product’s KPIs in mind at this point. Your user’s goals should always be aligned with your company’s.
Here are some more pointers to keep in mind when writing your user stories:
Once your user stories have been written and approved, it’s time to add more detail to them. This is where discussions with your team come in. Generally, your whole product team will take part in discussions. Your UX / UI designers and dev team may also be part of the conversation.
You essentially need to take each user story in turn and decide how your product can help the user achieve the goal that each story details. Actual features or functionalities that you can build into your product should be an end goal of the discussion. It’s also where you’ll decide on rough timelines on when you will start building.
These discussions are arguably the most important aspect of user stories. They turn a simple sentence into something more tangible and ready to be built.
Before we finish up here, let’s take a look at some good examples of user stories.
All of these follow the formula we outlined above, and will give you a good idea of what a user story should look like.
Let’s imagine that we built a product that simplifies email marketing. Currently, our users are able to compose an email and then send it out right away. Here’s a potential user story that we might write, based on conversations with our users.
“Sally wants to schedule emails in advance, so she can improve the efficiency of her email marketing.”
Sally is our user persona — a marketing manager at a small business. Scheduling emails in advance is her intention. Improving efficiency is her ultimate goal. Note how that aligns with our business goal of making a simple email marketing tool.
Also note that there is no mention of how our product might actually enable this intention.
This time, our product is an app that enables people to organize ride shares. Here’s a user story that we might come up with:
“Tyler wants to know when he should leave his house for work, so that he doesn’t turn up late.”
Here, our user persona is Tyler, a middle-aged commuter who drives to work. He is one of the drivers for our ride-share app. His intention is to set off at the right time. His underlying reason is that he doesn’t want to be late for work.
Again, this user story doesn’t explain how our product could help. There are several different approaches we could take to solve this problem, but we don’t include those in the user story.
. . .
Productboard is a product management system that enables teams to get the right products to market faster. Built on top of the Product Excellence framework, Productboard serves as the dedicated system of record for product managers and aligns everyone on the right features to build next. Access a free trial of Productboard today.
