Podcast: Play in new window | Download

Sean: [00:00:00] So Joe, we’ve been using personas for years now for the software products that we produce for our clients. And in general, they’ve been used by marketers for decades. So we’ve found them valuable because everyone on the team has a better ability to empathize with the users of our products, would you agree?

Joe: [00:00:18] I do. 100%.

Sean: [00:00:19] I think that better personas are those that help inform the teams around subtle feature decisions, the day-to-day decisions that they make when looking at features. They can help to inspire and our connect developers and our teams, our designers with the users. In fact, I think that the more accurate a persona is, the more likely we are to empathize with them. We’ve talked about having them databased and improving them over time. Joe, what do you think the goal of a persona is?

Joe: [00:00:47] Yeah, so the goal of the persona, in my eyes, is not only to accurately represent the greatest number of your users in your system, or our users in our systems, but like you said we want to bring the team emotionally closer to the users. Because a lot of times our team, you know they’re building it, but they haven’t really talked to the users themselves, or talked to the clients themselves, or the sales people, or the service reps, so these personas really help them empathize with those users and their core concerns. And, you know, we even go as far as identifying what the key emotions are for the users as they use that product. Lots of times we see with financially-centered products, people have a lot of anxiety, and they are nervous, and they’re scared because it’s tough to deal with that kind of subject matter sometimes. They might feel like they’re dumb because they don’t understand certain terms. But ideally, our product development team, we want them to see the world through the users’ eyes to the greatest degree possible. And so to do that, to be able to see through those lenses, you have to understand the context of our users. What are their concerns? What are the jobs they’re trying to get done? How do we help them with their frustrations or whatever that emotion is that they’re feeling when they’re using our products?

Joe: [00:02:03] So to give you an actual example, before we dig in further; I was at a conference a couple of years ago and I was at a particular session and the presenter talked about personas. He told a story about when Apple was building the Apple Watch, which is several years ago now, and when they were creating it, Apple had to make a kind of a decision for what version one was going to be. And ultimately, we can now see that they chose for it to be for health-conscious individuals. And we saw that with how they do the heart rate tracking, and tracking your steps, and the beautiful UI’s that are around your health. And so they made a persona as they were working through that of a user, in this case a man, who would be using the watch and wearing the watch. And part of the persona was that he likes to run outside. So that led to discussions around, “Okay so the watch has got to be really snug on his wrist so it doesn’t fall off when he’s running,” or “Maybe if he does drop it and he’s in the woods or something, it can’t scratch easily.” But then someone asked, “What if it’s raining outside?” And that led to better prioritization around the watch actually being water resistant. And so that’s a really basic example, but we see in our lives day-to-day when we’re using products. Like we say, “How did they not think of that?” So personas help us think of that, basically.

Joe: [00:03:23] And what’s cool about personas is they really aren’t just for software. You know, in this case this was a piece of hardware with a software element, but we can use them in all kinds of different ways. So I know Sean, when we talk a lot, we’re always talking to our users and our team members about the personas, but can you speak to what are those key elements or key things we should be thinking about when using the personas day-to-day?

Sean: [00:03:45] Sure. So first of all, you have to accept that the personas that you create will never be perfect. Your team should always be refining them and incorporating learnings as often as possible. You know, we talk a lot about the voice of the customer and we’re going to have another podcast episode, or maybe many, on how to manage voice of the customer and how to make sure that we’re getting good voice of the customer information incorporated back into our products, but it’s just as important to get those elements incorporated into the personas as well as we learn things about the people that we’re building these software products for. The second thing is that every product has multiple personas. In fact, in an idealistic world you’d have one persona for every single user. But that’s not generally economically feasible, right, so we need to prioritize and continuously refine the personas that we are serving with our software product. And our team should create an inventory of personas and decide together, “What are the right number of personas to manage and groom for the product?” Joe, I know you’ve thought a lot about how many personas is the ideal number personas.

Joe: [00:04:37] Yeah. So this is something that depending on who you ask, they might think that you can get down to just one persona for a product, or you could have fifty. And so really what we’ve found is not necessarily a magic number, but a magic range. And so the range that we typically aim for, and I’ve seen this in other spots too, other places, but what seems to work well is five to nine. And the reason for that is, like we’ve talked about, there’s lots of times many consumers or many users of a product. And that means there could be potentially a lot of personas, but we can’t be making dozens of personas and expecting a team to be able to empathize with all of those dozens of people all at once.

Joe: [00:05:16] But we also don’t want to oversimplify, because then we’re not looking through enough lenses to really make sure we’re considering what we need to for the product as we build it. So what we do is we try to think through the base users, we prioritize them, but then also to stay within that five to nine range, we look at the roadmap and we think, “Okay we’re targeting three months out, six months out, nine months out from now, that these new features might be built and these new personas may need to emerge.” And so we like to look at the roadmap and use that as a tool for, “What are the personas we need to be considering as we build the product today?” Because if we know that our persona’s name is Bob, and Bob’s going to be using the product not today, but six months from now, we want to be considering Bob as we make choices today. That can help us scale the product, it can help us build features better, structure the data better, there’s a lot of decisions that we can make in a better sense when we know who the future users are as well as the current users. So I’m kind of getting ahead of ourselves here talking about five to nine. Sean, I know you’re really good at talking about convincing people how to get started with personas, like where do you even start when you’re maybe not using persona’s today, but you want to be?

