"Don't find customers for your product, find products for your customers."
As an entry-level PM, you've probably heard this song before; Your users will be people, not abstract features.
As product managers involved in the entire product life cycle, it is easy to forget that your end product will be used by an actual person. How then can you, as a product manager, factor this into your entire work process? Two words: user stories.
What are "user stories"?
User stories are one of the most popular agile techniques to capture product functionality. Think of it this way, when you continuously outline and concisely map out what a user of your product wants your product to do at every phase of the product development process, you'd be well on your way to creating customer-centric products.
A user story is a small, self-contained unit of development work designed to accomplish a specific goal within a product.
As good practice, during the planning phase of SDLC, a user persona of your ideal customer is created. This user persona is then given a story stating how a software feature will provide value to the customer.
Agile software development methodology encourages the use of user stories to define the who, what, and why of a product feature. A user story is the smallest unit of work in an agile framework.
User stories are written in natural language. They give a description of the features of a software application.
A key component of agile software development is putting users first, and a user story puts end users at the center of the conversation.
These stories use non-technical language to provide context for the development team and their efforts. After reading a user story, the team knows why they are building, what they're building, and what value it creates.
The various users described in the stories your team writes might in some cases be the same person needing different functionality for different tasks or different features targeted at different people.
They are written from the perspective of an end user or user of a system, and may be recorded on index cards, Post-it notes, or digitally in project management software On an agile team, stories are something the team can commit to finishing within a one- or two-week sprint. Oftentimes, developers would work on dozens of stories a month.
Why product teams should write compelling user stories
Product teams choose to break development work into user stories instead of product features or product requirements because user stories are:
Are easy for anyone to understand
User stories are important because they represent bite-sized deliverables that can fit in sprints since all full features cannot.
User stories help the team focus on real people, rather than abstract features. A regular to-do list keeps the team focused on tasks that need to be checked off, but a collection of stories keeps the team focused on solving problems for real users.
User stories also give off a feeling of progress. This builds momentum in the product team members because they can measure progress by referring to the functionality outlined in the user story already integrated into the product. With each passing story, the development team enjoys a small challenge and a small win, and we all know that little wins drive big wins.
Help teams deliver a product that the client really needs. User stories = customer-centric products.
Stories enable collaboration. With the end goal defined, the team can work together to decide how best to serve the user and meet that goal.
Stories drive creative solutions. Stories encourage the team to think critically and creatively about how to best achieve an end goal in each user story.
A user story describes the type of user, what they want, and why. A user story helps to create a simplified description of a requirement.
User stories help with iterative and self-contained units of development work. During each sprint, a user story is indispensable in keeping both the technical and business teams in sync about the product's goal.
Who writes user stories?
Writing user stories is not restricted to the product manager or owner. Depending on the project, user stories may be written by various stakeholders, such as clients, users, managers, or members of the development team.
As a rule, a user story should avoid all forms of technicality. You want something simple so that anyone on the business or technical side of the team can contribute a user story for consideration. User stories ensure the technical functions are left to the architect, developers, testers, and so on. This way, the non-technical members of the team can get the full gist of what's going on without having to go through the hassle of learning technical concepts.
User stories format
Working with user stories is easy, telling effective stories is not so easy. How then can we, as PMs, make effective user stories?
User stories follow the following format:
As a [type of user], I want [an action] so that [a benefit/a value]
Here is an example of a user story that fits a made-up cleaning service app project:
As a cleaner, I want to block badly behaved clients so they are never shown to me again.
As a customer, I want to link my credit card to my profile so that I can pay for the cleaning services faster, easier, and without cash.
As a cleaner, I want to add photos of my previous work to my profile so that I can attract more users.
As a customer, I want several available cleaners as well as their ratings to be displayed so that I can choose the most suitable option for me.
To learn how to write user stories, check out this amazing resource by hygger!