 Hello, good afternoon. Good morning and good evening wherever you are. Welcome to my talk today. I'm going to start this conversation with this slide. I reckon a lot of audience today are product managers or have some interest in product managers. If you think back, if you sit back and think how many times have you worked on a product that actually required you working with multiple teams? Most of the times product does require working with other teams, but I'm sure there are times where you have worked with multiple product teams spread across R&D. You've worked with, you might have worked with pricing, legal, but the number of teams you touch on a product can significantly increase. The question that I want you to answer or think about is how many different types of documents can you think of as a product manager that you might have written or might need to write if you have to align everyone across all these teams and create a shared understanding with all these cross-functional teams to take your product to market. Think about it. Think about all the documents you might have written in the past or anything that comes to mind. I'll just flash the previous screen again and let's give it 10 seconds for you to think through it. Here's the question. How many different types of artifacts you as a product manager would need to write to align everyone and create shared understanding with everyone in these cross-functional teams? Guess what? The answer is just one. At least to share, to create a comprehensive shared understanding, you really require just one document. Users to remaps is the most intuitive and powerful tool that product managers can use to create shared understanding cross-functionally. And that is what we are here today to talk about. We will talk about how we use or what you could use users to remaps as a communication tool. Before we dive deep in, let's quickly look at the structure today. I'd love to introduce myself, so we'll get there in a second. I will also introduce you to Alice, who is a product manager at Amazing Inc. We'll talk about users to remaps. We'll definitely look at the concepts. We'll look at some examples, but I have a takeaway template if that becomes interesting to anyone. Okay, so let's go in. My name is Abhijit Mehta. I am director of product management at Algolia. I work on the Algolia source team quickly as my background. I'm an engineer by education and currently product manager by trade. I've been programmer, software architect, solutions architect and product manager in my past lives. Just before Algolia, I was head of product management at Impala, which is a travel tech startup in the UK. And as I mentioned, I'm working and leading on an Algolia source team currently as director of product management. Okay, so that's about me. Let's just move past that now. And meet our hero for today, really. So Alice, I'll just give you an introduction, but I should make a few quick disclaimers. Whoever is watching this presentation today, if you see a picture, if you see references for names, these are all picked up by me from the internet for today's demonstration so that I can deliver my story and deliver a message over to you. If there is anyone has any objections, please let me know and we can take it off. So yeah, that's the disclaimer. All right, let's move forward. So there is this company here in the UK. It's called Amazing Inc. This is all made up by the way, but for now let's just imagine there is actually real companies, but I'm hiding them behind this made up name. Yeah, it's founded in 2014, has been seeing rapid growth, especially last four years, and now the number of employee accounts is about 4,000 spread across multiple continents. We've got a lovely view from the rooftop of the gherkin. Alice Jane Doe, who we just talked about is a product manager. With such a lovely view, she went to office quite frequently, she still goes. She joined the company as an employee number 76. So over the time in the office, she built great relationships with engineering and design. She actually exemplified the product design and engineering relationship in her day-to-day job. She had led three products and shipped tons of features and capabilities for customers. And now she is working on a new product in 2023. This is supposed to define the next decade for Amazing Inc. She has been very successful in creating aligned teams. She'd been office, she spent time with engineering, design, whoever it needed to be. She'll spend auditions, sessions, discussions. She's just been an amazing product manager. You could probably think of yourself in her seat, isn't it? This is something we do as PMs day in and day out. But things have changed, things have changed quite significantly. Specifically for her in her context, if you think about the company group and her calendar started filling up. Is this something you could relate to? If you do relate to something like this where your calendar started filling up your day you actually did not have time to sit down and have focused time to work through it. You're meeting people, you're spending time reviewing roadmaps, one-to-one designs, design reviews, product reviews and whatnot. Does it make sense? Have you experienced this? Please do draw the note in the chat and I'd love to think about it. And even talk to you about it. Some interesting things here. If you look at these specific examples, within the span of less than two days Alice had spent time talking about the same thing in four different meetings. That's four hours of her time. Guess what? Because the user types have increased over time and she's now addressing complex user needs. It's not just one user, one state-filed use case. She's been working on complex user needs. The teams have now become remote and distributed, post-pandemic specifically. And she is impacting large number of teams. The work she's directing impacts many roadmaps. So there's a lot of cross-functional dependencies. And this is why the model of getting in a room and being able to convey and create share understanding is not working anymore. She's left with this problem. It's a good problem. Still a problem. It's good because it is delivering higher impact for the company. It's good for her career, but still a problem. She's onto something big, but she's a bit overwhelmed right now. She has sold it and this is what we are going to look at. We talked about today's conversation specifically about user story maps. It is a multi-purpose tool. This is what Alice is going to deploy now. This is what she deployed to handle all this. And we'll learn that technique in the next 10, 15 minutes. So this tool is useful because it brings customer centricity right on the forefront. Through these tools, user needs are handled very clearly in a crisp manner. One can also look at different customer segmentations. It is actually a living description of product. This is how product looks like to customer. This is how it behaves. It's that living documentation. But it is also usable as a planning item. You can actually extract user stories out of this. That can go into your Gira backlog. This also allows for a cross-functional cohesion. How do different teams work in what order so that you together advance product ahead? And it creates empowered teams. I'll talk about this all, but this is a multi-purpose tool. And I can spend a lot of time explaining why is communication important. What is the benefit of this? But today's focus is going into the detail, like diving in and understanding how to use this tool. But again, if you do think that discussing the benefits of it, why is it actually absolutely required, like various nuances of users story map and the benefits. Let me know in the comments and maybe we can arrange another session for that. But for now, let's dive in. Let's look at the anatomy of user story map. I'd love to explain this to you in step by step. The first thing you need to know is it is meant to tell a story. And as the name suggests, it's the story of the user. So I'll take an example. Let's talk about Dennis. I'm guessing a lot of you probably have heard the name. And I definitely grew up reading about Dennis, even watching shows about Dennis. So yeah, he was a character that was well known, might I am at least. So Dennis the Menace goes to school. And we are going to now talk about and look at the anatomy of a user story map to do the job of getting Dennis the Menace to the school. I'll just call him Dennis going forward. Okay, as I was saying, the very important thing to know is it's a narrative flow. If you look at a user story map from left to right, it basically tells you the overall experience that a user described in this story map is going to have. And if there are other different types of users come together to achieve a specific goal. When you actually create or just think about how to go about the user story map, describe it as if you would be describing to a friend. Don't skip the details. Bring in different actors and personas and start with what you have in mind. Don't focus too much on adding details right away. You can come back and start adding details as well. So yeah, think about this as if you are telling a story to a friend about something, about how a thing, a very specific thing can be accomplished. And that specific thing can expand the spectrum of that can be something as simple as sending Dennis to school to creating Apple Pay or an email client or your product, whatever that product you are working on. So it is a narrative flow and I spent a lot of time here because this is absolutely important. You need to understand the goal is get to that story. You all the users coming into that story should work together to get a thing done. Okay, next step. So as I said, you need to figure out who are the users who are the actors who are the personas that will show up as you try to do that thing that you're trying to do. You try to achieve the goal that the product is being built for. So in this case, forget the product for now. Let's look at users to remember. Remember, we want to send Dennis and I just realized there's a missing end there. Sorry about that. So the goal here is to send Dennis to the school. The three actors that would come into play here are dad, mom and Dennis. So once you've figured out who the personas are, let's try adding the narrative. So in your head, you can think about if Dennis has to go to the school. We can start from what happens in the morning. So let's just assume the dad is responsible to get Dennis in the uniform while mom gets the bag already. And then it's obviously hard to do a bunch of stuff himself. So the first thing that you add after identifying user are the high level activities. These are the things that needs to be achieved. These are the biggest, highest level goals that needs to be achieved for the overall goal to be successful. So in this case, the examples are that dad needs to get Dennis in school uniform. Now he'll need to do a bunch of things, but like that's the goal dad is trying to achieve. Mom gets the school bag already. And again, she might have to do a bunch of other things as well, but that's what she's trying to do. While dad is getting him in uniform, she's getting the school bag already. Dennis himself had to get up because he's Dennis. He'll cause some trouble like, I guess, every other child could not necessarily directly wake up, but eventually, you know, Dennis will get ready and then go to school. These are the activities that Dennis will perform or all the actors will need to perform for Dennis to go to the school. Now we go level 2D. Now we'll start adding some activity. Some examples here are for Dennis to get ready. He has to wake up or he has to get dressed, but he also needs to get his bag ready. So, you know, mom's getting bag ready. She's bringing it to him, but Dennis is the person who needs to put it all together. So that's another sub activity he needs to perform for himself to be get ready. And then he needs to eat breakfast before he could go to the school. So you probably get an idea. Now, sub activity as a side note might not necessarily be a thing you always add. And if you actually read a lot of literature around users to remap, you might not necessarily see sub activity. But in my experience, I have found this useful. So I definitely always recommend keeping this as a placeholder and see where it is needed. Sometimes breaking it down actually gives a lot of granularity and details that help communicate with cross-functional team. And, you know, in examples, a few minutes down the line, it will become clear. So let's stick with that. We've got sub activity sorted. Time to go next level deeper. And I'll just take some examples here, right? Because user story map quickly becomes quite big. So let's take the first persona here, which is the dad who is getting Dennis in the uniform. So that's the goal he's trying to achieve. We haven't identified any sub activity straight into tasks. So tasks are important. These are the steps, like really small steps that will need to be done. Like if you think about this, the one I've identified here, the five steps, actually there could be more. It could be dad needing to set up an alarm at the night, waking up, walking downstairs if they are on different floors, things like that. These are detailed steps. And these are the things that will need to be done. These are tasks. These are not necessarily the goal, but you need to do them in a specific order to achieve your goal, specified at activity level. So that here is waking up, going to the room where Dennis, so Dennis's room, wakes Dennis up. Obviously Dennis might or might not wake up immediately. So there could be other steps here. Reminds him, keep reminding him to get out of the bed or eventually get Dennis, put the uniform on the bed and get Dennis in the uniform. If you think about Dennis, he's waking up. Obviously he'll act sleepy for a bit, but finally wake up, brush, shower, viewer uniform. If you think about these tasks, brush is not necessarily the ultimate activity he's trying to perform. It's not the goal. It's a step Dennis is performing to get ready. So these are tasks. Now let's step back. Let's see, maybe the scenario that we should have talked about in the past was very specific to the start of the school year. So let's assume that we wrote this story for day one, month one, of start of school year. Usually if you're a parent, you might know that you want to ease your kid up as a new school year starts. Maybe that's what dad and mama are trying to do here for Dennis. But maybe as the school year proceeds, they might want to add a bit of an exercise. So now you can create layers on the same activity. So getting Dennis in uniform in the first month of the year doesn't have exercise. You're easing them in. It's not the most mandatory thing that is required in this first month. But you might want to add this. This is good. This is better, delightful. I shouldn't use the word delightful here, essentially. But yeah, it is better for Dennis if he can accommodate 10 minutes of exercise to layer that in. You plan it for the next month. And essentially, if you expand this for everything that is needed from the time everyone goes to sleep till the time Dennis reaches school, you could plot this left to right each detailed activity into this. And this is what user story map is. Now we took a real world example, but let's let's let's strip these off and look at the core anatomy here. It's so this is what it would look like in general. You start at personal level. You start identifying activities of activity and then add smaller tasks. You do want to slice your task into the things that are absolutely mandatory and then start having nice to house in in a real product cycle. These slices, these group of tasks that slice between the two dotted lines are releases. This could be your the first would be your pilot. And then you follow on to your next release. Let's take some examples here for concrete examples to start making sense of this structure. Let's say let's say your product manager at Apple and you were trying to do to add create Apple pay. So I've tried to put an example together. Obviously, this is not the most detailed, but this is enough to convey the story and and and explain and demonstrate how the story map user. So let's bring in a persona for an iPhone user. Actually, you know what? As we go through this, please think of these activities and sub activities and tasks in your head that you might want to add. I would actually say that pull up a white piece of paper and then start putting and plotting this for yourselves as well. And you will immediately see the benefits of it. So the high level activity this this user performs is, you know, they have a phone, they unlock the phone. They want to set up a card on the Apple wallet. And then eventually when they're at a gas station or a supermarket, they would want to pay with Apple pay. And in future sitting at home, they might want to check the transaction as well. So let's say these are like the key activities that an iPhone user would want to achieve when they're using Apple pay. Now you can start putting some activities. Let's pick up the setup exact setup activity card and expand there. When they want to add an Apple wallet, a card on Apple wallet. Well, first of all, if this is the very first time the Apple wall Apple pays being launched, they might want to learn about it. They might want to watch a tutorial. If they have done that, an activity we would require or you as a product manager at Apple would require is for them to accept terms and conditions. And then finally add a credit card. So you could see that these are the tasks like if you go task level, these are detailed steps. So launch Apple wallet, read the introduction page when you want to learn about Apple wallet. And this would be the first sub activity you will do eventually to to set up card on Apple wallet. Let's look at watch. Let's look at add credit card. The tasks there will be type of credit card number, add your name, add a date, click submit. And that's your MVP for Apple pay. But guess what? That is just an MVP or MLP maybe it's a lovable product itself. But you want to as a PM you want to continuously make it easier for customers to use. So the next release in the add credit card sub activity. You would add another feature that is they could point a camera to the credit card and scan and get everything automatically populated. So you could see now how iteratively you can start slicing releases in this format. I haven't said it so far, but I'm going to do this now about how does this can how how would one extract a user story for engineering team here. So let's pick. Let's pick the same set of tasks that we were just talking about, right? And let's start from the top. I'm going to write a user story now from here as iPhone user that there comes the user here. I want to add a credit card number and my name and date. So that I can add a credit card to Apple pay for setting up Apple card, so setting up a credit card on Apple wallet. That is a full user story that can go and become an epic in your backlog. And that's how you see when I mentioned you can extract user stories from this user story map. Let's take another example. An email client, right? Let's say you were you were a product manager at Google and we're trying to create a Gmail client for the first time. So high level activities as a Gmail user, they want to organize their emails, manage the emails and manage contacts like very basic stuff. You can see let's take pick manage email activity. The sub activity there would be compose an email, read an email and delete an email. You could actually keep adding lots of activities, right? Like as I mentioned, think about other activities. You can think about how to manage a calendar. That could be another activity, interactions, chat, whatnot. So you can expand that horizontally as well. Okay, coming back to manage email. So now think of various releases here. The first release, the very basic would have been I'm sure when someone at Google were thinking about Gmail clients, the first set of releases they would have talked about was basic email. If you actually started using Gmail in that period, you might remember that as well. So yeah, what does it require? It requires setting, writing a basic email, text based, send that email out. In the next iterations, next versions, you would create an HTML email and then ability to add attachments. So this is how it could be used. Hopefully these two examples gave you a good view into how it can be used in a product lifecycle. So I talked about this being a multi-purpose tool. But have we actually covered, have I actually demonstrated everything that I mentioned earlier? Not so much yet. There are a few things that I definitely feel that we haven't actually seen. Like in the previous examples, the two examples we talked about, this doesn't show how this is a cross-functional cohesive action tools. It doesn't show that. It also doesn't show dependencies. It doesn't show empower teams. So let's expand on that. Let's just take this example and add a layer to it. So I've added now another set of cards called teams. So you'll see now within those activities, I've actually split the compose email into two. The first one as an email client. So the ability for someone to log in and see an interface and create a basic email. And so that is a difference of activity than storing and sending that email. And there the teams identified as the API team, internal API team. And this is where the activity, sub-activity thing becomes important. So as a user, you don't care about, or you don't even know that the email is being stored or sent. Or maybe you know, but you don't really care. What you care about is managing email. So activity, that level is where that remains same. But at sub-activity, you can actually break it down on slightly system levels. When you're thinking about building that managed email customer capability. So here now, the things, the sub-activity that has been identified is compose email, storing sending of my email that I just composed as a user. And then I also want to be certain that this is safe. So now you can see the internal teams that would come into play for these user activities. It's actually also expanded from just user activity to user needs, right? Being certain is not an activity, but it's a need that is expected from the product that it should be safe. So if you expand them, you can now start adding other tasks. Spam check would come into picture. Virus scan in release three, version 1.2 would come into picture. And the team that would be taking care of it, slightly misplaced virus scan card that should be under security. So yeah, security. So now you can see that how different teams come together. Internal R&D teams come together for one activity, just manage email. And you have actually as a PM who was driving this whole thing, have showed that in one artifact. You brought them together and shown the order of things. Also shown them how this needs to come together and still like from a customer perspective. Let's add another layer here to make it more useful. So I talked about user segmentation as tool, right? Gmail is used as a free tool for individuals, but also part of G Suite, which is business tool. So in that case, there are two users or two personas that would come into picture. Someone in a corporate needs to configure an account and then only the Gmail business user can start using. So let's just assume for now Gmail business users behave exactly the same as Gmail individual. We wouldn't look at that exactly the same. But now you have by putting another user in the story, you have identified a different set of requirements. That needs to be done prior to the users, the Gmail users coming to life on your product. So configuring an account, configuring single sign-on, managing users, requires the enterprise and identity and management. Sorry, I am identity and access management team to come and deliver a few things on the product suite before you could actually give it over to the customers. So this is again a full lifetime of a user or set of users on Gmail client, but now expanded into two different users. If you combine this and the previous one, you have actually created different segment of customers in this artifact as well. So this is where it starts to get more and more useful. Now if you've read about user story maps and you've read other artifacts, these are not the layers that are present there. This is something through experience and through using user story maps in my product is something I've added to the default template that I use for myself. I've certainly seen other PMs in my previous teams use similar templates. So this is slightly enhanced version of what usual user story map template you will see. Let me know if this makes sense to you in the chat and hopefully now we can take all the boxes. Actually, let me quickly cover the empower teams point here as well. Once you've presented this view as a PM who's driving this entire thing, the individual teams, enterprise team or identity and access management team or email client team, they can see where their roles come into picture. How do they contribute to overall mission? So now with that missions figured out, you can empower them to go and do their own stuff. They can manage their backlog separately. They can be part of this entire user story map as well, but they would know exactly what the biggest bigger mission is and they can join hands there. So this is the way or one of the things you would want to do if you believe in empower teams. Great. So that has hopefully made sense to you. Hopefully you found why I strongly recommend using this tool and how this can be used as a multipurpose tool. I have to mention this. This is like the Bible for users to remapping Jeff Patton has written a book. I'd highly recommend you go and read the book. Before we close, let me show you the template that I was talking about. This is a template built on Excel. You can use it on Miro or whatnot, but let me quickly show you my Excel version of template. So here you can see the different personas are on the top most multiple personas would come into picture. So this developer is one of the personas and then you expand high level is the user activity. These are sub activities and you can actually create this can become a very detailed artifact. You can expand and see that the whole life cycle of a customer or all the three users can be seen through this spreadsheet. Vertically, you can see that different releases have been identified. There is a task to attend summary of the expected impact. Anyone can quickly view, but when you expand here, let me see. Obviously, it's not explained. There you go. Well, you can imagine when it expands. Sorry about this. I don't know why is it not if anybody if you expand, you'll see the tasks here. The yellow, the yellow cards that you talked about. So if this template is of interest, I'm happy to share, drop a note in the chat and I will. I will share this spreadsheet template to you. That is all for me for today. Hopefully that you find it useful. If you want to connect with me, follow me. Those are my LinkedIn and Twitter profiles. With that, I'll take your leave. Thank you. Have a good remaining rest of the day.