Sean: [00:06:24] Yeah, well you need to start somewhere or you don’t get anything done. So to get our software built and tested to start with our MVP’s, we always start with at least one. But how do you pick the one you start with, right? That’s the challenge. And we have a good process that we use for prioritizing personas. I’ll briefly describe it, but we can probably dedicate an entire episode just to that. If I draw a pyramid, and I talk about all the different user communities, and we identify the entire group to prioritize and choose one persona that we’re going to focus on, at least in the short run. If you don’t choose one, you’d end up trying to build things for too many people and it’s very hard to keep focus. So we always force our product development teams to have one primary persona and to balance out how we’re developing features and how we’re taking on different perspectives for a software product. So what do you think about that, Joe, what’s your experience been?

Joe: [00:07:11] I totally agree. They’re not going to be perfect when you start this, you’re going to find out what works for you and what doesn’t. It’s definitely something where just, you know; get a minimum viable persona, for lack of a better term.

Sean: [00:07:24] Yeah exactly.

Joe: [00:07:24] Just get something basic in place and just improve from there, because it’s something that you’re going to learn over time. You’re going to start to feel if you’re hitting the right persona’s or not, like if you’re actually understanding, you know, who your persona is, and then one day you actually see a user using the product that is that persona. So that’s really cool to see. But just in terms of getting started, basic stuff: understand who the core demographic is. Basics: gender, age, income level, education level, Where do they live? Climate could be a factor. Do they have kids? What’s their occupation? Where do they come from in their life? What’s their background?

Joe: [00:07:58] A lot of people think that those kinds of attributes of a persona can be really fluffy and not useful and they’re more for just making commercials and stuff. But, I love to use examples because it helps people to kind of connect the dots. We were working with a healthcare organization discussing a consumer facing product. This is basically where their customers could book a medical appointment and perform some other basic tasks through the app. And in our case, our persona was a woman, and she was in her thirties, she was a teacher, she had two kids. And as we talked through just this basic information, a couple of key insights that came out of the discussion were, “Okay, so she’s a teacher, so she’s got classes all day, which means in between classes she’s really only got a couple of minutes. And so, if she needs to schedule an appointment for one of her kids, this has got to be a super quick process with this little friction as possible.” So we can literally use that in our user testing eventually- can she get this done in ninety seconds, two minutes? And secondly, she’s got kids, but she’s got her own health to manage as well, so through the app it’s got to be really super-simple to either be able to toggle between herself or her two kids and who she’s managing appointments for or seeing test results for. So that kind of experience we’ve got to make sure it’s really seamless and she knows who in her family she is reviewing the health care information for. So that was really, really important, and just those basics got us there.

Joe: [00:09:16] I would say for the team, bringing it back to empathy, definitely give them a name. It can be a fun name, you know a name that’s not typical, or whatever is going to help. At the end of the day, sometimes the different names are more memorable, but where I’ve seen that really play off is when the team actually starts using the name, they use it in their user stories, which we’ll talk about in a future episode- how to write user stories that are really great for the team. But they also talk about it like it’s a person in their day-to-day, in their meetings, everything like that. As far as we brought a new team member to our project one day and people were talking about Anna. And for about a week, somebody thought Anna was a real person working here until a team member said, “Oh, no that’s a persona.”

Sean: [00:09:58] Yeah.

Joe: [00:09:58] So the team was really using them and empathizing with them in that case.

Sean: [00:10:01] I’ve heard stories of some of our designers actually having conversations with their personas hanging on their workspace walls. What are your thoughts on using a real person versus like a known customer that they talk about a lot versus having a fictitious persona?

Joe: [00:10:15] Yeah. So the real customer or the real user has not worked out so well. What happens is, as we’re using the persona with the team or with the client, in this case, they get a little too attached to that person, and you know, that person may have a couple of things about how they experience the product or how they use the product that really isn’t typical for the majority of the rest of the users. They might have some edge cases or specific use cases for just them, and it’s been detrimental in that case. So we try to keep it fictitious as much as possible, but then take inspiration from the real-life calls that people have received with these users or the letters they’ve received, things like that.

Sean: [00:10:51] I agree. I’ve found that when you choose an actual customer, they tend to pigeonhole and try to answer questions from that specific customer’s perspective and it doesn’t work.

Joe: [00:11:00] Exactly. Okay, so again I love giving examples. Let’s come up with a persona here on-the-spot to some extent. Let’s do a real estate agent.

Sean: [00:11:10] Sure. Let’s say Donna is a 43-year-old real estate agent who works for the largest agencies in Santa Barbara, California.

Joe: [00:11:18] Okay, does she have a dog, is she married?

Sean: [00:11:20] Let’s say she lives comfortably in the suburbs with her husband, an attorney, their two children, let’s give them names too. Sarah and Michael. Sarah’s 12. Michael’s 15. And they have a dog named Ian.

