 Here we are. So six months ago I gave a presentation on personas. It was very much an introduction to personas, why you might use them, what you might use them for, and how you might come up with one. So one of the things that I committed to tentatively at that time was to come up with some personas for OpenStack or to lead an effort to come up with some personas for OpenStack. Through the user committee and with some help from the documentation team and some input from some colleagues in Red Hat, I've been putting together some personas which I'm going to talk to you a little bit about today and try and get some feedback on them and some commitment to help develop these and get these actually useful and used within the project going forward. So my name is Dave Neary. I work for Red Hat in the open source and standards group. And I'm Neary D on Twitter if you want to praise or criticize my presentation. Live, I do like to see the live tweets after. So a quick recap on what's a persona. I'm not going to go into it for very, very much. Thank you very much. So the first thing is there are two plurals of persona. The correct one is persona, the incorrect one that everybody uses personas. So just to get that out of the way for the rest of the presentation, I'm going to try and be consistent and use personas. Personas and technical background come from, this book is one of the sort of the seminal books that said we should be using personas for designing user interfaces. Alan Cooper's The Inmates Are Running the Asylum, he claimed and he was right that engineers have been writing programs for themselves and not for the people who are eventually going to be using them. So you end up with very complicated user interfaces that expose the internal structure of the object structure or the architecture of the program, rather than the way people have a conceptual model of how the thing should work and how the problem space works. So we argued that coming up with personas and thinking, putting yourself in the place of the users would be a good thing. So what's a persona? Personas have enough detail to make them feel real, but they're not actually real. So you've got a name, a photo, which is typically clip art, or not clip art, stock art, sort of age, job, family situation. What kind of educational background they have, what kind of skills they're bringing to the situation they're in. And then kind of the distinctive characteristics that make them useful to us as an archetype, a person who represents a group of users that's significant enough that we care about them. So personas help focus debate. They help us figure out what we want to achieve, and who. So you get all these kinds of debates around users need this feature, or we have to be at this particular conference. And you don't get into the actual specifics of which users need this feature and why. What's the business case behind it, Randy? Why is talked about this a little bit earlier in the community track this morning? What's the business case? What's the actual symptom that leads people to ask for this feature? And can we solve it maybe in a better way? So understanding your users gives you focus and allows you to have better internal discussions. So coming up with a persona, typically you start with interviews. You talk to users, talk to potential users, people in the target audience. And then based on that kind of large number of interviews, let me say I've kind of skipped this part. Well, we'll get to that. So the users that I'm basing the personas on here, we've got a number of data sources that I'm going to go into. A significant number of them are the people that we see in the RDO community on the user forum. People we see who are here in the user committee, the user committee survey and so on. We'll get to some of the sources that I've used later. But you start with interviews. You get data. Second, you try and cluster that data to figure out what are the kind of the trends that you're seeing? Groups of users that have similar problems. And then you try and figure out whether you have a representative user that you can come up with that has most of those issues and can kind of speak for a group of users. And then you simplify so that a user profile can be really, really broad. It can be really specific. And you want to get down and distill that to something that's useful. And you want to distill the number of archetypes. So you might come up with, say, 20 clusters. And you might say, well, actually, the IT director, let's say the experienced sysadmin but who has no cloud experience and wants to learn more about cloud because he maybe wants to become a cloud operator. Well, maybe he shares a lot of the same characteristics with the guy who's a student who is kind of looking around at what the hot technologies are and decides that cloud is where the career options are. And so he's learning about cloud. They're coming into the situation with different, maybe different technical levels of expertise. But if we solve the problems that the student trying to learn about cloud has, then we solve the problems for the experienced sysadmin who's trying to learn about cloud too. So you try and figure out are there ways that we can merge different personas. And then you've got them and then how do you use them? So the most obvious one is in marketing and promotion. It's getting the word out. It's figuring out what your target audience is and how to reach them and what problems they have that you can potentially solve so speaking in their language. So it's things like what conferences do our audience go to, what publications do they read, what kind of key messages will resonate. The second area where you see people using personas a lot is in documentation, in terms of working out when somebody comes to the website, what kind of use cases they have. Are they looking to ask questions? Are they looking to find an answer to a problem they have? Are they getting there because they're coming into the front page? Are they coming through search? And some of the answers to those questions will depend on what type of user they are and what kind of, what their pain points are. Are they coming to the website to download the software, things like that? So what can I assume about my audience in terms of documentation level? If I have documentation that has an acronym in it, can I reasonably expect the people who are going to land on that page and have a problem that is solved by that page to understand what the acronym is? So it focuses, again, it focuses discussion on we need to have more detail in the docs because people don't understand the docs are too technical. That's not actually a useful comment to make. Docs are too technical. They're actually assuming a level of knowledge which is not shared by a significant portion of our user base. And here's the portion of our user base we're talking about. Well, that's much more useful because it maybe helps you to address the problem in a different way. Rather than modifying the docs you have, maybe you need to write different docs or maybe you need to structure the documentation differently. So you've got the fast track for the newer users who don't know the acronyms. And then you've got an index with the acronyms that helps them. I'm using acronyms. It's a bad example. But what kind of questions they have and how do they search for and find docs? So what are the usage patterns that somebody has when they're coming to your project to find a solution to their problem? Because all documentation is we're helping our users solve problems there. User experience. So in terms of the next use for personas is in being able to say, if you can clearly identify with and empathize with a group of users and better understand their needs, then Randy's just walked in. So Randy said earlier, he said, we don't want to have people go to the doctor and telling somebody I need the cure for leprosy. You go to the doctor and you say, I've got a sore finger. And then the doctor tells you whether you have leprosy or not. You go with a problem and you get it solved. So user experience is all about understanding your users, empathizing with them and trying to solve the problems that they have by giving them a better overall experience interacting with your project. So what are the main tasks that people have? What are the business problems that we need to solve? Do we have different types of users integrating with the same system? And if we do, do we need to maybe expose different interfaces? So one example is the Overt project. We've got a user console which actually has two views into it. One is for a basic user, which is somebody who has virtual machines that have been created for him. And he can start them, stop them, pause them, snapshot them. And we've got an advanced user who's somebody like, say, QA test engineer who wants to have a set of templates. And he can spin up multiple copies of VMs based on the templates. He has a much more rich experience. And then you've got the cloud admin. You've got the cloud operator or the divert admin who he wants to have access to your storage network and data center structure. So you separate different workflows by identifying the different types of problems that people might have rather than trying to solve everybody's problems with the same interface. And in development, right? So we've had a lot of conversations this week about what are the priorities for the project over the next six months? What is core? What is do we need to have AWS compatibility? What are we going to have in the next version of Nova? Things like this. And prioritizing features, prioritizing the things that we need to have and to kind of get in there and make sure that they're fully supported and work well out of the box. First, you need to know how people are going to use the software. And to know how people are going to use the software, you need to have some idea of who they are. So options versus sensible defaults, are there things that we can remove from the options? Because well, actually, if you look at things, this option plus this option plus this option, they don't make sense. And maybe it makes better sense to have kind of, maybe we can have a config file where somebody really, really needs to change that, can change the option there. But let's not expose it in the interface because that complicates things. Let's not have an install process where somebody has to answer 20 questions, 19 of which they don't actually know what the question means. Concentrating areas on the place where you're going to get the biggest impact. And to get all of that, you need to know your target audience. So the OpenStack User Committee definition says an OpenStack user may have different roles, consumer operator, ecosystem partner, distributor, or appliance vendor. A user can be different types of organizations. They can be in different market segments, different geographical regions. So my comment last time around was you could actually replace this quite easily with everyone. And that would kind of aptly summarize it. So it makes sense to focus in terms of thinking of the target audience. So maybe the people in a specific geographical region also belong to a specific market segment or have a certain risk profile so that we can say organizations of this size in this geographical area are more risk-averse for their earlier adopters than organizations of this size in this geographical area. So trying to break things up and focus that target audience debate. So some of the contributing sources, there were some personas that were done by the ALS Conductor Project quite a while ago around their cloud personas, the NTT.com security cloud personas. That was a group that I didn't like their characterization, but it was the kind of very specifically in terms of the adoption curve. They had the five personas, the controller and the innovator. And I can't remember what they were. But that was helpful. IBM Cloud User Roles. So this is an IBM cloud paper that was published in ACM two years ago. And they described various user roles. Am I an operator? Am I a deployer? Am I a user? And I think, did they say cloud user? I believe they did. And the cloud user was the people who were deploying applications on the cloud. The deployer included things like distributors, but also people who were servicing the clouds. And then the operator is where the people were actually doing day-to-day management. And there's obviously some overlap and some interaction between those. But that was useful, too. EMC has a user experience blog, which is very helpful that a colleague, Julian, actually, who's here, I think, I hope, there you are, pointed me to that had some. So this was specifically the three that I saw were the Storage Admin, the Network Admin, and the Cloud Admin. So EMC, obviously, have a bias there. Their audience is the admins. And then two colleagues, Bruce Reeler and Julian from Red Hat, were both very helpful. Bruce works for the content management team. So he came up with a set of personas that the content management team were using to kind of focus their discussions around OpenStack docs. And Drew is part of our user experience team working on Horizon now. Is that correct? I believe so. Awesome. And other projects. And Tusker as well, perhaps? OK, good. OK, so we get to the meet. And the rest of this is going to be presenting the work we've got so far. It's a work in progress. And I need the feedback. So I'll ask for it at the end, but I'll ask for it now. I actually want to have this be a little bit. We've got 10 of these, so we've got about three minutes each. So we'll get through them. But I want feedback on, is this completely unuseful, or is this something that is actually a useful persona to have that kind of correctly reflects what we're seeing? This is a target audience or potential target audience for OpenStack, or potential non-audience. Because you can also use personas to say, this is a type of person which you might superficially think is going to be part of our target audience. And in fact, we don't want to target this person. This is not who we're looking for. OK, so the main one, Anna, the enterprise admin. So system administrator in a big company. This is the gold standard. This is the people we're targeting primarily. Bigger company, several data centers, hundreds of servers, perhaps thousands. Her legacy infrastructure is mostly VMware. She's got a little bit of Hyper-V and KVM on the host, but mostly Windows and Linux guests, probably mostly Windows, running enterprise workloads. Her reason for considering infrastructure as a service is to give people self-service in terms of the outside of the organization. They have a ticketing system where you get requests in, and they want to just be able to let people spin up VMs for things so that they're a little bit more agile, getting going a little bit quicker. The main things that she's going to need is she needs to make sure that she's picking the right solution. So she's going to want to see people who are happy with whatever she chooses. So she's going to want to see people who are already using this in her use cases. She wants monitoring. So she really needs to know exactly what the loads are, whether there are VMs that are misbehaving, so that she can come in and have a look at what's going on, and some way to monitor and manage all of her legacy virtualization and her existing virtualization together. If she takes on IAS, she wants to manage something there as well. And she's going to want some kind of a marketplace. She doesn't want to particularly buy into one specific vendor. She wants a way to move around. So Anna's, I would call late majority, sort of late majority adopter, she's not going to be one of the people who is running like Bayer, or is anybody running Bayer? Anyway, even Essex Folsom Grizzly, she might know that she's seeing this big conference as well. There's a lot of user stories. Maybe she's going to be considering Havana. But she deploys basically what her management chain decides is going to get deployed. So she has a significant input into whether this is going to meet the needs that she has, but she actually is not the one who gets to decide what vendor gets chosen. I would say freedom to change vendors if she's unhappy with the one she chooses. Yeah, yeah, yeah. So she's going to want to, if she goes with one solution and two years later decides this is not working for me, there are issues with this. I need to change vendors. And there's nobody else there. She's screwed. And we don't want that. She doesn't want that. She's risk averse. Everybody happy with Anna? So this is a slide. There is a document. And yeah, that would be a useful addition. Ju? So Ju's comment was that outside the VMware Hyper-V, KVM comment was that not many people would have both of them coexisting. Very rarely. My understanding is that about 40% to 50% of people in some of the service that I've seen have either currently have a dual hypervisor strategy, or up to 75% plan to have a dual hypervisor strategy. It's kind of a hedge, right? So just for the benefit of the cameras, Randy saying in his experience, Hyper-V has gotten in because there are Windows loads that you get licensing benefits, licensing discounts if you're running them on Hyper-V over ESX. And that's how Hyper-V is getting in there as a mixed data center running Windows workloads. And also KVM is getting in there partly through vendors also using that as leverage to get their stuff in there supported on virtualization. OK, yeah. So I would argue that this is actually the core of our current user base, or a significant part of it anyway. So Simon's a small, medium business admin. He's running an organization that's got a development aspect to it. So I think the industry section I put him in was construction, and they're doing IT systems for managing things like elevators and Aircon. And they want to provide people who are going to run the management of a building with a kind of a custom vertical solution. And they need some kind of elastic infrastructure, because they've got a bunch of stuff that's coming up. And they need to be able to develop stuff quickly. IT is not a value add for them. It's a cost center. And they just need to get going quicker. Probably already using AWS and wants private infrastructure service for development. QA self-service wants to keep some stuff in-house. And he needs an easy way to apply security updates. So Simon's big issue is if I'm managing VMs in a cloud, how am I going to make sure that the stuff I'm delivering to my clients has all the updates involved? How do I manage the life cycle of those things? But Simon's a good DevOps guy, so he will typically fix that with Publisher or whatever. And he also needs good monitoring for nodes, quotas, guests. Make sure that he knows that he's provisioned correctly and is managing the life cycle of his data center. So the comment is one of the key questions for Anabee, the ability to upgrade between releases. I can't remember on the document. I'll get the document up later. And you'll see what, each profile has a page. And it's got skills, needs, goals, pain points, things like that. Yes? OK. So Dan, the deployer. So Dan is not going to be involved in the day-to-day management. He works for a services company. He wants to get OpenStack into clients. He's going out and he's selling OpenStack. Well, he's selling cloud. He's not selling OpenStack. OpenStack is just the way he's delivering cloud. He is going to look at a lot of technology and he's going to follow where the money is. So Dan is the kind of guy who's going to want to see that there's a market for his services. And he's going to scale up a business offering. He or his boss is going to scale up a business offering based on where the market is. He's the guy who's going to architecture cloud. He wants an easy way to spec out a design. Get in, get out, deploy it as quickly as possible. He's involved during installation but not a min. And I would say he's an early majority in that he's not going to get involved at a very early stage in any project until he's sure that there's going to be some market demand behind it. Randy, are you Dan? You're not Dan. Erin, so it works in a bigger organization. She works with the development team. She's the person who does the deployment of the operations. You can think of her as the deployment team. So Erin's been using AWS for a long while. She is very familiar with all the continuous integration continuous deployment tools and workflows that are out there in the industry. And her primary use case is she's taking applications that are developed internally and she's getting them onto the cloud. So she's the kind of person who's bringing the elastic infrastructure and that elastic knowledge into an organization. And she's focused on her app. She doesn't really much care what the underlying infrastructure is as long as it supports the pieces that she needs in terms of if she's using a database as a server, if she's got load balancing on there. Once the subset of features that are available for clouds in general are available, I mean she's just using the deployment tools that she has always used. She doesn't really care what the infrastructure is. Diane is developing applications that are going to specifically going to integrate with OpenStack. She's a kind of a value add vendor developer. She's selling some kind of hardware or software services, maybe a vertical stack, something that's going to run a specific cloud deployed service and they want to sell that into their clients. She cares about the upstream experience. She's very much an API consumer, API and command line. She does care about working well with the OpenStack developers, the core developers, and probably here this week. So the comment is that Diane probably cares about SDK, something that's wrapping the APIs in a specific language that she cares about. Yeah, for sure. And her company cares about generating revenues from sales of whatever it is her company sells and OpenStack is just a way to get that. So whether it's a software add on on top of an application that's going to run like a management application is going to run on top of OpenStack or if it's hardware that like OpenStack is integrating well with OpenStack is just a means to sell more hardware. But the money here is in whatever the company is doing is the add on. So the feedback is she's looking to add business value. Well, in the context of this specifically, and I don't want to get down that rattle, but let's throw that out there, in the context of specifically the don't compete with your ecosystem debate that's been going on over the last couple of weeks or we're going to provide open source solutions in the context of the OpenStack community for problems that our users are having. Well, then Diane very much does care about where the business value is coming from. It's coming from hardware then we're never going to compete with hardware. If it's coming from, for example, a management interface, then Diane is going to be worried about whether we're going to have a management interface here down the line. So the comment is Diane's going to worry about the downstream. So I presume what you mean there is that Diane's company is going to worry about the vendor relationship with the company that actually is deploying the OpenStack that she's getting her stuff into. All right, so I'm just clarifying what you mean by downstream because there are two possible. So the customer need and the customer market demand. OpenStack is a lever to get more sales of whatever it is she's selling. So Ursula is the university IT director. It's an Irish name. It didn't seem weird to me. Anyway, the alliteration thing came from the initial ones that Bruce Reeler did and I just followed the, I'm not very good at alliteration. Anyway, so we see a lot of people in the academic area or sort of smaller, not smaller, relatively large sized organizations, but typically budget constrained on the software and management side. So Ursula is managing a lot of servers, a lot of EMS, and she's managing the university IT needs, but also providing IT services to staff and students. So she needs that flexibility. She needs the elasticity. And she loves open source because she gets the kind of control, she gets the community ecosystem because she's not paying for support, so she wants to kind of get that close relationship with the developers and software. And she's got the pressure from staff and students to provide the more flexible self-service type of thing, creating projects because staff member wants to run a course on cloud development. He wants every student to have a tenant, right? Something like that, and he wants to be able to set that up on his own. Again, she cares about monitoring, she cares about security updates, she cares about managing with her existing infrastructure and her existing applications, but she is much less risk-averse than Anna or Ann that we saw earlier. So the question is, is the university first because of a reason or because it's targeting that specific sector? So I would say the three different profiles that I saw are open source organizations, so something like MediaWiki, Wikimedia, CERN, and that kind of whole family of organizations, a lot of universities using OpenStack. Anybody who's got their primary constraint is going to be budget and manpower and not necessarily hardware, they have the hardware needs and they just need the elasticity and they've got that open source bias. That's the essence of what I was trying to get out here, or so it's just representative of that. Would HEP and HPC fit into that? Perhaps. HPC, my understanding is that it's got, because of the, oh yeah, so something like Excel Cloud would probably, yeah, the Inria projects would probably fit into that kind of sector, why not? Brad, the beginner. So Brad is a kind of a synthesis of anybody who's coming to OpenStack because they see a kind of an employment opportunity later on. They want to get their skills in the cloud. Brad has, he's a Linux user, he's a Linux admitted home, and he needs to get an easy install and set up on his home network running two or three servers, and he can brush over the details, he just wants to figure out what's going on with this cloud thing. And if the install processes, he gets to the horizon and he says, OK, what now? So he wants to figure out what's going on and understand DevOps workflows and all of that kind of thing. So he lacks the knowledge to dig in and debug issues with installation and configuration. He needs an easy start quick. He wants to have a sample app that he can run, like a sample heat template that he can run and see a cloud application running and say, oh right, I get it now. Victor, the virtual infrastructure admin. So Victor's longtime vSphere user. You will notice I am not speaking on behalf of, some of the things that people will tell you is that you shouldn't talk about competitors, but OpenStack is coming into a market where you've got two very dominant players, vSphere in the data center and AWS in the public cloud. I think it would be silly of us not to talk about the needs of people who are using those things. So I've kind of ignored that advice for the purposes of this presentation. Victor? Yeah. So Victor knows all there is to know about vSphere. His company is committed to vSphere, their longtime vSphere partner, and they do have changing needs. He's considering infrastructure as a service, but he wants to figure out how it fits into his existing infrastructure story. So am I going to keep using ESX as a hypervisor? Am I going to use the vSphere driver for Nova? Is that my way to migrate? Or am I going to move to a separate, like add some new hypervisor, new capability that I'm going to just set aside for OpenStack? See how that goes now to management layer over the top. What are the things that are going to solve my pain points? His pain points are things like capacity planning and integrating infrastructure, migrating workloads. So this is things that are running in VMs, traditional VMs on vSphere are not going to work without some kind of rethinking on infrastructure as a service. It's not. It's actually included in a bunch of them, but it was the one that kind of bobbled to the top for this guy. But Victor is kind of, I would say, early majority. He's committed to vSphere, but he's already got the virtualization. He's drunk the virtualization Kool-Aid, and he's ready to take that step. He is going to get an infrastructure as a service component. The question is just how is he going to do it? So I would say he's probably going to be a promising market for potentially next career move. Maybe looking around and saying, OK, vSphere is kind of VMware share price is flagging, and I need to diversify it. I don't know. I told you I wasn't the communications department. Anyway, Dennis, so director of IT, he is the guy who gets engaged by all the vendors. He talks to his IT staff to figure out what we're going to do. He's the guy who decides whether we're buying and who we're going to buy from. But Dennis is really nervous about new technology. He's a late adopter. He's going to need to be brought to that purchase decision by people who are really enthusiastic and expressing that need really clearly internally. So maybe the way to get to Dennis is to give his IT staff the tools that they need to explain in terms that Dennis understands the value of elastic computing internally in his data center. One of the things that Dennis maybe doesn't know about is that there are a bunch of people internally using AWS already and sort of consolidate a billing that he just sees the invoices coming in. He doesn't know what the hell is going on up there. He's excited about technology. I'm just repeating for the he's looking to open stack. Well, he's looking to respond to IT needs. That's the thing is he's not looking at open stack. That's one of the things that I didn't mention earlier is it's very important when you're coming up with personas to avoid that kind of to not fall into the trap of assuming that the people you're talking about know about your stuff and are excited about it. They are going to have a need. And open stack may respond to that need. And it may be cloud stack. And it may be eucalyptus. And it may be open nebula. And it may be Amazon web service. Or it may be a kind of a specific product offering. And they don't even see it as open stack. They see it as a rack space hosted cloud. Or red hat open stack platform. So Dennis may be a non-goal for some people and a goal for other people. So for example, Lauren may care a lot about Dennis. Lauren doing the marketing for the open stack foundation, maybe evangelizing and getting open stack, get mind share, and getting into analyst press, and getting into kind of, I don't know, Wall Street Journal and that level of very high level, the kind of publications that kind of do a very high level treatment of technology trends. That may be the kinds of things that Dennis is going to be targeting. And like Brad doesn't care about that stuff. Brad's kind of gets excited about the stuff he sees in tech conferences, right? So, yes, yeah, there was another hand. Was it, oh, awesome. Am I, whoa, I'm two minutes out. Alan, AWS enthusiast, so it's unfortunately, we're running out of time. Alan's been working on AWS for years. He's committed to AWS. He's got a bunch of stuff running on there. And then the question for us is, is Alan a goal? He's already got the elastic. He's sold on that. He doesn't need to be sold on infrastructure as a service. But he's committed to Amazon. So unless we're providing it sort of a private option that adds to the value that he's getting from Amazon or a public option that allows him to move easily from one to the other, we're missing out on Alan. Is Alan a target audience who we care about? That's, I guess that's one of the topics of discussion that we've had a lot in the community recently. Walter, the web developer, I added this guy because this is specifically probably a target user for pass. He's working in an organization where he just, he just cares about the code, right? He just cares about his PHP or his Python or his Ruby or whatever it is. The CSS, the HTML, JavaScript is like developing web applications, providing an application running on a middleware, perhaps. And he just hands that off to the operations team, right? Walter just needs some information on how to develop his applications in a way that doesn't make it harder for the operations team to scale out, right? Maybe that's gonna come through the operations team. Maybe that's gonna come through the DevOps profile that we saw earlier. Or maybe that's something that we can reach. Or maybe we need to figure out how do we convince Walter of the value of using a pass, right? So, again. So, help. There are a bunch of things in here that, yep, I'm just done, this is the last slide. There are a bunch of things in here, not last slide. I lied. That we don't have, right? Something like there's a bunch of people here this week, OpenStack core developers, we haven't even talked about their needs and their pain points. Press, analysts, pundits, right? So that how do we improve the, what are the things that those people are looking for and how do we address that audience? Distributors, product managers, what are the kinds of things that, like, these are people who are in some sense our gateway to customers, right? Gateway to users. They're the people through whom we will be getting feedback, what are their pain points and how do we leverage that audience? They need polish. They need to be compared to reality. So the user committee survey has been very useful. Those of you who are in customer-facing roles or in market-facing roles, I would love to get your help polishing these and improving them over time. So the integrating of the user committee survey results I already talked about. I wanna get some feedback and interviews. So I wanna compare with, I've got the RDO experience. Ask OpenStack. I'd like to get sort of some help from the OpenStack Foundation. You guys have awesome contacts with key users and we can improve these if we can get them. And perhaps some condensation, right? Maybe 11 is too many. Personas are useful when they're used. So anybody here who has a use for personas, I would love to hear how useful they are, whether you're using them. And I would love to get your help in promoting inside the open source community that the people who could get value from these are aware of them, right? So please help. The documentation, I'm gonna put a link, I'm gonna put the slides up and the link to the Google Docs which has the personas as they are today up on the presentation, the website. And yeah, go along, read and help out. Thank you, and I have minus four. Minus. Thank you.