Hi, my name is Eric, and I used to hate personas.
I mean, hate is a strong word. More like, “was equal parts jaded by, and skeptical of.” The reason for this is all the different ways personas can fail to do their job.
On paper, personas sound great. They’re “a way to model, summarize and communicate research about people who have been observed or researched in some way.” However, in the real world they oftentimes run afoul of circumstances that conspire to keep them from delivering on their promise.
Where personas go wrong
An all-too-common example of this would be a business assuming what people want, and then creating a persona to back it up. Without proper research, this cart-before-the-horse approach is nothing more than a risky and potentially very expensive guess. Startups are especially susceptible here, in their rush to crank out features and be first to market.
Another common example, probably the one I like least of all, is where a persona is used as a tool to drive a stakeholder’s personal agenda.
Here, the intent behind a persona is flipped. Someone with clout has a pet idea or feature, and uses a persona’s attributes as a battering ram to smash through criticism (“Of course Betty Buyer wants in-browser notifications! It’s a great way for her to know when we’re having a sale!”).
Because of these and other abuses, I had historically sworn off crafting personas, or using existing ones as anything other than a high-level cheat sheet for understanding where a company’s focus may have at one point been (failing to keep personas up-to-date is another common way they can go wrong).
Giving it another go
At thoughtbot, we’re big fans of the Product Design Sprint. In my experience, Product Design Sprints are the quickest, most efficient, and economical way to dig into previously uninvestigated concepts and motivations to de-risk and streamline an idea.
Product Design Sprints help to validate if the idea has market fit before even a single line of code is written. Compare this to committing countless hours and tens (if not hundreds) of thousands of dollars into creating a product and putting it out into the world, only to see it garner no interest.
Product Design Sprints center around a Problem Statement, which is a way to identify:
- If there actually is a problem,
- What the problem is, and
- How the product will solve it.
Solving problems
To effectively solve a problem, you need to understand what the underlying motivations, emotions, and issues a potential customer possesses.
In the Jobs to be Done world, the classic example is selling milkshakes: Research revealed that instead of new flavors, customers wanted a thicker milkshake, so as to not spill their drinkable dairy snack on themselves while driving.
It was only by investigating the underlying motivations behind how and why people purchase milkshakes that the company was able to turn a profit. Their previous attempt—churning out new flavors—didn’t provide the necessary framework to allow for this kind of innovation to occur.
So, how do we investigate underlying motivations?
Enter personas
I’m not talking about a worksheet full of cutesy names, glossy headshots, cryptic charts, colored gradients, and brand logos. I’m talking about something that gets a room full of people thinking about what a person wants, not what the business wants.
Before you introduce the Problem Statement, create a persona. Getting the Product Design Sprint participants to focus on this before the problem is introduced helps to direct their thinking—if you do this right, that person will become their customer.
To build this persona, we slowly work from the great heights of extrinsic motivations down into the murky depths of the intrinsic.
Extrinsic
These motivations exist outside of the individual—stuff like money, fame, praise, etc. For our personas, we have two subcategories of extrinsic motivation: Values and Aspirations and Requirements.
Values and Aspirations
I introduce these two first because they’re the easiest to think about. Values and Aspirations can be things like what they’ll get, how they’ll feel, and where they want to be. These motivational factors are powerful—they address someone’s self-image.
Values and Aspirations are typically the end state the business is already thinking about. For example, an app that helps you take care of your pet dog could touch on desires to be seen as both caring and competent by your peers at the dog park.
Requirements
Requirements are things the business may have considered, but in my experience, only at the surface level. In digging into them, a business may push back on the issue, believing that they have captured them as Values and Aspirations. However, one of the goals of a Product Design Sprint is to really dig into the whys and uncover previously unconsidered motivational factors. Because of this, we need to do our due diligence and push one step deeper.
From a potential customer’s perspective, Requirements represent friction. Sometimes they are to the point of being a deal-breaker, but can often be negotiable if there’s enough value demonstrated up-front. This friction manifests as personal or environmental qualities.
For our dog care app, an example would be needing the app to not use too much data. While it might be difficult to find wifi outside, someone might upgrade their data plan if it means their beloved pet is taken care of.
Intrinsic
Intrinsic motivations are highly personal, and may never be outwardly communicated. Failing to satisfy intrinsic motivations is a lot more risky than failing to satisfy the extrinsic motivations. Intrinsic motivations may also affect extrinsic outcomes, just to make things complicated.
Satisfying an intrinsic motivation should lead to feelings of personal gratification. This makes them very much worth paying attention to.
The two subcategories of intrinsic motivation I use for persona creation are Limitations and Fears. These are the things a business typically avoids thinking about, either consciously or subconsciously.
By slow-boiling our way to intrinsic motivations, we’re able to discuss them in a safe, structured way. Here, we’re leaning on previous Product Design Sprint activities setting up a culture of open exploration, expression, and collaboration. These are difficult concepts to explain but critical to the overall design. Let’s look at Limitations and Fears one step at a time.
Limitations
Limitations are things that are hard and fast stops—something that would keep someone from using the solution entirely. The difference between Requirements and Limitations is Limitations are implicit and customer-centric, while Requirements are presumed and business-centric.
If motivating factors are sufficiently strong enough, a person might be able to work around a Requirement. Limitations, however, are functionally unsurmountable.
An example of this could be the person’s Requirement being an Android-compatible experience, but the product is only available as an iOS app. In this scenario, the person may hypothetically be able to find an Android device (borrowing, buying, etc.) if it guarantees they ultimately get what they need.
In the case of a Limitation, an example would be if the app charges a monthly subscription that is too expensive, even if the dog owner got a raise or a part-time job.
Fear
Following Limitations comes our last motivation: Fear.
Fear is the other side of the Values and Aspirations coin. It exists largely outside the range of conscious thought, yet still affects a person’s behavior. While not everyone is ultimately motivated by fear, we would be irresponsible if we ignored it.
You can have gorgeous visuals, clean code, and seamless user flows, but it all is for naught if you fail to accommodate a person’s unspoken anxieties. Worse, failing to address fears may lead to a situation where a customer who feels betrayed by your product actively talks other potential customers out of using it.
Working with fear isn’t exploiting someone’s weaknesses. Contrary to that, it may be uncovering powerful motivational factors to figure out how to equip someone with the tools they need to address major obstacles and preempt unnecessary hardship. This can be incredibly powerful.
For our dog care app, a fear could be someone or something harming their dog. This fear isn’t tied directly to the app, but it will most likely manifest when initially evaluating it. It could be poor care instructions, or disclosing your dog’s location to the wrong person. In putting ourselves in the role of the villain during the Product Design Sprint, we’re able to nip these scenarios in the bud before they get to the point where a customer could even consider them being an issue.
Facilitation
This is something that can be conducted in 10–15 minutes, provided that the company has done at least some initial research and provided it in the Prepare phase. It also shouldn’t be a deep psychological dive. That’s something you can really dig into afterwards if the prototype validates your hypotheses.
Introducing the idea of a persona’s name suggests the possibility of other personas. To focus on the problem we’re solving as a group, I try to completely avoid writing a name down altogether.
For the actual act of capturing the persona, I write down only one subcategory at a time until it feels like it’s been discussed in full (be sure to leave plenty of room for bullet points).
When discussing Fear in particular, it is important to set up guardrails against exploitative or predatory behavior outside of the Product Design Sprint. Understanding your customer’s fears is not a license to exploit them. Rather, it is a way to establish trust in what you’ve created.
Two such strategies for mitigating this could be reminding the group about the culture of “yes, and…” (good for course correcting), or the huge potential for consumer backlash (good for putting your foot down).
Being personable
Ending on fear is a bit of a bummer. I’ve learned that acknowledging that fact directly can help, especially if you work in a joke or two afterwards.
You can also build your way back upwards. Read the written-down qualities out loud for each subcategory attribute the group decided on, starting from Fear and ending with Values and Aspirations.
After that, it feels natural to introduce the Problem Statement to the Product Design Sprint participants. Transition with a sense of enthusiasm, and you’ll have a room full of people who understand a far-more-nuanced view of who their potential customers could be.
Wrapping up
My name is Eric, and I used to hate personas. Now I use them as a powerful tool to focus on what really matters most: the user.
I’ve found this approach to crafting a persona to be really effective at getting Product Design Sprint participants to consider more angles of their problem space, and to open up their thinking to less-conventional pathways. This kind of approach to persona-crafting is also great for segueing into the Diverge phase the next day.
If you’d like to see how a Product Design Sprint—possibly including a well-crafted persona—can help your business, don’t hesitate to get in touch!
Thank you to Louis Antonopoulos for his feedback.