Joe: [00:11:29] And Santa Barbara is not cheap. So what kind of lifestyle do they have?

Sean: [00:11:34] Together they make about 180k per year. They vacation twice a year, once on a school holiday week, and one time in the summer, let’s say for two weeks.

Joe: [00:11:42] All right. Donna is ready. So what we typically do next is we ask two basic questions about Donna to help inform us about how she makes decisions. So what we ask is, “Is Donna more data-oriented, meaning she likes to look through numbers, look through all the nitty-gritty details, or is she more people-oriented when she is using the product, meaning she likes to hear stories, get opinions, testimonials. What end is Donna on?”

Sean: [00:12:10] Right. So when we ask these questions, we have to think about a couple things. So if our product, if our software product is aimed towards the general population, we’re going to get a range of answers here, right. But if we focus on Donna who’s a real estate agent, and we think about what Donna is doing, let’s say this software product that we’re working on is a product to serve real estate agents. What mindset is she most likely to be in when she’s performing the job that she has to perform for the real estate agency that she’s working for? And in this case would tend to find that the Donnas are probably more people-oriented, right. She’s selling, she’s a real estate agent, and she’s in that frame of mind of, “How do I get people to buy from me?” So she’ll probably be more people-oriented and intuitive in this specific case.

Joe: [00:12:52] Right, exactly. We always like to make sure if the user, in this case, Donna, more extroverted or more introverted? So when they’re making decisions, are they more vocal, or are they a little more reserved when making decisions?

Sean: [00:13:06] Right. And in this case, we would say Donna, as a real estate agent who’s in a selling mode, is going to be more extroverted, more assertive on that one-to-ten scale.

Joe: [00:13:15] Totally. Well think about just something really simple like when you go to buy a TV. I have all these developer friends who are more data-oriented and they’re more introverted, so you know what they do? They make spreadsheets and they have spreadsheets of every TV that they’re looking at and considering. And what you would want to give them is all the specs about the TV: how many pixels, what’s the top resolution, how’s the sound quality? Is it a smart TV? What are the features? Everything, and then they’ll go home and they’ll toil over which TV they’re going to pick. Whereas in this case, Donna, more people-oriented, you want to touch on, “You’re going to have great family experiences with this TV, you’re going to watch movies together, you’re going to have memories,” all that kind of stuff.

Sean: [00:13:57] But the key thing here is, we ask these two questions. So first question: “Are they more people-oriented or data-oriented?” The second question: “Are are they more extroverted or more introverted?” Answering these two questions allows us to draw a four-quadrant model, otherwise referred to as the DISC framework. That’s a whole other subject that we can talk about another episode, but it’s an important one. It allows us to just put her into a quadrant that we can then use to make decisions around the user interface.

Joe: [00:14:21] Right, and that’s D-I-S-C just to be clear for everyone.

Sean: [00:14:25] So the DISC model goes way back in social sciences to Maxwell Maltz and Marston Maston, other folks before them even. It’s kind of a socio-dynamic model for personality analysis. The D stands for driver, the I stands for influencer, the S stands for supporter, and the C stands for compliant. And we found that it’s a super simple model. It’s just a basic framework for figuring out, “How do people make decisions, interact with technology and other people?” And we use it as a way to influence our design decisions and our feature decisions in our products. So Joe, now that we’ve established where they are sort of on the personality scale, how do we determine how much competence they have? How much do we need to build them up in terms of the use of the app or in the specific domain?

Joe: [00:15:08] Right. So you know, a lot of times when you download an app on your phone nowadays, the first thing that you see when you open it is kind of like a step-by-step how to use the app. So as we’ve talked to users and listened to feedback and seen where maybe the product is confusing, we’ve essentially boiled it down to two types of competency. You can really know about the topic at hand, but you may not know how to use the software, or vice versa. You could be like super savvy , you try a lot of apps out, but maybe you’re diving into a topic that’s new to you.

Joe: [00:15:39] So what we do is we look at one type of competence that we call technical competence, which is, “Do you know how to use web apps?” You know, if you’ve got a filtering mechanism, is that something you’ve seen before, you’re used to using, like Amazon’s got. And then on the flip side, we talk about domain competence. And that is, “Do you understand the content at hand?” essentially. If you’re using a product that’s in the financial industry, do we need to define for you what a 401k is versus a Roth IRA, or are you already familiar with that terminology? So we use those two types of competencies because it’ll affect how we on-board a user, to what extent, and then also during the experience, “How easy does it need to be for them to access help features, or support features, or ask questions, or have an FAQ, for example?” So those two have worked out really well because those especially lead us to make some pretty important product decisions, especially around prioritization of how we prioritize on-boarding into our experience.

Sean: [00:16:44] Right. We’ve found that knowing where Donna is starting, knowing where our user persona is starting, gives us the ability to better construct the on-boarding experience.

Joe: [00:16:54] Right. And so I know you have talked a lot to us about the work of Clayton Christiansen. Can you talk about what he’s about, how we’ve used some of his work?

