I’ve been running research plans and collaborative persona development sessions for at least 10 years. In that time, I’ve heard the same set of complaints (ok, questions) more times than I can count.
This article assumes that the reader is familiar with product/software personas, why we make them, and how we use them. Also that they share my understanding of a pretty straight-forward process:
1. Conduct research (I know. This step is complicated by itself, but…)
2. Affinity diagramming to identify patterns in quant data
3. Add information and ideas to patterns to turn them into full-fledged personas
A run-down of the questions that come up in nearly every workshop, and how I talk to them:
“How do we know these are right?”
This comes up especially around the affinity diagramming as we look for patterns in the quantitative data. People wonder if we’re picking out the right information to draw patterns on, whether the patterns we create are valid, and whether they’re sufficient to describe a user base. I usually share four things to think about:
First, it’s essential that we do this together. Yeah, we could have someone go plug all this into a spreadsheet, but my experience is that when you engage teams (especially big teams — product, design, development, marketing, as many as you can get to join in the research), the Personas “stick” in a much more profound way. You don’t need tricks like cardboard cutouts or beer steins, because they are everyone’s babies, and the team understands them deeply and values them differently than if they were someone else’s creation.
Second, if we come across a unique-seeming user that warrants more investigation, we’ll add more research to understand if that user is particularly unique or important, and conduct more interviews. This isn’t carved in stone.
Third, as my mentor Hugh Dubberly points out, there are seven ways to organize the change in your pocket. They are subjectively and objectively different. That doesn’t mean they aren’t valid. Similarly, Personas are subjectively organized. But that doesn’t make them wrong.
Finally, I had the great pleasure of making personas years ago with the Kelley Blue Book team. They had a robust Business Intelligence team who had done plenty of analysis of their own of users. They were open-minded participants (thank goodness) who also took all the information, re-keyed all the sticky notes, crunched the numbers, and two weeks later came back with their big news: Yes. Our patterns worked, our Personas were quantitatively valid, we had their stamp of approval.
As the statistician George Box wrote, “Essentially, all models are wrong, but some are useful.” The question is whether the Personas are not-wrong enough to be useful.
This conversation, and some open-minded listening, is usually helpful in addressing the analytical skeptics in a Persona workshop.
“If I asked customers what they wanted, they would have asked for a faster horse.”
First, there is no evidence that Henry Ford ever said this, although attitudinally this might have been where he was coming from. Second, people who bring this up are generally making one of two points:
1. I don’t believe in the value of customers answers to dumb questions. Totally with you on this one. This is why we *don’t* ask dumb questions like, “What do you want?” But if we had talked to customers pre-Model-T, we might have asked about the best and worst parts of their weeks, the things that trouble people and that make them happy. And we might have learned that a faster mode of transportation that was less time-consuming and expensive to maintain would make people’s lives better. We put that together with the technology available at the time and voila!
2. I am a brilliant visionary à la Steve Jobs and don’t need to hear from users. Ok, these dudes are one-in-a-bazillion, but even if you are, Steve Jobs did listen carefully to customers. He didn’t believe in the kind of research that helped convince people they wanted something that they actually didn’t want — but he did believe in the kind of research and thinking that focused on people’s actual needs and meeting them. And that is what personas are all about.
“But we already have personas from the marketing team.”
Great. Glad your marketing team has personas. Would love to see them.
But… Product personas are different from Marketing personas. A Marketing Persona is generally about reaching a potential buyer and convincing them to make a purchase. A Product Persona is about what happens once someone is using your product, what their underlying goals, motivations and behaviors are, and how the product supports them. Product teams will organize people differently, the research will ask different questions, and the personas will contain different information. There is no duplication of effort here.
Product Personas are useful tools, but are widely misunderstood in ways that are surprisingly similar from company to company. If you are preparing to make the case for Persona research on your team, you might find it helpful to be ready for these common areas of misunderstanding. If you’ve lead Persona research in the past, I’d love to hear from you! Are there any other
complaints questions that you hear over and over again?
Join me for my next personas workshop September 5th in Omaha
I’m presenting my personas workshop Wednesday, September 5th at the Embassy Suites LaVista Conference Center in La Vista, NE. Sign up for the workshop here. You’ll learn how to talk to stakeholders about the value of personas, the distinction between Marketing and Product personas, generative research, and how to identify patterns and develop personas that can be used in your organization.