 So I'm going to get started in a minute because it's 9.48, 9.49 according to my watch. I don't want to start too early and disappoint the people who come in late. Okay, so I might as well get started. Hello everybody. My name is Dave Neary. I work for Red Hat in the open source and standards team. What we do is we make all of the open source projects or try and make all of the open source projects that Red Hat is invested in, well least successful, whatever that means for that project in specific. So one of the tools that we use is Personas and I'm going to guide you a little bit through today what are Personas, how you can use them, how they're useful in terms of thinking about your product discussions and your marketing discussions around a project. And specifically thinking about OpenStack and how we can use maybe Personas to help facilitate discussions in the OpenStack project. Okay, so I should start with a problem statement. What are Personas? Why do we have them? What problem are they solving? So one of the things that you'll hear a lot in open source projects in general and even outside of open source is you'll hear people talk in generalities, just like I am now, about what their users want. One of the discussions I've had recently with a colleague is we were doing a website and he said, what do you mean you've got an open source project and you don't have a download the source link on the front page, you don't have a link to the license. And I said, well, you know, thinking about our target audience, we're thinking about people who want to install this first and then maybe later they'll start getting involved and we don't want to scare off people who aren't familiar with, you know, downloading source code and compiling projects. We don't want to scare them off by having that be one of the primary artifacts that they see. And so we ended up in this discussion, you know, open source projects, we must have a download source code link and I said, well, you know, that doesn't fit into what the primary target audience of the website is. So when you get into these kinds of conversations, what typically what you'll find the symptom is the conversation. The actual core problem is that you don't have a key understanding of a common frame of reference in that conversation for what your user is, who you're talking about. So, you know, when you're talking about no one uses Feature X, I've seen in the GNOME project, which is another project I've been a long time contributor to, the number of times where every now and again somebody would say, well, why are we even supporting 1024 by 768, nobody uses that anymore, except we have some statistics for the screen sizes that people use in GNOME and about 20% of our user audience is 1024 by 768. So it's a question of not being distanced from your audience and thinking that everybody you know who uses the software is representative of the general target audience for the software. So personas can help there. So, basically in the OpenStack project, this is an extract from the OpenStack user committee charter. An OpenStack user may have different roles, can be a consumer, an operator, an ecosystem partner, a distributor, provider, appliance vendor of OpenStack. An OpenStack user may be from different types of organizational affiliation, company, government, non-profit, can come from different market segments, so they talk about healthcare, military, state and government, or they're a list of about five or six different market segments. And then finally, geographic regions, Asia Pacific, India, Europe, South America and North America. And the thing is that this is really broad. I have absolutely no understanding of what an IT manager of a military organization in Indonesia has as his constraints when he's deciding what cloud software to use. If that's part of our target audience and clearly it is, then we need to understand that person what his problems are, what his needs are and how we can solve them. And so that's where personas come in. And it's kind of a bad word in open source projects, marketing. This is where the personas have come from, they've been used in the marketing world and the communication world for decades. So I want to talk a little bit because this is a bad word. What is marketing? Why is it appropriate here? We think of it as kind of putting lipstick on a pig, right? You take whatever the developers give you and the marketing is, okay, how can we sell this now? How can we push this down people's throats? And that's the idea we have of marketing in the technical world in general. And that's not what I think of as marketing. So I'm going to guide you through what I think of as marketing and hopefully by the end of this you'll all realize that you're all in the marketing department, including the people who aren't in this room actually who may need that. So the very first thing in marketing is you need to know your target audience. You need to understand who am I aiming for with this product or project. What am I trying to achieve? What is the problem that I'm trying to solve? So once you know your target audience, you can identify the problems that they have. And then from there try and fix them. So you've got an idea of who your target audience is, which market segment you're going for. And then you've got an idea of a problem that they have. This is from FOSSTEM this year. The projector was we had to get a replacement projector and the projector was pointing too low. The problem was that the projector was pointing too low. The solution was to put a bottle underneath it. It's a hack, but it solved the problem. So if you can fix a problem that people have, then you're in good shape. And then once you know that somebody has a problem and you fix the problem, that's not enough. You then need to let them know that you have a solution to their problem. You need to get the word out. And that's where the communication and marketing that we typically think of, you know, Marcoms comes into play. Now that we have something that we feel like people will want to hear about, how do we actually reach them and get to them with that message? And in the old world of broadcast communications, and I say old, it's only been for the last 60 years since we've had television and radio, and it's in the process of dying. So maybe broadcast communication was a blip in the history of marketing. I don't know. We're not going to go into that today. In the old world of broadcast, the way you got your message out was, you know, by spending as much as you could in as broad a channel as you could. You kind of plastered everybody with the same message, and you hoped that the subsection of that audience that was interested in your message would hear it and see it. In the open source world, that's not quite what we do. It's important in the open source world, and in general, in fact, to go where your target users are. You need to be sure that, for example, one of the things that you see in open source projects in general is that we go to open source conferences to promote our stuff, right? FASTEM, OSCON, the Linux Foundation events, right? These are the places where you go to hear about open source projects. But if you're doing something like OpenMRS, which is medical record systems, maybe you want to go to medical conferences, places where doctors are, and people who are deciding on the IT infrastructure for hospitals, because that's your target audience. Those are the people who are going to adopt your software. The fact that it's open source is kind of a nice secondary selling point, but the primary selling point is we do electronic medical record systems. So you need to go to where your audience are, and that's a key mistake that a lot of people do in open source projects in general, and again, personas can help with that. It's not enough that you know who your target audience is, that you know what problems they have, that you've solved those problems, and that they've heard about your solutions to those problems. When they use it, they then have to actually like your solution, right? They have to adopt it, and it has to be easy for them to use. If you make it hard for somebody to adopt your software, then it's never going to take off no matter what you do. One CEO that I know has a test that he does. He sets aside an hour a week. He asks people to propose four projects that he will test in that hour. He gives them 15 minutes each. If in 15 minutes he cannot install the software, configure it, and have something useful happen with it, he's not going to look at it, right? That will never get into that company. It's got to be that easy to use. So that's the test that you've got to apply to your own stuff, is can somebody from our target audience take this up and do something useful with it almost immediately? If you're not there, then you're not going to get take up whether you like it or not. And finally, something which is new in the open source world, which is not so relevant perhaps in commercial software world, is that if you want to get people to go from using your software to being contributors and engaged users of your product and kind of going further down the funnel, you've got to be nice. You've got to have a nice culture. It's very important in open source projects to think of the culture that you have in people's first experiences with your community. And so that's marketing in the open source world. It's kind of the four P's of people here who have done business studies. It's the standard price position, product and placement. What is it? Yeah. Very good. And there are several other P's that people occasionally throw in to compliment the four P's. But this is marketing 101. You have to have a good product that people know about, that people like, and that's got the right price. And price in the open source world is typically the amount of time you've got to invest in. Okay? Right. So how does that relate to personas? And this is the only slide where you will see the two. I know that there are two plurals for persona. I acknowledge that the Greek origin of the word would mean that it's pluralized to persona. For the context of this presentation, I will use personas. Okay. This is the book that introduced personas to the world of information technology. The inmates are running the asylum. This was a book which basically the starting premise of the book is we have engineers writing software for people who are not engineers and they don't know how to do it. They're writing software for themselves. They're writing software which reflects the architecture of the software they're writing, and reflecting the conceptual model that people using the software have. So anybody here who's into user experience design will have the Don Norman books, emotional design, the design of everyday things. Very similar idea is there was a break, there was a disconnect in IT in the 1980s and 1990s between what we were producing in the IT industry, the way people perceived how that software should work. So you ended up with horrible software with lots of options and so on. So he introduced the idea of personas in terms of product development, in terms of coming up with user interface design. And as I said, it's been used in many other industries for decades. So what is a persona? So the basic elements of a persona is if you want to get down to the knob of the matter, you want a persona to be real enough that you can identify with the person, but abstract enough that it represents a group or a market segment rather than just one individual. So a persona typically has a name. You'll typically associate a photo like any face at all will do. Age, family, job, situation, anything which is relevant to your target audience. So if you're targeting something which people use in their spare time, maybe you're going to focus more on the outside-of-work life aspect of the persona. If it's something that people use professionally, maybe you just want to acknowledge the fact that they do have a life outside work and that IT is not their primary passion. Unless your target audience is people whose primary passion is IT and then maybe you want to focus on the fact that they spend three hours a night recompiling kernels, it's not the 1990s anymore. We don't do that anymore. So it's distilled characteristics of a market segment. A useful tool that I found in thinking of coming up with personas, you won't have one typically for a project, you'll have several, is to think in terms of the community types. This is the four communities is something that Simon Phipps has used in a couple of blog posts. So you can have, typically, you can have user communities or developer communities in open source projects. And in the user communities, you have individuals who want to use your software. Those are kind of engaged users, people who are kind of joining forums, posting to mailing lists, who want to update documents in a wiki. They want good documentation and they want community engagement, the ability to exchange with other users. You've got deployer communities, people who are taking that software, packaging it up, perhaps including some extras, and shipping that to people directly. So they have different needs. They want a kind of a higher quality communication channel with the core developers because they're representing much more than just one person. You can have the core developer communities. So you've got either the people we typically think of as the open source developers, the people who are working on the core code. They need patch review or source control, mailing lists, the hate forums, hate forums. And all of the other kind of developer tools that we were used to in open source projects. And then you've got the extension developer. They have different needs. It's something like what you see in Firefox extensions, the store. They want a path to market. They want good API documentation. They want good developer tools. So by thinking of the, in terms of the community types, and where do these people fall, the target audience archetypes, where do they fall, will help you also kind of find the solution to the problem. So here's an example of a persona. It says, don't worry about the text on the right. This is just a screenshot. I've summarized the main points on the left, right. Left, right. So this is Frank. He's 32 years old. He's a system administrator in a medium-sized company. He's the guy who the CIO will go to to figure out what technologies to test in the lab so that they can decide what they're going to deploy at the next release cycle, right. So he's kind of interested in technology. He's kind of the free software guy in the company. Everybody knows this person, right. He's kind of the free software guy, but he's typically a user, somebody who keeps track of the latest tech trends. But, you know, basically by hacker news and Reddit and whatever kind of the standard mainstream tech channels are. He's not going to be on developer mailing lists. He's not going to have the time to do that because he's got his job to do. Outside of work, he's a tech enthusiast, but he's kind of a hobbyist programmer, but he doesn't spend his weekends doing this stuff, right. Essentially a job for him. So how do we get to Frank? Does Frank go to conferences? Is Frank here this week? I would say no. Jboss example, this is a developer. So this is one that the Jboss community, previous one, Frank. That was me. That was kind of an amateur thrown together over the course of a few weeks in a few hours. And we'll see how to do that later. Jboss, this is a professionally developed persona. So much more work upfront, much more professional. And you can see there's much more information in there as well. So this is Matches. Matches is a kind of a senior developer building in-house applications in a larger company. He's a bit of a laggard, technology-wise. He has enough on his plate just with the work he has to do. He doesn't want to spend all of his day looking at what's the newest snowflake on the market. He's not going to test the next CMS. He's not going to test the next MVC framework. He just wants to use what he knows will work. Matches is not going to be the person who's going to get Jboss into the company. Right? How do we reach Matches? How do we influence his decisions and make sure that we're getting our stuff into the framework? So this is a persona. This is why it's useful. And we'll see you later. OpenStack Personas. Some of the personas that we might have in the OpenStack project in terms of operators, but maybe the typical use case for an OpenStack user would be somebody who's running a QE lab. We've got the guy who's operating the lab so that we have QE engineers who can spin up their own VMs, test something, test an application and environment and kind of tear it down very quickly. Right? Make that workflow easy. Perhaps we're talking about system administrators serving internal customers. Right? So we've got people who want to be able to reboot their own internal services, kind of a private cloud. Right? Or maybe we're going to be focusing on something like an ISP. Right? Somebody who wants to just make a VM available to customers, build them according to what they use, make it highly available. Those are the kind of the features that they're interested in. In terms of resellers, distributors, maybe we're talking about somebody who's building a public cloud offering, like Rackspace or HP. Maybe we're talking about somebody that's like Red Hat doing an OpenStack distribution. Or maybe we're talking about companies that are selling add-on, value-add products on top of OpenStack. Each of these are different types of people and each have different needs. In terms of end users, these are just ideas for potential personas for the OpenStack project. If you're talking about a dev ops that wants to maintain many services, kind of monitoring over a series of VMs, perhaps somebody who just wants to run a web service and wants to make it highly available. So we need to have load balancing, we need to have redundant services and backups and snapshots and all of that kind of stuff is more important. And so on. Okay, so that's what personas are. That's what they look like. What use are they? We've already seen it quite a lot. I'm not going to labour this point. Essentially they're useful in terms of user interface decisions because by having an idea of the person that you're targeting, you have an idea of their technical level, you have an idea of what kind of prior knowledge they're bringing into the experience. For something like educational software where you have different user audiences that are all going to be using this software. So you're going to have kids of different ages. Preschool kids, you're going to present a different user interface for the high school kids, for example. Teachers will want a way to interact with the system as well. Khan Academy has three separate interfaces. They have one for the students, one for the teachers and one for the parents who want to track how their kids are doing and figure out where there's difficulties. The classic example in the inmates are running the asylum is people using an in-flight entertainment system in airplanes. The needs of the first class passenger who is travelling every week are only three films because he's seen them already twice this month are not the same needs as the mother of three who's travelling with her kids and wants to make sure that they're not going to be watching the violent movies that she doesn't want them to be watching. So you need to have the different interface and that's not going to be the same interface that the flight attendant is going to use to reboot a seat if it's having problems or that the technician is going to use in the airport to upload new movies or that the airport executive and how the movies are going to go and how they get classified and what the deals are with the studios and what not. So do I need different user interfaces and what are those different user interfaces going to present to people depending on the user profile that they have? How can I reach my target audience? So we saw it with Frank. Frank's not going to be here this week. How do we get to Frank? Maybe standard communication, press releases, analyst relations, all of that will reach Frank and we'll get picked up by mainstream news sites and somebody will blog about something cool that we're doing and Frank will pick that up through Reddit. Maybe. Maybe we need something else to reach Frank. Maybe we need a road show. So maybe Frank won't come here but maybe if there's an open stack meetup in his town he'll go there. So how do we go about spreading out this kind of outreach to the tips? Another place where it comes in useful is thinking about feature decisions. Right? Do I need... Between... I'm going to try and think of an open stack example. Between... Okay. Let's forget the open stack example. Between... Between feature A and feature B. Feature A is going to be more useful to one target audience segment. Feature B is going to be more useful to others. Which one do we prioritize? Feature A is going to be more useful to one target audience segment first. And personas can help you frame that kind of decision. And finally, what should our website look like? So it's one thing to think about. Website is a promotional tool. Another use of the website is an informational tool for people who are using your software. So you can think of, okay, what are the kinds of questions that people have when they come to my website? How can I answer those questions quickly? Is it more to find out about the project and contact with the developers? Or is it because they want to meet other users? Or is it because they want to download the software? Or is it because they want to compile from source? So in terms of thinking of your target audience and thinking of the kinds of things that they want to do, that can help you very, very much in coming up with better websites. To summarize all of that, what personas do is they allow you to focus discussion on a specific frame rather than have this broad discussion where you're talking about your users, your developers, and so on. Okay, so how do you come up with one? We've seen, I think, that they can be useful. We've seen what they look like. How do you come up with one in an open source project? What's the process? Because one of the things that's difficulty is that you can invent personas, but you don't know whether they're right or not. So the first step in coming up with personas, typically, is to do interviews. You talk to people who are potential users of your software, current users of the software, users of your competitor's software. And by talking to these people you don't want one of the traps that you can fall into is to talk about your personas as people who are already using your software or people who are to kind of idealize and say this person has the problem that the software solves without actually having a clear idea of what problems people actually have. So to think in terms of idealized terms rather than the concrete. So for overt, for example, I talked on the user's mailing list to maybe a dozen or two dozen users of overt software to find out what type of company do you work for? How are you using this software? What was attractive about this software? Do you use anything else? Any information that you can get which will help you understand the problems that these people are having and how you can eventually solve those problems and solve them better. Once you've got a set of interviews and you can have, in professionally done ones you can have hundreds. I talked to a colleague last week who was telling me, yeah, when I do an interview I do about a hundred. When I do a persona I do about a hundred interviews and then I condense those down. See a cluster and consolidate your profiles into archetypes. You want to reduce those hundred down to a small manageable number. So you say okay I did an interview with this person and this person they're essentially the same use case. I can merge those. I did an interview with somebody who is managing a small cloud for communication company, internal managing infrastructure and managing storage and I did the same thing and it was somebody in a different market segment but essentially the same problem set. I'm going to solve the problems for him and I'm going to solve the problems for her too. So you can merge those. And by that you can get it down to a manageable number. I would say for most projects between four and eight is probably a good number of personas. So once you've clustered things down to about four to eight kind of market profiles you've got four to eight piles of interviews then you're in good shape. Now what you want to do is distill from those piles of interviews the salient details. What represents that pile in each persona. So you're kind of bringing it down to the core details of what you're interested in in the person in the archetype. And so your end result when you've done all that you've got your persona which has the picture, the name and so on. The end result of that is that you have easier discussions. All of your internal discussions become easier because you're no longer talking about your users you're talking about Ellen you're talking about Ahmed. You're talking about specific people that represent groups of your target users. So you can say well okay adding that feature will help Ellen but actually it makes things more difficult for Brian how do we do this in a way that keeps both satisfied. So it makes it easier to have those kinds of discussions internally. It gives you a better idea of the publications that you target because you know what people are reading or you have some idea you know what websites people read. Gives you a better idea of the conference plan to go to so you're focusing your investment on conferences where your target audience are actually going to be there rather than going to conferences and kind of talking in the echo chamber which we can sometimes feel like we're doing especially in open source projects where you go along and you see the same people every two months and you say well are we meeting anybody new at these conferences are we getting value for our money here. It gives you a better idea of yourself and their shoes. It's a very good tool for creating empathy with your users and your target users and the end result of it which is what we all want is more and happier users. We've got at the end of this you're going to see your user base grow because you're going to have a product that's going to address their needs better than it did before. Thank you very much. Are there any questions or comments or feedback OK, so the question was are there any examples of open source projects that have gone through this process in the community. I mentioned Overt earlier I do know of several projects that have done personas in the past but I don't know if they've been kept up. I know that they've been done in the ALS project for example which is the upstream project for CloudForms. I don't want to just talk about Red Hat projects those are the ones I know best. We've done some in the GNOME project in the past around GNOME 2 time most of them have been done at the at the impetus of companies that were participating in these projects. I don't know of any others does anybody know of any other projects that have been doing personas successfully? Any other questions? Yeah other open source software projects I'll repeat what you say that's fine this is Skater you said? Skater was that your reply to Parik or was that your question or your comment? Your comment was that Skater I'm repeating for the cameras Skater uses three types of personas to focus their discussions one is the software developer that doesn't have any operations experience who's more interested in self service and having assumptions made for him so this is the person who's going to operate the cloud and then the IT director who's going to be choosing the cloud software that the company applies and they're more interested in collaborative how is this going to fit into our IT infrastructure and how does this work with other pieces that we're already using is that a fair summary? Ask your question What open stack personas are underrepresented in the user community? Right now we don't have any personas so what we have in the user committee is a broad idea of what our target user audience is and my suggestion is that we actually go about creating some personas over the next few months which help us to focus those discussions so I would say all of them is kind of the glib answer to your question Well I have honestly in terms of the the people on the user committee they represent a kind of a broad basis of people and they're again repeating for the camera So in terms of the people on the user committee which people are missing that would be in the target audience was that your question? So certainly I think in terms of some of the user segments the education user segment seems to be pretty well educated research labs seems to be pretty well represented Certainly private enterprise you know bigger companies doing doing public cloud and large private cloud they seem to be well represented I would think in terms of Asia back Japan, Singapore China under represented but I haven't been following perhaps as closely as I should have but certainly and kind of people who want to use this I don't know if that's even a target audience but if we're imagining people would be using this for their personal virtualization needs or small to medium size business so you're talking about somebody who's got maybe 10 servers using this for a small private cloud I don't know if we have any of those represented on the user committee right now Okay So the practical tools what are the practical tools that people can use for this I love paper, I really paper and pens great, you can draw stuff Wikis are good anything that allows you to throw stuff up quickly Wikis are good but I start with paper and pen email for interviews this is low tech stuff typically what's missing in persona development is not the tools to do it, it's kind of the time and the the volonté to use the French word the will to carry it through so this is a presentation of personas as a general idea not a proposal to do this in the context of the user committee but I would like to kick that off and it would be the natural place in English Thank you Okay, shall we call it a day? Thank you very much, I hope it was useful to you and you have four minutes to get to your next presentation