Sean: [00:17:04] Yeah, well he’s written a ton of books, so trying to describe all of his work in one podcast would be impossible, if not challenging. The next thing we do is we think about what we call the jobs to be done framework, which is from Clayton Christiansen’s work. When a user decides to use a software product, they’re using it for a reason, there’s a job that they’re hiring that software product to do, basically. And in the context of our product, we want to understand where her goals are in the persona documents. We catalog her goals in terms of the jobs that she’s hiring this product to do.

Sean: [00:17:32] For example, if we’re building an online vacation planning tool, the goals might be: “find possible vacation locations that might fit my budget, location, and timing restrictions,” or “find possible activities to do while I’m on my vacation,” or “find places to eat and sleep on my vacation.” And you could take it to the nth level with that. Once we’ve identified what the goals are, we want to identify the pain points that are standing in the way of the user accomplishing those goals and align what we’re trying to do with our goal of turning them into an advocate.

Joe: [00:18:00] I’ve been hearing a lot more about jobs to be done myself, I’ve been reading a lot more about it, I’ve got a new book on my desk here that just came for me to read as well. But I heard a certain example that stuck with me, it was from a hardware company, and they sell drills, right. So when they were looking at how to market the drill, sell the drill, build the drill, they always said to themselves, “Our customers aren’t buying our drills, they’re buying the hole in the wall that the drill creates.” And so I think that that’s kind of an interesting way to look at it. You know, your product is a means to an end, essentially, at the end of the day for your customers. They’re trying to get something done. So you want to think about , what is it that you’re trying to get done, and then how can your product facilitate that?

Sean: [00:18:39] Right. Another great example that Clayton uses in his book is the milkshake example. They found at one of the fast food restaurants that he studied, a lot of people were buying milkshakes in the morning. And it turned out that the job that they were hiring that milkshake to do was to make them feel full and fulfilled, but not too fast. Like, the act of actually taking the milkshake in slowly, because it was slow to drink, made them feel like they were full, basically. So they were hiring the milkshake to make them feel full.

Joe: [00:19:07] Yeah that’s a good one. I forgot about that one.

Sean: [00:19:12] Cool. So lastly, we establish KPI’s for the product in the context of what we call our journey framework, again, another episode that we’ll do in the future. But we have to have a set of KPI’s that we all agree on for the persona, like how are we making sure that this product is successful in the eyes of our user and in the context of our business? And with all of those things in place, every member of our team will be armed with the ability to ask themselves, “How would Donna want this feature to work?” And the result is a better product on all fronts, at least that’s been my experience. Would you agree, Joe?

Joe: [00:19:44] Totally agree, and we’ve got some other parts of our personas, or attributes of our personas, that we’ve been playing around, with trying out. But, for a starter set, if you haven’t done any persona work yet, or you’ve got some more basic personas, the things that we talked about today, these are going to be a good either first step or next step as you guys get to use personas more in your work.

Sean: [00:20:06] Cool. In terms of building product momentum, we believe that having a really solid persona is a key part of the vision. Like understanding who we’re serving and how we’re serving them will ensure that we at least have a big part of the vision for that product covered, and getting everybody aligned on that vision this is going to be key. So making sure that your team and everybody is working on the product agrees that this persona is the right persona and has the ability to influence that persona’s description in the future is important.

Sean: [00:20:33] One last thing too, we also believe that the personas need to be beautiful, like designed and beautiful so that people are proud to hang them up in their workspaces, on the walls of their workspace. Because we believe in customer empathy at the end of the day as one of the key driving factors for successful products. So make sure that your personas are easy to look at, easy to consume, and actually help your development teams influence product decisions every day.

Interview Transcript:

Sean: [00:00:00] So welcome Jeremy, thanks for joining us today on the momentum podcast. We’re extremely grateful to have you here. So we’ve worked on a few projects together in the past when I’m over at Paychex, and we’ve gotten to know each other a little bit. You’ve been doing software product development, you’ve been in this space for a long time, and you have a unique thing in the world that a lot of people don’t have today. You’ve gotten the opportunity to watch Paychex go through really building the same applications many different times because you’ve been there for a long time, and you’ve learned too. You’ve kind of grown up in the software product development space. I’d love to learn, that’s what you’re here for today. We’re going to learn a little bit about that, but our subject matter is today’s about persona. So we’re going to dig deep on the persona thing. Would you mind sharing with our audience, Jer, a little bit about your role, your history, your responsibilities at Paychex.

Jeremy: [00:00:51] Not at all. So number one, I kind of started with the company back actually in an operational role and working my way into a development organization after having some opportunities via an acquisition that the company did that happened to be written in a coding language that I had some experience with. You know, right place, right time and an opportunity to get in and start getting a little bit more involved in the technology side of things. And with that, you know, over a number of years of development and working on one of those platforms, I got the opportunity to take over and move into the program and user experience space and some other pieces. And that’s really where things started to evolve that you’re referencing as far as the numerous times that we’ve gone through some transformations as a company. And and that really happened in large part due to how the industry was changing both from a user experience perspective and from an HCM now. What was payroll, then a payroll and HR type of industry.

