Product Usability and the Thing That Frustrates Your Users Most
If you’re a product manager or product owner, here’s the thing that frustrates your users most. In their words…“do they really know what we do?”
You don’t truly understand what your users do – their job! And that lack of understanding shows up front and center in your product usability.
There’s a significant difference between understanding what users do with your products and understanding what they do, period, without any regard to your products, including how their job performance is measured by their managers.
When it comes to product usability, that distinction matters way more than anyone realizes.
How Do You See Your Users?
Most product teams view users through the narrow lens of their products: features, workflows, screens, and configurations. What they rarely step back to understand is the pure, job-level reality of the user—what specific tasks they perform, what success looks like in their role, what makes their day easier or harder and how job performance is evaluated by their managers.
And that misunderstanding shows up loud and clear in how we write user stories that drive product usability at all levels.
The Problem with Most User Stories
Take a look at a typical backlog and you’ll see user stories like this:
“As a user, I want to generate an XYZ report so that I can analyze the performance of…”
On the surface, this looks reasonable. But if you’re writing user stories like this, you’ve already missed the boat
This story isn’t really about the user’s job. It’s about what the product should do.
What’s missing is the deeper understanding of why the user needs that report, what decision it supports, why it’s so difficult to analyze something today and what success actually means for the specific job task of analyzing something. Without that context, teams end up optimizing features instead of making users more successful at specific job tasks.
The result? Software that technically works—but doesn’t simplify the job task of the user in order to deliver a superior outcome.
The Reality of Product Usability
For all the years I’ve been facilitating product management courses, I’ve also been teaching pre-sales demo courses. So, I’ve been seen more than my fair share of product demos.
On a scale of 1 to 10—where 10 is outstanding usability—about 80% of enterprise products land in the neighborhood of a 6.
Not terrible. Not great. Just tolerable enough to survive – and frustrate the daylights out of their users because of missed opportunities to make their life easier.
The remaining 20% that land in the 9–10 range all have something in common:
The people managing and designing those products have a deep understanding what users actually do and what it takes for them to be successful at a well-defined set of specific job tasks.
In other words, these products correctly anticipate what users need to do in order to successfully complete a given number of job tasks, and they either do it for them or greatly simplify what has to be done to get the most desirable outcome with the least amount of effort.
The Question Every Product Should Answer
Here’s the bottom-line question every product team should be able to answer clearly:
Will the managers of our users notice improvements in the performance of specific job tasks because of our products, and WHY?
If you can’t answer that without referencing product capabilities, then you don’t truly understand the jobs of your users.
The Culprit: Treating All User Stories the Same
The first thing product teams need to do to fix this is recognize that there are two very different types of user stories—and they serve very different purposes.
1. Job User Stories
Job stories have nothing to do with your product, and they’re not epics.
They describe a specific job task and what a person must do to complete that job task successfully, independent of tools, technology, or features. They focus on outcomes, constraints, and measures of success.
Think of these job stories as the goal or the most desirable outcome of the supporting feature stories that follow. They force clarity around what ultimately matters.
They’re not use cases or long narratives that encompass big chunks of a user’s job. They’re focused on a single job task and how to make users more successful at that job task in a purely procedural context.
For example, if a certain job task requires too many steps to complete, the goal is to complete that task with fewer steps. That becomes the goal of the features you’ll add.
2. Product User Stories
Product user stories come after job stories.
They describe what the product should do to help users successfully complete those job tasks in the most desirable manner. And here’s the key:
There is almost always a one-to-many relationship between a single job story and the subsequent product stories.
One job task, multiple features to make the user quantifiably more successful at that job task.
When teams skip the job story and jump straight to product stories, they lock themselves into assumptions—and that’s why usability suffers so much.
Final Thought
Great usability doesn’t come from better feature stories alone.
It comes from the context that’s incorporated into your job stories that serve as the target for your product stories.
Understand the job task first.
Then design the product to make the users as successful as possible doing that job task.
That’s how your product stops frustrating users—and starts making them measurably better at what they do – their real job.
Learn How Make Your Users More Successful
High customer retention rates have become one of the most important metrics your investors are looking at because they reflect the real value customers get from your products.
If your customer retention rates are suffering because of poor product usability, contact us about a personalized User Story Workshop and learn how to understand your users as well or better than they understand themselves.
