If you’re like most product managers, you probably have a backlog full of user stories representing just what you’d like to see your best users do with your product.
You have stories representing how they’ll get the most out of every feature, how they’ll find every benefit laid out for them, and how they’ll squeeze your best intent out of every corner of your product. Everything you’ve done has been with an eye towards taking care of your best users.
But what about your not so great users? Not just those who are casual users of your product, or who approach it with little enthusiasm. No, I’m talking about those malevolent users who have set out with no other purpose in mind than to do you harm. You have those users, too…you just may not be thinking about them.
These are the users who have only malicious intent towards your company, your product, or even your other users. We call these our “evil users,” and whether you want to think of them or not…they’re your users, too. And they deserve their own user stories.
Evil user stories are just like normal user stories, except they represent what a malevolent user would do in your product instead of what a benign user would do. In every case, these stories represent what you don’t want a user doing inside of your product.
Why would you write stories that represent what you don’t want a user to do? Because by understanding what an evil user wants to do in your product, and more importantly why they want to do it, you can better understand how to defend against them.
Illustration by Moe Bonneau.
Let’s look at an example.
Imagine that your product is an e-commerce platform that allows your users to buy and sell rare video game cartridges. Buyers on your marketplace can pay with either their PayPal accounts or credit cards.
Now imagine that your community of rare video game aficionados has been targeted by a hacker. This hacker intends to steal the credit card numbers of your users so he can sell those numbers on the black market.
To represent this intent, you might write an evil user story that looks something like this:
As a hacker, I want to steal the credit card numbers of the site’s users, so I can sell those numbers on the black market.
This story is just your starting point. It helps you understand what a hacker wants to do and why they would want to do it. But it doesn’t help you understand how they might accomplish it.
With a bit of “evil brainstorming,” you can probably think of a few ways to accomplish this. One way would be to gain direct access to the database that backs your website. This would give your hacker unfettered access to all credit card numbers in the site. However, this would be difficult for your hacker to do and, since you’re most likely encrypting your credit card numbers (right?), the hacker wouldn’t be able to use his bounty, anyway. At least, not easily.
Another option would be to break into another user’s account where the hacker could pull that user’s credit card number right from their billing information page. This would be much easier than gaining direct access to your backend database and it would also give the hacker access to more of your user’s profile information, such as the corresponding name and address associated with their credit card.
This seems like the most likely path your hacker would take, so let’s refine your evil user story to reflect this:
As a hacker, I want to break into a specific user’s account, so I can steal their credit card number.
Now that you have a better understanding of why a hacker would want to break into a specific user’s account, you can begin to think about how you can better defend against it. For example, you could strengthen the authentication requirements for a user to log into their account, perhaps by requiring an alphanumeric password with at least 8 characters and special symbols, or requiring two-factor authentication. Alternatively, instead of complicating the authentication process you could just decide to never display the full credit card number to a user and instead display only the last four digits. That way, if a hacker does compromise a user’s account, then they’ll never be able to access the full credit card number in order to steal it.
The important takeaway here is that, much like a normal user story, the most powerful part of an evil user story is the “so that” clause. Once you understand the intentions behind a user’s actions you can start to work backwards to understand the steps that they might take to accomplish those intentions. Those steps are what you’ll want to protect against.
You now have your first evil user story focusing on hackers. But “hacker” is a pretty generic term. There are plenty of disgruntled people in the world who might wish to do harm to both your product and your more benign users. For example, imagine that early in the history of your company you hired an IT Admin named Victor. Although Victor was a talented admin, he just never seemed to fit with the rest of the team. Eventually things turned sour, and unfortunately, he had to be let go. Victor’s departure was nasty and although you may have forgotten about him, he hasn’t forgotten about you or your company. And now he’s back for revenge.
Illustration by Moe Bonneau.
How will Victor take his revenge? Well, he knows that what sets your e-commerce platform apart from your competitors’ is the depth of your inventory. You’re “the place” that people come to for hard-to-find classic console video games. If your inventory were to suddenly disappear from your website, then your business would be sunk. Unfortunately, Victor also knows exactly how your e-commerce administration portal works, and that you rarely disable admin accounts after employees leave. To help you imagine exactly what Victor may try to do, you can model his intent with another evil user story.
As a disgruntled employee, I want to delete all of the store’s inventory, so that the store will appear to be out of stock of all items and will be unable to generate revenue.
Now that you understand exactly what Victor is trying to do, you can explore ways to prevent him from accomplishing his task, just as you did with your hacker.
The key takeaway here is the addition of the disgruntled employee persona. Just like with normal user stories, considering all evil user stories from the perspective of the generic “hacker” persona would limit your vision of how the product could be compromised and bias your perception to only a single use case. Instead, just as you should create user personas to represent all of the major types of users of your product, you should also create evil personas to help you explore all of the potential groups of users who may wish to do you harm. Only by creating actual personas for each of these groups can you be better understand their motivations and, ultimately, their methods.
Unlike normal stories, evil user stories are unlikely to ever end up on your product backlog in their original form. After all, you probably wouldn’t want to invest time in adding the ability for Victor to delete your entire inventory in a single click.
Instead, you would use these stories as the first step of the process of modeling the potential threats that could affect your app and then brainstorming how to mitigate them. It is the output of that brainstorming that ultimately makes its way onto your product backlog as stories.
For example, as a result of your hacker’s evil user story, you may add a story to obscure all but the last 4 digits of all credit cards to a user who is viewing their billing information. Or, as a result of your disgruntled employee’s evil user story, you may decide to add an automated alert to review all active admin user accounts in the system every 30 days to ensure that no former employees retain their access after leaving your company.
As a product manager, you’re probably quite adept at considering all of the possibilities where your product could bring benefit to your users. You’re also probably quite good at considering your different types of users and what their different motivations may be. But the ways in which some of your users might intend to take advantage of your product for their own nefarious purposes is often a blind spot. By considering their different motivations, and ultimately their means, you can better protect both your users and your company from those less scrupulous users who may wish to do everyone harm.
Jeremy Jarrell is an agile coach who helps teams get better at doing what they love. When he’s not mentoring Scrum Masters or Product Owners, Jeremy loves to write on all things agile. You can read more of his thoughts at www.jeremyjarrell.com, see his videos at Pluralsight, or follow him on Twitter @jeremyjarrell.
Category: Productivity