Jeremy: [00:01:49] And just to give you a feel for some of that, that’s kind of very interesting and the topic: as we went from a world where, as a company, we were doing very well in the payroll space and we started out very much a call-in, call-out with a little bit of a dabble into an online payroll experience, mostly just for people to drop off, you know, hours and amounts on their employees and that was about it. And as we got into a larger client space where people were having hundreds of employees and doing a lot more themselves, we started into a world where we did an acquisition where people were using PCs and entering data into there, and so they were bringing in a disconnected world and just connecting up to drop things off. And it really was very much a basic employee information and then shipping payroll. And so it was kind of contained to a handful of use cases.

Jeremy: [00:02:41] We then evolved into a world that went much more online, and through those acquisitions, started adding on more and more expectations of the user. So people wanted to have the ability to track time off online, not just to put in 40 hours a week. People wanted to have the ability to start doing things like track performance of individuals. And so, you know, we acquired a number of different products, grew products ourselves. But every single one of those things were in a world of integration from a data perspective and not really from the user experience.

Jeremy: [00:03:15] So, you know, as we did that evolution for payroll and got employee and payroll management evolved into kind of one experience online and did that update, people had all those different product lines from us but they weren’t integrated from user experience perspective. And those individuals would have to maintain things that are baseline capabilities in any one of those. So you acquire a product for performance management, and it has a way that you track basic employee information, which you also already have in payroll, which you also already have another product lines. So we had to go through an evolution to start moving those things together, and at the same time the world was coming into the mobile experience, and so we had to do a lot of work there to start to introduce a native application. But then eventually, people wanted everything to work simultaneously on different devices with the same experience. So yet again, another evolution where you bring those things together. Not all complete recreations, but you got to start to evolve those experiences one after another. And you know, that comes with a lot of great opportunities, a lot of great challenges, and opportunities to go after from both a technology and experience perspective.

Sean: [00:04:23] Yeah that’s awesome, and again, I think that what you bring here to this discussion of what we’re talking about is extremely powerful because you’ve seen these transformations occur all while working on the same sort of product set and the product domain and the same personas really that you’re targeting.

Jeremy: [00:04:41] That’s correct.

Sean: [00:04:42] In today’s day, people tend to job jump a lot, right. So to have the experience you’ve had with this one product, it’s awesome. It’s awesome for us to be able to tap into it. So again, thanks for being here.

Joe: [00:04:56] So you talked about, you know, having to go online at some point and going to mobile at some point. So the personas are typically part of the overall vision. So how do you typically just get started with that, with the vision and then working into the personas, where do you even start?

Jeremy: [00:05:12] For us, you know, the big thing is trying to understand the various users and what their needs are before we even start into what the vision is for where we need to take things. And part of it that gets extra complex, for the stuff that I’m involved in, is the fact that we have a number of different types of users that can be into the same system. So everything from, an employee who just has to go in and punch in an hour or maybe look at their check stub, to an administrator who is responsible for everything in a certain sized company. But the extra complexity comes into play where you have a system that can have a client that’s, say, a construction company with a handful of employees and then a company that has, you know, a number of locations of the same business, say a restaurant or something like that, and they’re all co-owned by the same person. And some may be using a CPA who also comes with the system, or not. So starting with that user, that persona, and understanding what the needs are is critical. And then from there you can build into what, from those needs, what the vision might be, and you really need to understand from that that you may have varying needs amongst them, even in the same exact system.

Sean: [00:06:33] You guys have this unique scenario too where your payroll manager is also an employee. So you have to be able to jump between different personas, even for the same person, because they’re going to have the same needs in different scenarios. It’s interesting.

Jeremy: [00:06:54] Yeah, I’ll tell you what, it brings some real challenges that are fun to try to overcome in the sense of creating a world where you may have somebody who needs to go in between both in the same session inside your application. So for us, you know, we found it best to be able to create an experience that’s very much driven towards them operating as an employee, and then one that is clear that they’re operating as the administrator. So that way they can understand the difference between systems are in when they’re operating is what’s impactful to them personally, and also so that we can have an experience that, for an employee coming into our system, it feels a system that they want to be in and it doesn’t feel so institutional and transactional. But for an administrator, it can go the other way.

Joe: [00:07:46] Right. So we talked about where you start. And it sounds like you’re really starting with the user, which is the persona. And so, if that’s the case it’s got to be really, really valuable from the start. So in your opinion, what do you think makes for a really valuable persona?

Jeremy: [00:08:03] And so for us, you know, it’s getting and understanding the various types of personas that you need and the needs inside of each one, what might be motivational, but also what might be a frustration or a distraction for them, as well as really understanding the varying skills that may be brought to the table. So when you have a very diverse base of users and you get into them, try to fit them into a reasonable, manageable number of personas, it’s really important to understand that you may have somebody who, like I said is out on a construction site, rarely ever goes onto a piece of technology, and you may have somebody who might be a data guru and wants to do really complex analytics and things with the system, and understands technology really well, and may jump between devices even in the same day. “I want to start something on the desktop and move on to a tablet or a smartphone in the same even even transactions at the start and stop.” So understanding that diverse user base and getting it into a manageable number of personas is really critical.

