How to get started with user story mapping

Welcome everyone to the second episode of the Product Bakery podcast. Today from my bedroom and your living room Christian. Hi Christian. Hi Alex. So we gave you a little bit of an intro last week about what this podcast will actually be about but obviously it's more than important as you also get to know who is actually standing behind the show and therefore the focus of today is to have a little bit of chat with you Christian and pretty much get you introduced to everyone. Christian maybe like before we jump into the say more traditional intro. You're working in consulting and you are currently working on a client. How was your day? Have you been on the client side today or was everything like remote? I have been on site today in Berlin for a fintech company so yeah big projects going on at the moment a lot of things that need to be clarified and I would say it was quite successful day but also as always exhausting but still a lot of fun. I'm not the only one who's working consulting Alex. No but that's also like where I know your answer from like always phrase it positively you're working a lot but no it's been a great opportunity and we had a lot of interesting work today. But we choose the path. Absolutely and I couldn't be more than happy. It's nine o'clock now I still have some work to do after this recording but nevertheless super happy that we can actually have our sessions now in the evening and catch up a little bit while talking about products. Yes. So going back diving deep a little bit on your history it's not the most traditional product background right and I think there is also some background on how this podcast or where this podcast actually got its name from but I leave this up to you. Yeah I hear from many people in many Reddit and Facebook groups product groups because I want to stay on top of things and I'm also interested in what the community is struggling with. Ask what is the best way to transition into product. Yeah I'm not sure if the way I went is the best one but I think it's worth sharing. I started my career working as a baker in 2007. After almost. Like chopper, bread. Cheesecake. Flour. Buns. Whatever you can imagine the full stuff. In Germany we have even the possibility to make a master degree in baking which I did and enabled me to start studying. And in 2011 I started studying business administration. Back then I had a small side job in an IT booth where I was repairing PCs and stuff and I met a friend who was also called Alex and he was a computer scientist. He and I both had a big problem back then. Girlfriends who didn't know what to wear. Obviously a big problem for a man and we decided to tackle this. At least you had girlfriends. Yeah that's also true. Nevertheless with this problem statement we developed two applications. First of all the small wardrobe application called pocket rope which is unfortunately not any longer in the app store. We took it off a couple of months ago because the maintenance was too much. However we developed this wardrobe application as well as an affiliate based online shop. Started in 2012 and launched in 2014 and we got featured by Apple in the Apple lifestyle charts back then in April. That was quite a biggie for us. It was a student project and we didn't believe to be super successful or make millions with it but we had fun and this project helped me and also my friend to land our first job. We both started working at a company called Shopgate. This company provides mobile solutions in form of an app and mobile website for your online shop so you can just integrate yourself and get the full-fledged solution. I was responsible there for the mobile apps. I was covering all parts related to the design and the conversion rate and honestly it was back then already a big project for me and I'm super thankful and happy that I was supposed and allowed to work on this. When we speak about mobile apps what year are we talking about or more in detail what iOS version do we talk about? We talk about iOS 7 and iOS 8. It was the time when they introduced the flat design. When we were working on our own app back then we designed everything on iOS 6 in Squamorphism. We started developing and then we needed to throw everything away. That was a tough time. One of my responsibilities was to bring the apps from iOS 6 to iOS 7 because they were a bit outdated and that was my job and that was actually for me the introduction into the world of product management and the first steps that I've made. After about two years I got an offer from a company called New Store which was founded by Stefan Schambach, the founder of Intershop and Demandware, one of the first online shopping systems. I started there. The company New Store is still building an omnichannel retail platform which allows big brands to integrate all their business processes into the system and enable features on mobile apps like a same-day delivery from a store with an Uber driver who comes to your place and also exchanges products that you just have bought or you go into a store you want to buy two pairs of jeans. One is there, one is unfortunately out of stock and you still get it same-day delivered from another store to your place so these kind of things. I was responsible there also for building an SDK to enable agencies to build apps upon this as well as building back-end services. This was to me the introduction into the more technical side of product management and after two years I moved on to a company called SumUp which is a fintech company building card reader and payment services where I also met a friend called Alex who is right now hosting this podcast with me together. I was responsible at SumUp for redesigning the whole platform together with Alex and my team we redesigned the websites, the merchant back-end interfaces as well as the mobile apps. We introduced the design system CircuitUI which you can check out on GitHub in case you're interested. In 2018 I started and I was in parallel already consulting a couple of companies and I had a lot of fun with this as a kind of small side projects and then beginning of 2020 I realized it makes so much fun that I really want to do this full-time and I quit my job and since January I'm working now as a self-employee consultant. Wow, you went through quite some different roles. Now bakery aside you had your own kind of startups, you went to smaller, bigger companies. What was the most interesting part of transitioning through these companies? One of the most interesting or also most shocking things that I've realized in going through all these different companies also while I was doing consulting is you see patterns and you see patterns in all companies in terms of issues they're facing. Obviously also things they're doing well but with primary focusing here on this podcast on things that can be improved upon or on patterns that usually go into the wrong direction. So what I've seen is that two things are usually the reason why projects do not work as expected which is missing transparency and communication. I see this as one thing and the other one is not enough time spent in planning. What's like your take on better planning or increasing like transparency and improving communication? How do you go about that one? Yeah, that's a big one, right? The question is where to start. We can talk about problem evaluation. Many companies call it ideation phase. I'm not a big fan of calling it like this because you should in product management rather focus on problems than ideas but I don't want to say that one exclude the other. Sometimes great ideas can also lead to great results. However, the best thing is to really focus on problems. We're not Steve Jobs or someone else. I mean obviously as a designer I'm very familiar with all sorts of like ideation framework. It's worth also thinking about or mentioning that obviously as you say the ideation phase needs to come after the problem phase, right? What are you going to ideate if you don't have a right problem? And I only agree I do see it way too often that people jump into this ideation phase. It's great to talk about solutions and have everything there but yeah I think it's totally worth to ideate but you need problems. Yeah, I agree. The product discovery process in itself is it's quite a big topic. The question is where do you start? You have the problem, you need to evaluate, you do your market research, you go through the phases of data analysis, etc. And this kind of stuff needs to be done and it's worth I think many podcast episodes. But if we look into companies and how things are running there, the perfect process sounds always amazing and I'm a fan of following best practices. But if we are honest to each other, if you go into a company that just have finished a fundraising of a couple of millions or hundreds of millions even, they have pressure, they have things to do, they have challenges and what do you say when you come in as a consultant or even as a product manager? Are you stopping everything and saying hey we do product discovery first and we challenge the whole roadmap and the whole strategy and we not do this? That doesn't work like that. You have projects that are ongoing, you have deadlines and for sure they are not always the most valuable products. Sometimes these kind of things fail but this is also part of the game. What I like is coming from the other angle and first of all see okay what is the status quo, what are the teams working on and how can we improve up on the things that are in progress right now and make sure that we evaluate better if we are building the right thing. Stopping things is not always possible as I mentioned but you can do damage control. There are a couple of steps between the product discovery and the delivery or the development and something which is in between which I really like is the feature planning phase or product planning phase. I'm a big fan of doing user story mapping. What is user story mapping about? Once we have a problem statement and data many people start jumping into creating tickets, prototyping, user testing which is all good and necessary. User story mapping is the step before. User story mapping is a workshop based methodology that brings first of all people together so that's what I like most about it. It brings people together to think about the user activities and possible user stories. So what does that mean? The idea is that in a user story mapping session you think about what kind of personas or users are involved into the feature that you want to build. I like explaining it with the Apple Pay functionality on iPhones. Let's imagine a couple of years ago Apple Pay is not existing and you and I are product managers who want to build that feature. So if we do a story mapping session around this Apple Pay functionality the first thing we would do is obviously pitch the feature, the business value and all the information we have gathered. And the next step is together with a small group of product managers maybe one or two designers as well as some stakeholders who have the domain knowledge and who are experts in the world of payments to map out a user flow. If we for example have a persona called the I-user, what would the I-user do if you look at activities that these kind of people perform? So the first thing is they obviously unlock their phone. As a next step they go to the wallet app. Then after that they press the add credit card button. Then they add the credit card information. Then they accept the terms and conditions and so on. So you really think in a kind of narrative flow what is going to happen in natural language that everyone can understand. And then once you have the flow defined you go into each activity and ask yourself what needs to be built in order to deliver the full functionality. If we check out that I as the I-user going to add a card. I press the add credit card button. That would be already a user story because you need to have this button in place. Not a biggie for very likely but the next step would be then to edit credit card information. And as we know there are two ways how you can do this. You can either just enter your credit card information manually in a form or alternatively you can scan. The question is now do we want to build both or do we want to just start with the form or do we want to start with the scan. And you start now discussing with people and start also to define what's in the first version and what not. We could for example say first version we deliver the form without the scan and the scan will be delivered in a next version. So user story mapping is made to have exactly these kind of conversations and define how the product has to look like. But explain me one thing when it's like about defining key specific features because obviously we all know how the adding a card works from Apple or at least I guess everyone in tech who pays attention to these little things knows. But is there like a part of going back to the ideation of really coming up with the functionalities as part of this or when would you do the user story mapping? Do you already know the individual functionalities that you want to build in when you start or is it something that also comes up as part of the exercise? That's a good question and I would say both. It depends on the industry, on the products you are building. Let's say if we live in the world of FinTech, you have very strong regulations, you have established standards on the market. So it's very likely that these ideas are already floating around or will be part of the future discovery on the feature scoping. On the other hand if we look for example at companies that are building chatting apps like WhatsApp or something like this where you have a B2C product. There you have way more options how you can solve problems with less regulations where you have way more creativity and I have experienced many times that people then come spontaneously up while you have discussions during the session. You need to imagine during a story mapping session there's for example a product designer, a product manager, then you have a guy who's a stakeholder or an expert in legal etc etc. So with these kind of people you have great discussions and everyone has its own point of view on the topics and this is actually to me the best time and the best outcomes that you can produce if you have smart people in one room focusing on one thing. But it almost sounds like you could in theory for each step in the map really have an additional session. Let's say let's run a design sprint on the challenge specifically on how to add a card to the card and then is that an option to say okay we have an initial user story mapping and then as you go to refine further and add further features functionalities and then prioritize them along different releases? Yes absolutely. The first step is to come up with the user flow and some high-level user stories. We don't have any idea of how the design has to look like at the beginning. Most important thing is that we have some placeholders or some basic ideas that we want to build later on and then it's perfect to take this kind of user stories which you then by the way afterwards directly translate into your backlog to come up with the grooming session, the sprint sessions, the prototyping because what many times happened is you have a feature and you say we want to build Apple Pay. So just imagine you would give this to one product designer who would sit down and design a flow out of nothing without knowing how the flow works, without knowing how the regulations work, without knowing what's technically possible and what not. Scanning is nice but maybe Apple will say hey our OS is not ready for using a scan or something like this. So you need to have these interactions and these discussions to know how you design and build it later on. And a design sprint is the perfect thing to discover designs for solutions in different ways. Absolutely. And then going back to the engineering team and discussing what can be achieved in shortest time or maybe even the longest time that also depends on how you prioritize. But to answer your question yes it's great to go afterwards into the designing phase. Okay cool. As we also talked about designs, prints and general many different frameworks obviously like user story mapping is also one framework put on the list. One thing that I do see dangerous sometimes is when people take frameworks that sound good or where the process has proven to be right really a couple of times. What would be the perfect stage of a project or what would be like the perfect project to actually use it and when would you actually recommend to not use user story mapping? Let's maybe start with the second question. I would not start doing story mapping when you have not enough data or if you haven't enough evaluated the feature. That means for example if you want to build a feature that has third-party integrations, contracts that need to be negotiated, missing customer data, missing market data. So as long as these things are not clear I would definitely not do user story mapping. User story mapping is a nice tool but it doesn't solve all the problems. There are many product teams that I see are sometimes struggling with the whole preparation phase in first place. You need to have, and I think that goes back to the first question as well, you should really have good data in place and you should be sure that it's complex enough to map it out. If you have a little straightforward feature that you want to build you don't necessarily need to do story mapping. So it's a mix of like complexity of the project that's given, information that's given and prep work that you also have to invest upfront sometimes in order to be set up for success when you run the session. The best way to approach projects in general is to do a proper problem evaluation and to get the data you need. Without this you won't go anywhere. What would such a problem evaluation session look like? What would you do to... That depends on the product you want to build. It's very important as a product manager to first of all understand the problem. Let's assume we do have a problem. In the next session or before we talk about sessions I would say it's rather the individual work that needs to be done by looking into the data. If you have access to a database you go into database, you do customer interviews, you see what the competition is doing etc. This whole kind of discovery phase and competitive analysis and stuff like this should happen in first place. At some point as a product manager you pull in the right people to accelerate this process or also to get the knowledge you need. For example if I do customer interviews I always do it with an engineer and designer to spread the knowledge and also have the people asking the right questions. Very important. That depends on the different kind of phases and also it depends on the product itself. Some products require more or some features require more research some less. That really depends on again complexity and what you want to build at the end of the day. And then as an outcome you said you have the backlog pretty much ready. How do you take it from the user-centered mapping? What's the next steps and how does the user-centered mapping then tie back into the process as you move on and develop the project? I'm still trying to understand if it's a workshop kind of thing or if it's something that you then like rather include in the overall product development process. Once you have had the workshop you need to make the next step. The next step is after you have created the story map it's important to go back to your engineering team and pitch that story map. Ideally you have already while you're creating the story map one engineering senior engineer or architect already as part of the session to get some pre insights. But the next step is after it's created to talk to your engineering team because they know exactly what's possible and what not. And these guys are usually very smart they have maybe great additions to your ideas. And you also need to get the sign-off from the team because if you agree on MVP or the first version you build it must not only come from you it also must be agreed and accepted by the team as well. So this is one of the things you need to do afterwards and once this is clear and everyone is aligned and we know what we want to build and we have a clear MVP defined then it's part to translate these user stories from the user story map into the backlog. That means creating the placeholder stories or maybe even detailed stories depending on what you know and then definitely then you have had already a product designer as part of the session etc to sit then down together with your team and start planning further steps which is coming up with either prototypes or high fidelity design and then either refine them with the team and make them ready for development or taking the prototypes and testing them before you have proof of what's the best solution. I see it as a part of the process but what I also like to mention is that I recently had a had a story mapping session with a company and there were a couple of people who recently joined product and they looked at it and said wow now where I see this whole flow I know how to write my test cases which is great and which is also not a bad way of thinking but user story map is more than that. The most important thing when it comes to user story mapping is making the connection to the backlog. Now to clearly state out that the things you have agreed upon there need to be translated in your backlog and it's also important to understand that you will save so much time because you have a clear picture of how this whole flow works and how the solution will be defined and also designed later and with design I'm not talking about the design itself also process-wise how this whole thing will run. You need way less discussions later on on talking about this whole kind of process and product in an abstract way because you have visualized it so I believe that with more planning you have way shorter development times. Yeah it definitely sounds also like a generally great way to get everyone on the same page and I think exactly doing that is so important and I do feel like that for all sorts of workshops, frameworks, formats that you can run in a team if one benefit is that it gets everyone on the same page you're already like almost one because from there it's just so easy to take it. But also a question back to you what are your experiences have you done user story mapping already? We worked together so we're sharing that we had some of our story mapping sessions together. I even think that I was first introduced to the user story mapping concept by you in the first place and I do think it's great. One thing that stuck with me was especially starting from the back and working from back to front. You probably can deep dive on that from a more theoretical kind of way but I think when you start from the point of arrival for the user or the end point of the map it really forces you to think backwards into really the different steps that are needed and to make sure that you don't forget about any edge cases or intermediate steps and that was just like something that I took and applied to not only like user story mapping but where I try to generally look at all sorts of journeys from both directions to just make sure that I think of everything. I think we need to pick up the audience here. What Alex and I have been doing back then is once you start using or defining a story map let's take the Apple Pay example. Let's imagine again we want to build the Apple Pay feature and what I always recommend if you want to build a new feature that you always start on the very last activity. So if we go back to this Apple Pay scenario the most important question is what is the very last thing the user does and which user is it in case you have many users in your flow. We could for example say the very last thing someone does in this new Apple Pay feature is making a successful transaction and the question is what happens before. Well now you need to think because it's not easy to ask yourself what is it. Is it reviewing data or entering the data or is it accepting terms or conditions. So in this case now the last thing or in my flow which is I don't know how Apple developed this feature but I believe the the last user step is accepting the terms or conditions. Before this you review the data you have entered. Before this you're going to enter the data etc. But the idea is to start from the end and I really recommend this when you want to build new features because as Alex said you really need to think. It forces you to think at the end and you go back and the good thing is if you go back from the end the likelihood that you go into the wrong direction at some point is way smaller first of all and secondly you will think harder in general. I have seen many times that when you start from the beginning that you just throw in ideas and at the end we have a mess up kind of activity flow that you correct all the time when you go back from the end it's way more focused and efficient. On the other hand if you want to visualize a story map for a feature that you have built already which can be also sometimes very helpful I recommend to rather start at the beginning because you have this functionality in place and it's more about reminding what is happening to be able to build the whole flow. The reason why I sometimes work with teams and story map feature that are existing is remembering the HR manifesto which says working software over comprehensive documentation sounds generally nice but it's in 2020 or in the last years the biggest problem why companies cannot scale. Nice to be fast and to build running software as quickly as possible but once you make your fundraising and you want to start hiring people you stand there and you have no documentation people don't know what to do. I can't go on for hours now but I think we all know in which direction this is leading. User story mapping can be also a great way to start visualizing how user flows and also business processes works even technical processes. I'm just writing right now additional information in an email course that I'm designing around user story mapping where I deep dive into this a little bit more explaining people hey once you have defined a product or build a product and you define the user flow you can also add the backend processes that are happening. For example once I have entered my credit card data as the I user the payment SDK will send the data to the payment backend or to the PSP the payment service provider. It's important that this is documented and I'm not saying that you should use UML the flows or to make a technical architecture out of this but for product people and stakeholders it's important to see what the flow is and can be sometimes very helpful to visualize this in a user story map as well. Yeah this brings me to thinking of how you could actually integrate something like user journey mapping and user story mapping because it would just add this a new level of the emotional state and the empathy level of the user for example when walking through a feature or set the functionalities while even like putting lights on the offline steps like everything that happens between each interaction with a digital product. What do you think should come first the customer journey or the user story mapping? Considering also on what we said at the beginning right you need to have the problem laid out before at the beginning of everything it also means understanding the user before everything else so the customer journey map helps you exactly finding pain points along the way finding problems along the way and you can then start building the product and you correct me if I'm wrong but I would start with the user journey map or a customer journey map but it could be a nice or interesting thing to combine the two at one point especially when we talk about like documentation so that we say okay we have three different layers what is the interaction with the product what is the general interaction with the word of the user and what are all the different touch points in between and what is the technical architecture behind it right yeah I agree along the lines I agree the reason I'm asking this question it's obviously kind of provocative question and also a question that is not easy to answer the reason why I'm asking this is if I look into all these communities yeah you see people writing a Facebook post saying should I do user story mapping or customer journey mapping first what kind of answer do you expect when you ask such a question especially without giving people any kind of background people are always looking for yeah how can I say that the perfect solution but the perfect solution doesn't exist on the other hand I believe the perfect solution is just doing things when you think it's right can overthink processes and product management or you can just do it the way we learned I guess is by just doing it wrong and not by doing it right and we can talk for hours about what should come first or what should come last the most important thing is that you understand what you're doing if in case you don't have clarity then I recommend to do both at the same time and Christian I really think that this is a great bridge to also what we are trying to do with this podcast because what I keep mentioning and what we keep discussing is also this general I would not even say problem this general topic of yeah you have a lot of different processes or tips and tricks and best practices in all sort of like professional areas and it also comes from the way we generally educate each other and the way we generally exchange with other people from our let's say area or where we go to conferences that are either very product design specific or very development specific or very product management specific and the thing exactly like this what exactly do I have to run who owns it and who performs it and I've also seen where product designers then feel like they need to own a specific process and need to drive it specifically and and this is really really where it comes down to okay we're talking about building products we're talking about every company pretty much is now more and more moving into cross-functional teams and having fully empowered teams with all the skills that you need really about also the collaboration and the combination of the different tools to make sure that you build the right things and we also see more and more multi-product companies you see many single product companies transitioning into multi-product companies offering more services features products etc and most important if you make this transition is also to be a real product focus company you can build a startup or a company without a product management team without any problems if you have smart people a smart founder etc that's all good but if you really want to scale if you really want to grow do we want to make something big and successful out of this at some point you need a product management and what I see is and this is not a general statement to all companies that product management especially at least here in Europe is not valued enough or also not strong enough is it the chicken-and-egg problem I would clearly say no it's up to the product managers to stand up and to make sure that you advocate in the companies the importance of product management with a structured way of working and good processes in place don't over process it but it's important to have a basic foundation of ways of working absolutely to sum it up because it's definitely too long of a discussion to put it in here I do see as well that especially when it comes to product management or between the different lines between the roles there it's still not super clear what are different responsibilities what are really the role descriptions and I do think many professionals don't really know what's expected from them and then it's easy to blame the chicken-and-egg problem and it's really about you first need to know it and then you need to own it and then you need to advocate it it comes down a little bit to that point this is something for lead separate session so trying to summarize it we've heard a lot about user star mapping I feel like it was also a great intro to get to know you a little bit better for everyone out there obviously like we already had the chance to work together so with that said I would say we can wrap it up here my key messages around user story mapping is in case you want to get started with it or think it's worth trying it out I would say take one of your running projects start with a small group of three or four people take another product manager take a product designer maybe an engineer and start designing a small user flow with personas and a couple of options that are maybe already part of your backlog and start really understanding what this is about how does the user interact with the product you want to build it doesn't need to be perfect you don't need to go crazy with the perfect process by putting it into your backlogs doing design sprints but start understanding what is going on from user perspective that can be already so helpful because I remember I many times just started planning something and asked my team to develop something without really understanding it if you want to go a little bit deeper than you can start at the end of it and we do the process in a more extended way in case you're interested last time in our podcast we said already hashtag no advertisement but in case you want to learn more about it I'm also writing a blog christianstrang.com slash blog so I have two articles about user story mapping where you can just read what we have discussed in a little bit of more structured way maybe and yeah just give it a try I would generally say self advertisement is no advertisement I was at christianstrang.com slash blog exactly check it out I really have to say the guy knows his shit about user story mapping I definitely have to learn a lot more but thanks a lot Christian for sharing all the insights and anything else to add yeah Alex thank you very much was a great a talk today since people don't know you as much as they know me how do we want to proceed the next episode ah I'm fearing that it will be a similar session where I have to introduce myself not only that looks like you want to announce the topic or a deep dive topic then when we do the episode yeah let's see where the show takes us enjoy the rest of tonight I would say I will jump back to my closing emails there is still some time before midnight that's sad have a lovely evening everyone