What Product Managers get wrong about user stories

PM are approaching user stories wrong.

While product managers focus on the customer problem and solution (the what, the why, and what the customer experience should be), the core focus of engineering is the technical implementation details. These are two completely different perspectives. Bridging this gap is essential but it can be a messy process and the how is not often talked about.

One of the tools used to bridge this gap is the user story. A user story is a short, simple description of a feature told from the perspective of the person who desires the new capability.

User stories are designed to shift the focus from writing about features to discussing them, which is especially important if we’re talking about bridging the PM and engineering perspectives.

Note: I’m not going over the basics of a user story because it’s been written to death and I’d prefer to focus on how to write user stories to bridge the PM-dev gap. So if you need to go over the basics, I suggest checking out Atlassian’s short and sweet article on user stories.

Product managers are approaching user stories all wrong.

In my experience working with product managers, PMs tend to overly focus on the customer perspective when writing user stories and forget that the ultimate goal of user stories is to foster collaboration between cross-functional teams, especially between PM and dev teams. When writing user stories, you should be thinking about how can I better write user stories to help engineers to think through technical implementation details.

The purpose of user stories is to convey the customer experience in a way that helps engineers better understand the customer and the product solution to get a sense of the technical implementation.

This is a big perspective shift and the key to a better PM-dev working relationship.

Writing better user stories for developers

User Stories should be both broad and specific

One of the main confusions about user stories is how broad or specific they should be. The answer is both.

To achieve this, create broad epic user stories first and then break them down into more specific functional user stories. Epic user stories help teams think of creative solutions to a customer problem while functional user stories are more specific to help engineers think through technical implementation.

Here’s an example of an epic and functional user story:

Epic User Stories

The epic user story should be broad enough that it conveys the general desired experience of customers. If you’re in the early stages of development where the problem is clear, but the solution is not, broad epics encourage teams to think of creative solutions to a problem.

Epic example:

As Courtney, I want to lock my phone when I’m not using it, so that I can prevent unauthorized access to my phone.

The problem here is clear: Courtney wants to prevent unauthorized access to her phone. However the solution isn’t. We know Courtney’s desired outcome is the ability to lock her phone when she’s not using it but we don’t yet know exactly what that looks like.

This is a great opportunity to brainstorm solutions to the problems. Your team may come up with solutions like using a PIN code, fingerprint, face recognition, audio recognition, etc.

Functional User Stories

Now let’s break down the broader epic user story into more functional parts. The functional user stories are smaller and more specific and helps engineers understand what the product solution is and what product managers are expecting to see.

Functional user story example:

As Courtney, I want to enter a pre-set 4 letter PIN code every time I want to use my phone, so that I can access my locked phone.

Both the problem and solution here is clear. The problem is Courtney wants to access her locked phone. The solution is to allow access to Courtney’s phone if a correct 4 letter PIN code is entered.

This functional user story is specific enough that it gives engineers sufficient information to start brainstorming what technical implementation may entail. For example:

• Should the pin code be stored in an existing database or a new database? Which would be easier and what are the trade-offs?
• What’s the best way to store the pin code securely?
• Can the frontend UI code be added to an existing stack or do we have to stand up a new frontend stack and with what framework(s)? What are the trade-offs here?
• Which and how many APIs will need to be created? Will we need to create new services to house the new APIs?

Developers want testable acceptance criteria in user stories.

Acceptance criteria refers to a set of predefined requirements that must be met to mark a user story as complete. When writing acceptance criteria, developers want testability: what measurable marker(s) will the dev use to determine the user story as complete?

Software engineering is a hard skill meaning it’s both objective and quantifiable. So as much as possible, do away with subjective adjectives and use markers like numbers, mocks, and flow diagrams.

Example of an acceptance criteria developers don’t want:

The landing page should load quickly.

Quickly is an adjective and therefore subjective.

Instead, be specific and quantifiable:

For every 2 out of 3 visits, the landing page should load within 1.5 seconds.

Here we replaced ‘quickly’ with quantifiable numbers: 1.5 seconds and every 2 out of 3 visits. Work with engineers to determine an acceptable load time if you’re not sure.

Some user stories will be more UI/UX based. In this case, attach well-created UI mocks that include the correct font, spacing, and colors.

I’ve worked with product manager who provided verbal instructions for what a UI should look like. For example: “Make this line red”. While red is not exactly subjective, it’s not specific either. Which shade of red? Providing well-made UI mocks is a measurable way for engineers to know what the expected end result should be.

Don’t forget to talk to your engineers when writing user stories!

You’ll likely be able to write the broader epic user stories on your own without the input of developers.

But when you start breaking epics down into more specific functional user stories, start getting developer feedback early on. Functional user stories help engineers understand what the technical implementation entails so getting their thoughts on what’s most helpful for them is makes everyone’s job easier. Always keep the line of communication open!

And finally, if you’re anything like me, you likely suffer from a little bit of perfectionism and think you have to do it all at once and do it perfectly from the get-go.

But this is too much pressure and not a collaborative process!

Instead, be flexible and adapt quickly. Expect things to change throughout the software development process and see it as a normal part of the process.

Positive feedback is feedback too!

We often think of feedback as “critical feedback”, but positive feedback is just as important! Team cohesive and effective teamwork ultimately comes from a place of positivity and a sense of forward/upward momentum. It’s difficult to have these when just focusing on critical feedback. You want to know what you’re doing right along with ways you can improve. So as much as possible, ask for positive feedback like “What did you like about [x] that you’d like to see me continue doing?” and “What was your favorite part about [x]?”

If you want to level up your technical skills and your ability to communicate and collaborate with engineers, enroll in the Skiplevel program. The Skiplevel program is a comprehensive, on-demand course + community that helps you become more technical without learning how to code.