Sean: [00:09:20] All right. So you mentioned the diversity of the customers, right. So in your space specifically, let’s talk about the employee products. Your consumer base, your persona, is essentially everyone. Everyone who works, which is most people, most adults in the world, right. So how do you hone in on individuals to make the solution more personalized? Is that something that you…like how do you think about personas from that perspective…like how close can you get to the actual needs and desires of the employees, and how do you handle that?

Jeremy: [00:10:00] Yeah, so we do a couple things to try to make sure that we’re really understanding the user base that we have and what their needs are. You know, everything from what we’re doing just from analytics to get profile data and information about the individuals that are using our system to focus groups and some user research, both industry-wide and and inside of our system and inside of our client base. Because, you know, it’s really easy to look at industry trends and what is going on out there, and people talk about things like the difference of a Milennial user today versus somebody who’s maybe a Gen Xer or a Baby Boomer. If you start designing for things that maybe haven’t actually occurred in your base, you can get yourself in trouble. But also, only catering to your current base and not being ahead of that can be the same issue that’s just lurking and waiting to hit you. So for us, it’s very critical for us to not only survey and pull real life users into our both research activities our testing, but to also get those people to have the opportunity to provide in-app feedback to us. Combining that really gets us to kind of an analysis that allows us to know what’s really going on and what people are using, and what’s important to them.

Sean: [00:11:21] Right. Do you actually incorporate that information into some sort of an artifact, like into a persona artifact, or does that data sit, because that’s a problem I see in the industry. There’s a lot of user research and data analysis going on but I don’t see a lot of companies really taking advantage of the research that they’re doing. Do you guys feel that you do take advantage of a lot of the research, how do you do that? How do you take advantage of it? Like how do you put it in front of the people that are building the products to actually make it useful?

Jeremy: [00:11:54] Yeah, sure, so we have a couple of different groups inside of our overall user experience organization that handle getting that information. And obviously with the number of things that we have going on at any given time, we have ninety-plus teams agile working on our software. We obviously have to go after the most critical projects to do that research, but we have a team that does research and another team that does field studies. And they develop a set of content that’s put in front of the agile teams as they’re getting through their release planning and getting ready to kick off an effort so they have an understanding of what those key components are and what the feedback is of our end users. In regards to your question of, does that translate into like a specific persona that’s managed? We definitely do create personas. I think to your point, it’s a little difficult, still. There’s not a great way to keep those things clear and up-to-date that fits the need of every single one of the different efforts going on. So we find ourselves actually producing that content; feeding it into our design team and our leadership team that does the vision. And for us, we start a vision and build it into detailed designs as we go, and that’s based off of both the information coming from our product teams as well as what we develop from that research and those field studies.

Sean: [00:13:23] Yeah ninety teams, man, that’s amazing. Ninety agile teams, that’s huge.

Joe: [00:13:28] Well you think about ultimately how many people that is. You want them to be empathizing with the users, and we do that through personas. That’s incredible, you know, to think about the scale of that and how valuable a persona can be in making all those people thinking about who these end users are as they build the product. So let’s say, you talked about rebuilding the products and the history, and that’s excellent. I know you guys are coming up with new ideas, brainstorming new products. So when you when you have a new product idea, do you approach the vision, and then the personas obviously, differently than for when it’s an existing product that you’re rebuilding? How do you go about that?

Jeremy: [00:14:12] Absolutely. I think there’s parts that overlap into both, but one of the key things for us is that when you get to a point where you have a large enough user base like we do, you know, eleven, twelve, thirteen million sessions at any given time, you know, millions of users are logging into our system. When you’re changing over something that already has an existing base like that, you have to be very cognizant of not losing them and losing that engagement from that group, while also knowing that we are going to continue to add more and more new users as we go. So that one kind of has to fit both worlds. Whereas when you’re building something completely brand new, you kind of get that opportunity to start from scratch and not have that drag effect of, you know, the way things have been done in the past.

Jeremy: [00:14:59] And that’s what made things so challenging for us. When you go through all of those transformations we talked about before, there is this sense that you get varying groups who have gotten very comfortable with what they’re doing, and so developing something that’s very simple yet powerful, something that is very intuitive and makes people feel like they can jump right in and use it day one is critical to not lose the engagement, that base that you already have. And again, like I said, you still want that simplicity in the new product, the new users, but you have to take a very different approach when you have an existing base.

Sean: [00:15:34] So you mentioned earlier that when you make a mistake it can be significantly detrimental. Especially with the tools and the products that you’re building and the reach that they have, I would consider that important. Do you have any examples of where your teams have made a mistake on a persona and what happened, what was a result of that?

