 Thanks everybody. All right, so yeah, I'm a technical product manager at a software company in Long Beach, California I used to work for a WordPress agency. So now WordPress is my hobby again as it started out so I Was you know when I was at in doing agency work was a little bit more like Project management and now I have since moved more into product management and the main difference there, which is mean it's a little What's what I'm looking for? I mean it's a little nitpicky, but a project manager deals more with What like what's getting done when and who's building it? But a product manager deals more with why you're building it and who you're building it for So that's where I'm coming from a little bit with this talk Specifically looking at user stories. So what are they? They're a way that you can Describe what you're building in context so that instead of having just a list of tasks You're describing what needs to get done in a way that keeps everybody on the same page And if you're using an agile process, it's a really key building block to the whole thing Does this look familiar to anyone? This is just a little screenshot from probably an actual Trello board or something that I used at some point It's just the list of tasks, you know I need to add a red border around a button and you know adjust some styling on a table so that it becomes more Responsive friendly I mean, you know if you've built a website or anything else before You know the importance of keeping track of all of the little things that need to get done Not only doesn't ensure that you didn't forget something super important at the last minute But it also lets your clients see in real time what's getting done and that's really important just to keep you accountable Keeps everybody happy But as I'm sure you know a project is a lot more than the sum of its task list You can get all the way through each individual item and still end up with something that your client Didn't have in mind and that their users absolutely hate So I mean just a quick show of hands Who's ever given an assignment to a developer or anyone else and it comes back and it might be technically correct But it wasn't quite what you're looking for Yeah, yeah number of people. Yeah, I feel you and I've been that developer too So hopefully This talk is going to show you just maybe a little bit of a different way if we're not using user stories already Just of how they can help you in your process These stories are gonna help you keep the what along with the Context of what you're building so that you're building the right thing For the right person. All right, so these are just some objectives things that I hope you're gonna get out of the talk today That hopefully you're gonna learn a little bit more about product thinking when it comes to understanding What your what your end user is going to need? And hopefully you'll have a better idea if you don't already of how to write clear manageable user stories that are gonna help keep your whole team on track So I also made a couple assumptions when I was putting these slides together I mean you always have to keep your end user in mind, right? So the assumptions that I'm working off of here is that you're already using an agile process If you're not familiar agile is one of many Systems or frameworks out there of how to get things done, especially when it comes to software development and I'm also assuming that you've got more than one person on your team You know, I know that that is certainly not always the case I've certainly worked on a whole bunch of websites just me myself and I but There's a level of complexity that comes in when you start adding additional people to your team You certainly can you know multiply the amount of things that you can get done but you can also at the same time multiply the amount of things that can go horrendously wrong so Keeping keeping those lines of communication Super clear is really helpful. And you know, we don't all just walk out of School or anything we don't all just walk into our desks and we just know how to get this stuff done we might know how to build a website really really well and We're not totally sure what we need to do in order to hand that off to somebody else So I just want to kind of let everybody know that that's okay And that there's always room to improve and that's also part of agile Is that you're always improving and always looking back at what you did and then wondering what you can do better the next time So if this doesn't entirely describe your team we can address in Q&A at the end Just how we can sort of modify the process a little bit. Okay, so what you're gonna need You're gonna need user personas Your team and by that I mean your whole team and a project objective that's going to take several sprints to achieve So this is kind of your grocery list for sitting down to write user stories We'll talk about personas in more detail in just a moment Just in case you're not familiar with agile a sprint is a predefined period of time where the team is working on a very limited set of tasks Usually it's about two weeks. I mean some people do four week five weeks six weeks sprints I mean, it's not really set in stone. It really depends on what you're doing I think two weeks is a nice, you know, it's long enough that you can dig in and get things done But it's not so long that you start to get overwhelmed by complexity So let's touch on teams and objectives first so Your team could include people fulfilling the roles of programmer tester analyst designer Database architect and technical writers And now larger agile teams might have a bunch of people fulfilling each one of these roles There could be entire teams fulfilling each one of these roles But a smaller team, you know, you might have, you know, your Your designer might also be one of your testers, you know, people just fulfilling a bunch of different roles here And you know, especially when you're dealing with WordPress Which is a product that already has a lot of the database architecture taking care of you might not have to deal with that at all But on a more complex WordPress build you might need somebody to get in there and start Tweaking those databases a little bit take care of some of those tables that don't quite get indexed so that you can have all That data available, you know You can get you can get pretty weird with WordPress. So just if you you know Call in call in the air support when you need it. So I Think it's really tempting when you're under to starting when you're undertaking a big project project to You know, just have those conversations with like, you know, the company owner and maybe the project manager But really you need your whole team in it because co-creating something is one of the best ways of establishing an aligned vision for a product People get really busy, you know, especially, you know, if you're very blessed at your office, you might have months and weeks worth of work and You don't want to take your your programmers off of something that they're doing in order to talk about this other project But you really need them to do it If you just keep it to the project or product manager and your stakeholders when you're starting to plan all of this stuff out You're you're not letting your your developers and your designers take part in the co-creation process So then when when it comes time to hand off the keys to them like, okay, go build do it They have less of an idea of What you're really doing and why? So resist the urge to you know, I don't want to borrow I don't want to bother the devs bother the devs It's gonna save you so much time in the future Everyone needs to have a really strong understanding of who the end user is in order to perform their function on the team Really no matter what they're doing a technical writer needs to know, you know the level of technical sophistication that the end user is gonna have because that's going to Impacts the way that they word everything, you know, if they're writing for other developers, they can write up here You know, if they're writing for a mass market website, they're gonna need to write down here So it's really good to have everybody on that same page from go and We use user personas to better understand whose problem this website or other product is going to solve So a user persona represents your products core demographic or demographics and It describes what your user does without consideration of how they use your product So this is one of those exercises that's really good to get outside of yourself and what you do and what you build and empathize deeply with the types of problems that you're trying to solve and I mean, and I just want to emphasize once again, you know, the most important part of this is kind of against logic What your product is should not be any kind of consideration when you're writing these personas I mean think about it this way, you know, you've got a problem. You're talking to a friend and They're not really listening to you. They're just like, well, did you try this? What about what about this? Did you did you ask this person? It's like, are you actually listening to me? Like I I just need you to listen to my problem and understand what my problem is I don't necessarily need you to solve it right now But because all you're trying to do is propose solutions. You're not listening to what I need So this is an exercise where you can really practice that that active listening and understanding Because the otherwise the solution that you're gonna come up with is almost always going to leave out some sort of really important consideration And and really in the end no matter what solution you come up with it is no solution at all if nobody can use it So when I talk about user personas, this is an example of what I mean Julie city clerk 42 years old spends her day fielding document requests from her city's residents She wishes there were two or three of her but cloning isn't real yet So this is just an example of what could be an opening line to a much longer user persona It defines who the user is giving them a name in this case Julie what their work function is city clerk How old they are 42 what they do public interaction and fulfilling requests and Their main obstacle which is not having enough people to really get the job done Now sometimes it seems a little silly to be giving your end user like a name and age and making up all of this stuff But really it's just an interface. It's just a technique to help you Better interact with who who this imaginary person is I mean this could be a composite based of a bunch of different interviews you've done with actual customers or it could just be you know, this is who we're going after But giving them you know sometimes you can even you know You find like a stock photo of who you're looking for and then just put that on there Because it's just it's a way for a human to interact better with a human if you've got some of those touch points that you can That you can relate to I Mean it's rare that you're only gonna have one user persona I have personally worked on projects where I've written five or so now I mean don't go crazy with it if you've got too many user personas your product is probably trying to be too many things to too Many people and you should niche that down but You know don't artificially limit yourself either and This empathizing exercise can really pay off in ways that you never expected One time I uncovered a security concern that we had to address all because I just sat down and I was thinking about okay This person's really concerned with security So what are the things that they're going to be looking for when they're evaluating this product on security? And I just start going through everything and I'm like, oh, oh that we should we should fix that So it can be it can be a really good exercise So once we understand who our user is and what they need We can start writing user stories that the whole team can work on So your user story needs to answer these questions What does the user need to do? Why do they need to do it and what's getting in their way? Using a previous example Julie needs to answer document requests from the general public Let's say it's a legal requirement that these documents are available by request. So there's no getting around it These requests have to be fulfilled Now the limits in time and space are getting in Julie the city clerk's way There are just too many requests for her to handle in a single eight-hour shift if these requests take too long people get impatient Maybe people even start to wonder if there's a conspiracy at foot trying to keep them away from accessing these documents A transparent quick process would help ensure that a secondary problem can get addressed the number of angry follow-up phone calls and office visits So there are very clear stakes in this game that we can define So now that we've put all of that on the table We've got a good problem worth solving Our sample user story tells us the city clerk's problem She's working long hours to try to avoid making people mad because public document requests are too numerous for her to handle Maybe she's missing out on dinner with her partnering kids because of it So there's a big win here if we can solve this problem for her One product feature that could help might be a way to automate simple requests so that she only has to get involved if Somebody needs something relatively complex so One way to interface into a user story and make sure that you're checking all your boxes is as a blank I Want to blank So I can blank This is just the basic framework that you can use to make sure that you're always covering your bases So using our example, this could be as a city clerk I want to handle public document requests more efficiently So I stopped getting angry phone calls and I don't have to work so much over time Now this story is a bit large maybe a little vague But we can talk about that a little later on for right now This is just a basic example of how this technique can work I just want to take a second and call attention to how Nothing that we've talked about up until this point has made any mention of code libraries Content management systems web hosts or anything else having to do with technology The end user really doesn't care what new JavaScript library you're leveraging They don't really care that you're deploying elastic search to supercharge your WordPress install search ability What they care about is that when they search they can find what they need Even if the search query is misspelled So if your user persona exercise indicates that people looking for content on your site might not be using standard spelling Then elastic search or another feature that enables fuzzy search could be one of your engineering solutions But again your end user doesn't really care how you're solving the problem They just care that you're solving the problem So try to avoid the urge to impress a client with technological jargon because they're not gonna understand it And it might just lead to misunderstandings later down the line You know some just with some of the the psychology of working with clients if somebody feels dumb or like I don't know this But I feel like I should know it I'm just not gonna say anything because I don't want to risk looking dumb even if there's no expectation that they would actually know it so You know, it's always a delicate balance to strike. You don't want to talk down to somebody. You don't want to talk over their head So just feeling it out, you know, but one of those one of those ways that you can always make sure that what you're saying is is Directed directly Head at what somebody needs is just by addressing their problems Because that at the end of the day is what they really need Now I mean sometimes you might need to get real technical to justify the size of your invoice And you know That's a whole other thing But you know people are gonna sign on the dotted line for solutions and not necessarily technology What you should always be trying to answer is how does this make someone better at their job? Success isn't the size of the invoice generated, but hey like it's your helps, right? Someone else's success using what you built is a measure of your own success As I've mentioned before your solution that you create is not a solution if no one can use it or if it doesn't solve the problem at hand so When you're making your plans Can you make your end user look like a rock star? If this is a B2B product Can you make the person who's going to be using your software or website? Look like an absolute genius for being able to turn around certain requests in record time Can they scale tall buildings in a single bound? Or can they just get everything done so that they can go home on time and have dinner with their kids? Like these are measurable things that make a difference in everybody's life and the more you can make somebody else feel good The more they're gonna want to come back and use your product and then you've got people coming back all the time So it should never be about you If you're always thinking about how what you're doing is going to help somebody else that's gonna keep you on track and You know, you always need to know how you're doing You know a big part of agile is checking in with yourself and making sure like hey, am I doing am I doing what? I need to be doing here So that means we need to define success And measure it so that we can keep track of that. So when you're picking a goal It needs to be Smart, which is acronym specific measurable achievable relevant and time bound So it needs to be a little bit smart or then make more money Save more time do more with less These are all things that we all want to do But there's no way to really measure any of those things It's kind of like in sports like if you're if you're playing football or something like that You can't just kind of like lob the ball in the general direction of where you think it needs to go There's a very clearly defined goal post or end zone that you need to get into and that's how That that is what everybody agrees is success. So that's what you want to work for you wanted to completely define your goal So that then everybody knows when you got there and then everyone can cheer for you. That's nice, right? All right, so if you want to make more money How about making ten thousand dollars more in gross revenue this month instead? Or maybe reduce the need for overtime hours by 50 percent over a quarter So you can use KPIs to measure this and those are key performance indicators These are just a couple examples of dimensions that can be measured The right kpi for your project is going to vary wildly by what you're doing These are just kind of a jumping off point. So if you have any commerce site, you might want to keep track of shopping cart abandonment rates over a period of time Or maybe the average order value that's coming in over time If you're a marketing Company or you know other kind of of agency. Maybe you want to track how many qualified leads you're getting per month So just note that they're very specific and that there's a defined period of time so that you can Keep tracking it and measure your growth So here's how all the pieces that we've discussed fit into a hierarchy Realizing your smart goal might need several features to satisfy it and user stories like our example of julie the city clerk Can help make up your product backlog So because this is agile we're working in sprints I mean you could spend your entire year trying to make it easier for julie to get home in time for dinner with her kids So you want to split those big stories into smaller sprint sized bits So that you can measure velocity or how many story points can your your team deliver in a period of time So that that way you can measure how you're doing and make sure that you're going to make your deadline because those are real important So you've got your high value business goal your smart goal, which in agile could be called an epic Then you've got your job task user story You know the as a city clerk. I want to not have to work so much over time Which then becomes your product user story Which is a smaller piece of that larger piece And then that turns into Your developer and designer tasks like I showed you in in that first slide after the title So you still have all of your tasks, but it's all getting folded in under contextualized stories So that that way it's never The the granular bits of what you're doing never gets separated from that greater goal So when you're trying to figure out how much you want to put into a quarter or six months or something like that Um, you should think about how to divide it up Um, you know, it's been said that there's no such thing as a finished product project It's just stuff that you decided to ship no matter how much more you still want to do about it And in agile shipping is a feature Uh, you want to make sure that you're shipping often That things are just getting out the door Because when things start to back up Then you know people start to not feel like they need to get certain things done on time And you know just there it's very helpful to project psychology if you can just keep things moving So defining your mvp or minimum viable product It means that when I hit This feat this set of features We ship Um That's when you know that you can go to market whether or not you feel like you can go to market is the whole other thing But that's something that project and product managers struggle with all the time. It's just part of it's part of the job Um, and whatever you decide is your mvp should take several sprints to finish And once you've shipped your mvp your future releases might be a minimum marketable feature An mmf a set of features that represent Enough of what users might want added in order for a release to be valuable to them Um, so these features might not quite be enough to stand on their own But it's a meaningful improvement to your existing product So, you know if you're only taking credit card payments on your website a future minimum marketable feature could be Accepting amazon payments or paypal So this is a process You're not going to get all of the user stories you need for a project in one meeting Um, you should have A story writing workshop Once per quarter for ongoing builds, especially with software Um, or once per phase for a phased project So you might be rolling out a website in eight months over three phases So You know, you'll you'll meet three times for that just to break up the work This ensures that your team can stay agile and not get bogged down by too much documentation You want to make sure that you're delivering the right amount of documentation at the right time Too little means that people are going to get lost and not know what's happening Too much is going to be just information overload and people aren't going to be able to really take it in So it's you know trying to get that Goldilocks amount. All right. How are we doing on time here? um I've identified a couple Other topics that I haven't quite gotten to in the space of this talk I want to make sure that we're leaving some room for q&a too um A couple things that I haven't uh specifically made slides for are splitting stories and story mapping So splitting stories is how you take The larger more general product backlog item and turn it into something sprint size that your team can complete in just one sprint And that is the the spider method, which is another great acronym Which is spike path interface data and rules So a spike is a period of research or discovery that you need to do before you can get work done So, you know, if you this is especially, you know, if you're like, okay I know we need to build an api to talk to WooCommerce. Um How do I do that? So you might spike for For a sprint and just do the research you need so that then The next sprint you can get right into it Um paths mean like pay with credit card pay with paypal pay with amazon pay Those are all paths that you can take. Um, so you can split So you're one thing where I want to be able to accept payments online You can split that into I want to accept credit cards. I want to accept paypal and so on So then it's just Splitting it out so that people can get it done in shorter amounts of time Interface is like web ios android. Um, you can tackle all of those separately Data is for separate stories for chunks of the data So like if you're working with something nationwide like a nationwide data set You might only want to take data from the southeast for for one sprint And then data from the southwest for another Um And then rules If it's more work to limit access to a part of the product For membership, maybe your initial story or iteration can be Making that information available to everybody and then on your next build Come in with the membership layer And story mapping is a technique to visualize all of the actions someone's going to take on your site using um Using post-it notes or you know other cards So you know the user is going to log in and then they're going to add something to their cart And then they're going to check out and then they're going to enter a coupon code And then they're going to pay So then you can you know add Uh different dimensions below that too So if that's interesting to you we can talk about that after this But I think we've got the sort of basics here And 10 minutes remaining so Any questions? All right, so the question is if you're just working by yourself Are there any modifications to this process that you need to make and I totally hear you I mean, you know wordpress is my hobby again. So I'm you know, I'm building some websites by myself sometimes um So it might become less important to necessarily document everything out because you don't you don't really have to communicate anything that you're doing to anyone but yourself Um unless you're you know, you have it unless your client is interested in following along with everything you're doing I mean, sometimes somebody's hiring you because they don't want to think about it. They just want you to get it done But it's useful to keep track of all of those stories Just somewhere whether it's you know, your your asana backlog or or what or asana. Sorry. I do yoga so I get confused um I mean when when you're a one person team, it really just comes down to what's going to work for you So if you feel like you're having trouble remembering What your greater context is when you really get down to the trenches in the lines of code Having those stories to tie everything back to is really useful But you know, it all depends like everything, right? Anybody else? So the question is how how do you do user research and Get all of these stories out of your user base So if you've gotten existing user base Building in some some listening features is really useful. So, you know, for example back at the office We've got a pre-sales division that holds Weekly webinars with the people who are selling our products And sometimes I will just get on and just be a fly on the wall and not say anything and listen And just hope that somebody calls in With a bunch of complaints because then that makes my life a lot easier I don't have to you know, dig in and try to to figure out what the problem is. They're just going to tell me But sometimes you do have to figure it out like You know one example that product managers like to use a lot is Henry Ford He once said that if he had asked the people what they wanted they would have said they wanted faster horses So sometimes people don't know What what they want is a solution or they they think they know But there's actually this whole other thing that they never considered So if that's that's why looking at the problem is really helpful But in terms of actually figuring out what these problems are Support forums are super helpful Because people especially with wordpress plugins people are going to tell you if they had a problem So paying attention to those is really good Also just asking people point blank You know if somebody says like oh, yeah, like I downloaded a theme from there once like oh really like tell me a little bit about that process Like what did you find really useful? I'm just I mean not necessarily putting people on the spot But just trying to get them to to speak openly and honestly About what it is that they're that they're trying to do And sometimes, you know, especially if you're you haven't quite gone to market with the product yet You don't really have existing customers. So that's kind of when you have to start getting a little creative You know, you might want to talk to people Who are in the space that you're targeting So working moms for example, you might just want to go seek out working moms in In the park by your house And just you know, say like so do you do how do you handle grocery lists? Uh, you know, especially if you're if you're trying to you know figure something out in that space like just ask People, you know, it's it's a lot of it's a lot of awkward conversations sometimes. Um, but yeah anybody uh So so the question is about prioritizing You know just trying to evaluate whose needs Are are the most important I mean that's hard, you know and and as a product manager, that's that's kind of what I have to do every day It's like, okay, so whose problems are getting solved today and whose aren't and that can be very difficult um, but you know, there are a bunch of things that you can kind of look at like um If you have access to sales data You know, can you trace back like okay This type of user Is paying, you know is is responsible for twice as much monthly income as this type of user So we're going to make sure that we're really drilling into this part this type of users needs um It might come down to Well, this person's needs are actually a lot easier to fulfill So why don't we just go there for the quick win and we'll come up with a plan for somebody else's instead um You know, it kind of also goes back to just your personal business goals as a service provider And and how you can make sure that you're taking care of some of your own needs So it's also taking a product look at at what you do Does that help And then there was one more question So the question was the difference between a user persona and a marketing persona. How do you view those as different? Okay, so it sounds like you've got the people who are sort of managing the website that you're building for them and then you've got their users Okay, so I don't know that I would necessarily consider them user personas and marketing personas I might just consider those two different types of of user persona You know because you know, you need to keep the customers of your customers in mind because you know Happy and user customers are going to mean that your client is happy, which means that your bottom line is healthy um So it's it's a you know, it's it's a chain. I don't know that I would necessarily View them as two different Yeah, that's um So the question was about why you give somebody a name And so it's like so when you're putting something together You can just just say well, this is for annie and then that says everything that that you need and that's exactly why you do it So even though I I totally feel self-conscious sometimes like Jeff is A truck driver, you know, I'm like this is this is silly. Why am I doing this? It's like, you know, it's exactly for that So that I can say no Jeff Couldn't do this So this this solution needs to be easier to use Anybody else? All right. Well, thank you guys so much. Uh these were These are some of the references that I use I encourage you to check them out too and just get out there too And talk to people about how they build what they build Thanks