Anti-Personas
ignorethecode.net
ignorethecode.net
Or how, often we write our personas by defining what they are, when we ought to also define what they are not.
Ex: John is a c-level exec. He wants to feel like he has all the information at his fingertips, but he will not take the time to read any dialog, or apply any filter. They will just “export all”.
Apple pioneered this, and I remember the steve jobs presentation where he talked about all the users, each with a credit card on file (required).
Apple doesn't want me as a customer. That's not a bad thing, or a thing I feel any sort of resentment about. Apple just has a very specific demographic in mind, and I am not in that group.
If the customer is the person your trying to sell to, then who is the anti-customer? A: The person you can’t seem to sell to.
1) Your persona says everything about the target customer relevant to your product. But which of these aspects of the customer persona make them hard to CLOSE? How does this analysis impact your marketing and sales approach? Your product? Your business?
2) Another option is to see the anti-persona as the “failure” to REACH your customer because of hidden aspects. Identify potential hidden aspects that can result in a failure to sell as your product, business or strategy is currently envisioned.
For instance, if I am a B2B product that really requires a large-scale (say, 10,000+ endpoints) deployment to really become valuable to a customer, I really should try to avoid selling to a 300-endpoint small business. And I sure as hell don't want to sell it to some random grandma who's not even running a business.
I won't flat-out refuse, but it's not going to help me or them to give them a product that is mostly useless to them.
It hurts them because it's a waste.
It hurts me because now I'm either setting up a future disappointment, or I'm potentially going to expand my product scope/features to try to become useful to this new group.
A product can't be everything to everyone, and just as it's important to understand what your product will do, and who it will be for, it's important to understand what you refuse to let it ever grow into doing, and who should not consume it as a result.
"No" is the most valuable word you have. Use it. It's easier to go broke by saying "yes" to the wrong thing than by saying "no" to the wrong thing.
Do we validate the anti-behaviors with rejection criteria?
Generally, we accrue these anti-stories as a sort of oral tradition, the classic example of which is "we tried that before, it didn't work." Any [junior] dev worth her salt will, when arriving on a team, start to question all the Chesterton's Fences strewn about the place. That's when we start reciting the anti-epics! Why not codify it?
Admittedly, from my perspective, Chesterton's Fences are technical in nature, but I imagine analogous interactions occur at the product level.
When creating line of business apps these chestertons fences can appear when a product owner does not fully understand the complexity they're supposed to be owning, and they remove / fail to capture critical validation steps in a process for the sake of efficiency.
Probably not something to do in your regular sprint planning, but as a part of strategic discussions, maybe at an offsite, the idea of creating a few anti-epics to help build focus seems like it could have some value.
But I was actually considering it as I wrote, thinking perhaps an anti-user story for a site like HN would be "As a sales person I want to astroturf interest in my company's product using puppet accounts so that I can generate sales." or "As a nation state I want to brigade topics that present my nation in a poor light."
So yeah, facetious, but legitimately considering it too.
As an example: An anti-persona could be "An abusive ex-partner who wants to harass another user of the program", and the new work to be created would be things like "adding the ability to block other users", or "adding visibility controls" etc.