Jeremy: [00:15:57] Absolutely. I wish I didn’t have any, but we absolutely have some examples where that’s occurred. One great one for us would be inside of some of our reporting capabilities, reporting something that spans all of our product lines, and people want to be able to get things in and out of your system quickly. And one of the things we had, at the time we did our first real redesign of our reporting capabilities, was we made a bad judgment or assumption in that we felt that the more capabilities and the more sheer volume of reports that we provided to users, that that was going to add more value to them. Just thinking that know if we got 100 reports, 150 reports is even better. If we got a 1000 data elements, 2000 data elements is even better. And, you know one of the things we learned after rolling some of those capabilities out it was actually more important than the two or three things that were really critical day in day out, week in week out, for our users, especially those who are our clients, like a CPA, was way more important than the volume. In fact, the real thing that they were trying to was to get to answers and not really get to a report. So that actually ended up allowing us to make really valuable changes to our product. To give answers to the user right as soon as they go in, we know is one of the top things everybody is looking for, and giving the ability to get to those other capabilities, but not at the service level, because that wasn’t what they were doing on a regular basis. So again, for us that was a failure, and you know, fail quick and learn, right. Well that was one where for us, where we kind of made an assumption that volume was important, and it was really more speed to a handful of answers.

Sean: [00:17:43] That’s a great answer, man. Gives us something to think about for sure. Do guys you have a standard that you use for personas? Or is it just team by team, design team by design team?

Jeremy: [00:17:57] The standard for us really comes in the fact that we have a handful of people responsible for it.

Sean: [00:18:02] Yeah.

Jeremy: [00:18:04] So they have the standard in how they accomplish that.

Sean: [00:18:07] That makes sense. And are there any tools that you use to kind of keep them aligned or to visualize them, other than the standard things that you see?

Jeremy: [00:18:17] Yeah, for us there really is no secret sauce or secret tool when it comes to that, we really just have a very basic set of personas. There’s plenty of tools that we from the overall design process, but for personas themselves, they’re very basic documents.

Joe: [00:18:33] Cool. So you know, the podcast, our listeners we’ve got people who are pretty experienced, pretty seasoned, and then also people who are maybe coming out of school and whatnot. So what would you recommend to someone who is just getting started with creating and using personas? And then, the second part of the question, if it’s separate or related, either way is fine. Any kinds of pitfalls or misuses of personas that you have seen that you’d like to point out for people to avoid?

Jeremy: [00:19:03] Sure, so a couple things on that. I would say number one, in the question of people just starting out, I actually happened to be talking to the overall user experience team today in an event that they were doing, and someone made a comment and asked a question about the interaction with somebody who was newer to the team. They brought up the idea that there’s an emotional connection in the world of dealing with user design and that, you know, that piece or that interaction in that engagement with the users is so important to people in that field. And I think that’s something that’s really important for somebody starting out. Realizing that, you know, that part or understanding what kind of makes the end user tick, that those things that like I mentioned that might be frustrations, versus things that might be motivations inside the system is critical. As far as pitfalls are concerned, I think it’s important to know that, one, it’s gotta be a reasonable number or you’ll get lost in the activity. So for us, you know, if we put out a whole grid of all the different components that could go into this with different user types, you’d be stuck in analysis paralysis there trying to figure out how to design a system that might work. So to me, getting down to that smaller number is really important.

Sean: [00:20:26] Of course, that makes sense. The industry has got some magic numbers that I’ve read about, about well, “you should have this many personas for your product, but not too many” you know, you got to find that balance. Do you guys have a balance, or is it something you just kind of figure out by product?

Jeremy: [00:20:41] You know what, in most things that I have responsiblity for, I try really hard to keep the teams flexible as much as possible to say, you know, let’s not set a standard that people get caught up in the black and white of something, and kind of have the ability to kind of adapt to what they’re doing. But as a general rule of thumb, I usually tell people that regardless of what they’ve read and what numbers are out there, single digits is really important to us.

Sean: [00:22:12] That makes sense.

Joe: [00:22:12] Yeah, agreed. So you’ve obviously seen a lot of software products either succeed or fail, what do you think is the single biggest reason that products fail, and any advice on what could be done to avoid that?

Jeremy: [00:22:12] Yeah, so for me, I would say probably the biggest reason something fails for us in what I’ve seen in my experience is what somebody thinks that they know better than what the users tell them.

Joe: [00:22:12] Ah, good one.

Jeremy: [00:22:12] And so you need to get out of your own way and realize what the end users really want. And I can tell you that I’ve even seen it in my own experience. For example, thinking that something would be really important on the dashboard for somebody and over and over people were telling us, “I don’t want to see that there” I felt like that was probably just a small number of people saying that, so we reduced its size, reduced its size, and eventually really just had to give them the ability to block it and ask it. So there’s really just so many of those, and if you can’t get out of your own way, then you’re going to fail.

Joe: [00:22:26] Great answer. Loved it.

Sean: [00:22:28] All right, so Jeremy, one of the things we put into our personas in a pretty standard way is we use the DISC profiling method. Are you familiar with DISC?

Jeremy: [00:22:39] I’m not.

Sean: [00:22:39] It’s a four quadrant model, it’s very simple to understand. There’s on one scale, it’s introverts versus extroverts, and on the other scale it’s data-oriented versus people-oriented. And if you’re more data-oriented and you’re extroverted you tend to be what’s called a D or a driver, and if you’re more extroverted but people-oriented that would be an influencer or an I, on the bottom half it’s introverted but people-oriented that’s a supporter or an S. And on the left side it’s compliant, a C, and those are people that are generally more introverted, but more data-oriented. And we use that because it’s a very simple sort of structure for figuring out what mindset is this person, and by the way we all will fall into all four of those quadrants in different places in our lives when we’re making certain decisions, right. If we’re making a big financial decision, we’re going to behave very differently than if we’re looking at our paycheck and the information that’s in the app for our paycheck, for example. So we try to help our people get into the mindset, the same mindset that the consumer has when they’re using the software products that we’re building. So we’ve been using that tool. What do you think about that approach?

Jeremy: [00:23:58] You know, I think that fits very well into some of the other topics we’ve had, or discussion we’ve had today, around the fact that you need to understand the different ways that people are comfortable and the skills they have, what they’re bringing to the table at the time you’re using the system.

Sean: [00:24:11] Yeah, we build a lot of things bespoke from scratch so we have to guess. We don’t really know what the users, what mindset they’re going to be in, so we this is how we start. So we use that model just to think through, where do we think the customer or the user of the software product is going to be? And then we can obviously test that later. Like once we get a group of consumers using the product, we can ask them a couple of questions to figure out where they are when they’re thinking about that.

Jeremy: [00:24:37] You know, it is great to have a framework like that, and I think we talked earlier about the new system versus trying to make a transformation or an update to an existing system with an existing base and some of the benefits you get with a new system. That you can start from scratch, as you mentioned, brings kind of that challenge of not having a base of the users to understand through analytics of what they’re already doing and what’s important to them.

Sean: [00:25:04] Right. But you got to start somewhere, right. That’s our theory. And then you can groom it. We groom our personas just like we groom our user stories and other things for our products. So the other thing, the other tool that we kind of have that we think is somewhat unique is, we use these competence scales. So we believe that we have to really know how competent the consumer is on two different dimensions. One being with technology, which often comes from the age demographic and the profession demographic as well, you can pretty much determine, “how competent is this person with the technology that they’re using?” The other competence scale is in their domain, like “how domain competent are they?” So if solving a problem in payroll, like how competent are they about what’s being taken out of their paycheck, for example, right. And we’ll build the software products very differently depending on where they are on those scales. Like if they’re low competence, we have to educate them more, or use more onboarding tools in the user interfaces, right. So those are other tools that we’ve been using. Do you have any thoughts on that?

Jeremy: [00:26:12] I think those are critically important in understanding the users and like I said, what their skills and capabilities are. I think the one other piece I would add to it if I was in your guys’ space, is you know, understanding what the engagement means to that user in a sense of, like you know, in a marketing system you’re trying to keep the person engaged and drive them to a sale. Whereas for another system, like you just mentioned for us, like getting and seeing your check stub, out you might want to be getting in and out of that is quick as you possibly can. So understanding what they bring to the table in skill set in understanding and knowledge, and then also what’s really driving them.

Joe: [00:26:51] Yeah. We’ve been using a lot more design thinking lately and so in the personas we do a really just basic and simple scenario. It’s just five steps, you know, kinda just whiteboard it out real quick. Like you were talking about earlier, what is their pain point potentially, or what is their goal, what are they trying to get done, and where does the technology involved in that become involved in their life, in solving that problem? Are they on the go, are they not, are they at home? What kind of time do they have? All that fits into that, so that’s totally onboard with that.

Joe: [00:27:23] So Jeremy, when we were trying to schedule this podcast, you were on vacation. Do you mind sharing where you were to make everyone jealous?

Jeremy: [00:27:30] So I was in Aruba for about nine, ten days. And it was gorgeous. An awesome, awesome place with a lot of great people, and the weather is just so consistent day in, day out, all year long that, you know, for me, if it wasn’t for the necessity of sunblock sunblock sunblock, I might never want to leave.

Joe: [00:27:57] And so it was very hard to set up an offshore bank account?

Jeremy: [00:28:03] Hahahaha, really wild there, nice joke. But you know what’s really wild is that I looked everything up there of what it would take to live there, and something crazy like 59% tax rate or something like that.

Joe: [00:28:17] Oh God. Hahahaha.

Jeremy: [00:28:17] And only your first, if you’re still US-based, only your first like 108 thousand dollars is only taxed in Aruba. After that, you still get federal tax on top of the 59%. Not any place for ex-pats to go and live.

Joe: [00:28:17] Yikes.

Sean: [00:28:17] Ouch. I think Bonaire right next door is a little more friendly. Somebody told me that.

Jeremy: [00:28:17] Yeah. But we’re a tax company so don’t quote me on that.

Sean: [00:28:17] Well thanks, Jeremy, thanks for joining us today and sharing all your great knowledge about personas and how you guys have used them, obviously for many years. I really appreciate your joining us and hopefully we can do this again sometime in the future.

Jeremy: [00:29:02] My pleasure. Thanks for having me.