 Hi everybody. I'm super excited to be here. I know a few people messaged me saying hi. So and that they were excited to come So thank you so much for coming Really pumped to talk about some lean Synthesis, I feel like it's like all the buzzwords at once So in this talk today what we're gonna cover is first what is synthesis and analysis because that's always a good starting point How to streamline your synthesis Some ways to avoid confirmation bias and kind of like how to create on the go insights So I might be switching my screens back and forth a little bit So just bear with me here as I do that. Um, but I also want to show you all Some of the things that I'm talking about as I talk through them So, um, as Renee mentioned, I'm mickey. Uh, most importantly, that's poncho Um, and as she said I've been a user researcher for quite some time I think it's actually like nine years now So it's getting getting up there. Uh in those those years I love pokemon and world of warcraft huge fan of pokemon. I have them like hanging everywhere Like photos of pokemon in the house as Curtis knows I write psychological thrillers in my spare time Because it's cool. Uh, and then some of my favorite sports are tennis archery and fencing So like archery and fencing. I guess they're like old school You know, why? Tennis not so much. Um, but yeah, and then as Renee mentioned, um, we live on a small island off the coast of France It's called jersey. It's part of the uk Google jersey cows. They are so super cute. Whoever said that they their their favorite food would be cow Maybe might rethink that after saying the jersey cows. No, I'm just kidding because I love it too. Um, okay So cool. Um in the chat, uh, because I like to start with something engaging Um, can you write how you feel? How do you feel about synthesis? Uh, and since I'm a researcher I'm all about the feels. Uh, I love hearing about people's feelings. Uh, so, um, I would love to hear how you feel about synthesis and maybe you can find some, uh Commonalities in between you and other people. Um, so that you can synthesize your own comments um, okay so Let's get started As I mentioned, uh, we are going to start with kind of understanding what synthesis and analysis is So how I define synthesis and analysis is making sense of user research by bringing it together and finding common patterns and trends Across the research and the whole point of synthesis is that it enables a team to take action Right. So if we have a bunch of data, so let's say we have like seven 10 12 15 qualitative interviews if you dump that on the team They're not really going to be able to do much with it So the entire point of synthesis is creating like these small insights, which we'll get to later that help people make decisions Help people figure out how to improve products. They help innovation, right? So they help us know what to create next Um, so again, it all goes back to enabling a team to take action The only problem is is in our ideal world. We spend should the should Should spend double the amount of time of a session on synthesis So one hour interview means that you should be doing two hours of synthesis So if we took a generative research, um study, which is typically speaking around 12 to 15 interviews one hour interviews You're looking at 24 to 30 hours of synthesis And there's a lot of steps involved, right? So we have a lot of different steps that go into this ideal synthesis process And that does not make it feel lean in the slightest, which is why it is Tempting to say the least to skip synthesis, but What happens if we do that? So if we decide to skip synthesis and we just do the interviews Um, what can happen is that information and i'm speaking as a researcher who has done hundreds and hundreds of interviews before that information can become very muddled in my brain and sometimes especially if you're juggling multiple studies at once Some studies kind of like merge into other studies And then you're like was that from this prototype or that prototype? So it can lead to really unclear results It's also if we skip synthesis You're highly likely um to be under the influence of confirmation bias Uh, which is when you pick out things that you wanted to hear that confirm your hypotheses And that feel good and you ignore all the other crappy stuff. That's actually quite helpful in improving your product and again looking at like Just even like five interviews There can be a lack of action if you skip synthesis because you're kind of just sitting there like okay Like what do we hear from these five people? Um, and like uh, we don't want to synthesize Let's just move forward right you pick out those things that you did hear that might not have actually been consistent across Your participants, which means you can build the wrong thing and ignore research And to be completely honest and this might be a little bit harsh, but if you skip synthesis I would question why do the research? Okay, um, so the synthesis part is the that I hate this phrase of actionable insights, but it is the thing that puts research into action. Okay So what I want to do is I want to strip down those like 24 to 30 hours of uh, Synthesis time that I know nobody wants to spend. Um, except for me. Maybe I love synthesis. So, um, But I want to introduce something called lightning synthesis to you Um And the benefits of doing lightning synthesis is that although it's less time you spend less time doing synthesis You still are able to understand the problem rather than going off like your confirmation bias Even if it's unconscious, uh, and you're not meaning to do that. Um, you you look at the problem rather than your assumptions Um, and what's really great about lightning synthesis is you can pull other people into this process Which means that you're collaborating and communicating them with them on the go Again, which also means that you're sharing this knowledge Much more efficiently than if you were to wait after like seven sessions Do the synthesis at the end alone potentially because nobody else wants to join your like full day workshop of And then you have to share it back. So if you do this lightning synthesis with a team of people What happens is you share knowledge on the go Um, which makes it a lot easier at the end of a study to like dive right into the action And finally gaining buy-in from from others like I don't know if you've ever tried to explain how great something is kind of like what i'm doing right now Instead of showing people. Um, but if you include them in this like short synthesis session What can happen? Um is it's easier for them to feel the impact and and see the benefits of it If they're part of it. So um, including people in these short little um synthesis rounds Can help you gain buy-in for either more research or for more synthesis. Um, so there are quite a few benefits to this lightning synthesis And then as well What you can do with it and what I have used lightning synthesis in the past and I have used it as a like a full blown user researcher Like I have used this before because I've I've also been very time poor And and so what can happen? Um is you you might not need to create a formal report So what I did is I did lightning synthesis on a mirror board And I'm going to show you my template in just one second so I can explain a little bit more what that looks like But I ended up presenting insights directly from that board So like we synthesized as we went and then at the end I was able to just like go right in and just present from there because everybody had already been a part of it So I didn't have to spend time on a report And then with this particular type of synthesis you you you highlight things that are helpful for your team helpful and help and making making better decisions So like pain points needs and quick fixes and these things create a sense of action and urgency Which leads to the next steps. Um, so those are all the like benefits and kind of you can avoid certain Things that tend to take a lot of time. I know report writing can take a lot of time I know getting from like The synthesis to the action can can take some time as people have to digest information But lightning synthesis can kind of speed up that process and make it more um efficient so What is lightning synthesis when we when we look at it? And I know that there are like quite a few steps here But I promise that there are fewer steps than in that slide before which have like I don't know 10 or 11 steps um, so I have tried to half it As best as I can the reason that I'm saying you don't ever have to do synthesis is because it is necessary um, so um, but I am trying my best to help you understand how to kind of lean that out And the first thing that we start with is gathering gathering all your data and that can take several forms So it can be notes from a research session. Um, it's best if it's like session recordings or transcripts Um, when you when you gather all these notes, um, it's it's super helpful And having them to refer back to during the lightning synthesis And and just a tip that I have if you're using a software Or some sort of recording device that allows you to timestamp recordings do that for like highlight reels or quotes It makes it easier to pull them out later And what I mean by highlight reels are like little clips that you can create um that show people Generally speaking having a really hard time doing something. Uh, so range clicking Is a great highlight reel Or you know people failing to complete a task. Um, so if you mark down timestamps, um on on those recordings It can also make it more efficient for you when you're pulling out additional data And then we are going to create global tabs. Um, so, uh tabs are the things that help us organize the data If we just looked at all of those notes as they were They might be a little bit scary And so, um global tabs, um are the first step to creating your lightning synthesis section a session And first I'm just going to do a quick Why should you tag? Slide because it's important to to talk through this. Um tagging brings order to chaos Uh, right? So when you choose uh to to kind of organize and synthesize and structure your data The best way to do that is by using tabs, right? Because again that helps show concrete evidence of pain points needs and quick fixes Um, and it inspires action. Um and helps you identify bigger trends So if you say that something is a pain point, right and you hear that same pain point over and over again You can sort of say hey that that's a trend in our data, right? Um and the the tags that i'm going to share with you Are the ones that I use specifically for lightning synthesis. Um, and I will explain again In just a minute what that looks like and and how we bring this all together The cool thing about global tags is you can use them across all your projects So you don't need to think about new tags and new tagging taxonomies after every project Or for every project what you can do is use these lean global tags Across all of your projects. So it makes it a little bit easier for you So these are the lean global tags that I tend to use I pick four at a time Um, I added on five because I thought maybe that would be interesting for you I'm just to have a uh an extra one in case you wanted to focus on something else But these are the most lean uh most common lean global tags that I use Um, so when we look at these a goal is something that somebody is trying to accomplish Um, so as a goal, I want to run a 5k, right? So that's my goal my goal is to run a 5k by like The end of uh, I don't know the summer Give myself a lot of time. Um a need is something that I need to fulfill a goal Right, so I need shoes. I need running shoes to get me through these horrendous runs Um, I might need a water bottle, you know, I might need a training program So these are all the things that I need to accomplish a goal and a pain point is a barrier or something that's difficult Um, and it does not It's like an obstacle for me trying to accomplish this goal So a pain point could be something like I can't run without losing my breath Um, or I get like muscle cramps or I get you know blisters and like um, or I don't know how like should I run in intervals or not, right? And then a tool is something that people can use to try and accomplish a goal So this could be anything from like a physical objects So like shoes are are technically a tool that we use. Um, but it could be digital as well Um, so like uh couch to 5k is like a super popular app that teaches you literally how to get off your couch Entering for a 5k. Um, but always keep in mind that tools don't always have to be digital You could be looking at a pen and paper um as a way Actually when I used to go to the gym and do bodybuilding I used pen and paper to track my progress So tools aren't always digital keep that in mind And then finally a quick fix is something that's painful or annoying for people that can easily be fixed within the context Generally speaking of a product or your product. Um, this, um, uh Dovetail the dovetail team is going to make um a small um kind of like handout for you Out with these lean global tags so you can look forward to that um as well um Cool So what do we do with these global tags? Why am I lecturing you on these? horrendously awful things um, so what happens um is you tag each session ideally right after and this is where we dive into what a lightning session actually looks like right, so As a user researcher, um, what I do is when I invite stakeholders to research I add on 20 to 30 minutes after a session Um, and so this is baked into the calendar invite. Um, so let's say we have an hour session I invite them for an hour and a half calendar block Um, and so what we do is right after that session we take 20 to 30 minutes To tag the session to synthesize the session in a very efficient way Right, so this is where lightning synthesis kind of comes into play right after the session And I I do stress that it is really important to do this right after the session Because that is when the information is super fresh for you And you can like really get it done really quickly trust me I have done it where I've tried it to do it the next day. I tried to do it at the end of the day It's just a nightmare. Um, so um always try and take the 20 to 30 minutes after the session to do this So, um, how to run a lightning uh synthesis session You create a board or you can use my template which you will get um access to And i'm just going to pop in here because this makes it a lot easier for me to explain Rather than telling you What what this is so if you see this board, um, and again, you will get access to this as a resource If you see this lightning synthesis board, uh, you'll see that I picked four quadrants over here and these, um Are directly lined up with the global tags that I was thinking about So we have I picked goals pain points needs and quick fixes right and so, um within this time within this 20 to 30 minute window After the session we go to this board and we're like, okay for each quadrant We're going to spend a few minutes. It's both divergent and convergent work, which is fantastic for synthesis Divergent being things that you do on your own and convergent being like discussions that you come together and discuss something So for a few minutes everybody writes down on their own all the goals that they can think about from that uh session Then the next few minutes you discuss the goals and you cluster the similar ones that came up Then you move on to pain points and you do the same thing needs the same thing quick fixes the same thing Right. So what you're doing is after each session you're getting down the most important information right away Okay, and the reason that this is so efficient is when you wait after seven sessions That's if you do the synthesis right after the seventh session You might have a really great memory of the sixth and the seventh session But then like the fifth fourth third second and first kind of all like mush into each other Um, and and it's harder for you to like pick out information um, so what this does is this this allows you like a really fresh take on on the um On the session um and gets all that information out So you do this for each participant and you'll see here that I also have an area for insights I also have an area for assumptions and biases and I also have an area for action items I will talk about insights and biases in just one moment But I just want to um highlight this action items area It's super important because what you can do is right like right after that synthesis Session the lightning synthesis is within it. You can start to assign actions and come up with some things that you can do So that's what I'm trying to stress is like be as action oriented as possible Okay, I am going to dive back in uh to uh this so great and um, this is a sample agenda But again, you will get the resources um, and um, you will you will be able to um see the actual template So as I mentioned Lightning synthesis is all about efficiency. So it allows you to pull patterns really quickly and write insights as you go So um and and everybody's like what's a pattern? I always think of a pattern as like a trend of three or more people So if like three or more people like said the same thing. So, uh, let's take that running example. Um, so let's say Three or more people were like, uh, you know, I don't I don't even know where to get started Right that that becomes a trend when you start to hear that or a pattern or a trend They're very interchangeable when you start to hear that from three or more people So that's why this like lightning synthesis is so great because like after like, uh As i'm going to say after just three participants you can start seeing patterns and creating insights Um, and just before we get into writing insights really quickly Um, I just wanted to find what an insight is because I feel like this is like full of buzzwords today Like synthesis analysis lean insight. Um, an insight is something that um makes us go like, oh, wow Like oh and wilson. Wow. Wow. Wow. Um, that's like an insight, right? Um, and it pushes us to challenge something that we previously believed Or it like disproves something that we believed right? So it's something that is like really surprising Um, and that's like, oh, wow. I I had no idea that that's how somebody thought Of course like insights can validate our hypotheses um, but generally speaking like insights are are really like about The underlying motivations behind why people are thinking or feeling or saying what they are So how do you create these insights on the go? Right? So as I mentioned, um, you can start creating these insights Um as like as you go through these like lightning synthesis sessions So I just want to quickly talk about the three components and like in all of my other slides and like presentations and articles Like there are like six or seven components of an insight So i'm also trying to lean out insights for you Um into three different steps and three different components. So key learning So that's what the like attitude or behavior is that you kind of learned Or the problem Um the why so why people are feeling or thinking a certain thing or why people are encountering this problem And then the consequence. This is the most important thing and I see like Researchers forgetting about the consequence all the time. Uh, the consequence is like the so what like what's the impact of this? um of this insight So for instance, let's say that I was using the couch to 5k program for training for for a marathon a 5k um, so In that like let's say that like between week three and four like there's like a major jump Right, so like I go from like running and walking and suddenly I'm like running a lot more And I'm feeling very like it's like it's it's kind of like shattered my confidence. I'm like, oh I'm clearly not doing something right. I'm feeling really bad about this A lot of people will like leave the insight There like they'll be like, oh the jump between week three or four three and four was like really tough for the user Right, but what's the next step? Okay, like what's the so what you know what what does that mean? What could that lead to and generally speaking it's like what happens if you don't act on this insight? Like what happens for the participant your organization your product, right? So if I'm feeling a lack of confidence in myself What might happen? Especially if you don't say to me in the beginning A lot of people experience difficulty between week three and four, you know Like if you don't say anything like that in your product, what could happen is I could actually go and be like this Is a frustrating experience. I'm going to go to a different training program So that is the consequence, right? So it's not just that the user is frustrated and feeling like less confident They could leave the product, right? So I just wanted to say that really really quickly in terms of insights And then right before I get to confirmation bias and that's the last part. I promise. I'm almost done So what happens is when you when you're going through that board? When when you're creating these insights, I usually start to create insights after the third interview Um, so let's say that I'm interviewing seven people. Um, I will start to create insights after the third person Because I start identifying patterns So again, if three or more people are saying that same thing week three to four is a really big jump I don't really have any confidence anymore That then becomes our pattern and we can write that as a as an insight Right after the third participant. So once you start seeing those patterns on the go You can start writing these insights as you go and and by the end you'll have like a load of really awesome insights Um, and and you won't have to do like a super long synthesis session at the end. Um, so this is again This is really about increasing your efficiency In terms of like gathering that data Tagging that data seeing those patterns early on and then being able to write insights like as you're going through the data So you might have quite a few let's say you're interviewing 12 people You might have quite a few insights even by the time you get to like the six or seventh person Um, so that's really really cool. And then you can build on those insights further if you hear more people saying it so I just want to say if you're doing this synthesis, um Any kind of synthesis but this kind of synthesis because it's more quick be careful of confirmation bias And as I mentioned, this is like choosing like you're you we generally speaking unconsciously do it I've done it before but we're picking out things that we want to hear Like oh that validates our hypothesis Or like oh, they said that they love this and we can kind of like ignore Some of the more important feedback Um, and what that can do is that can lead to really poor decision-making So instead of listening to like what actually went wrong So that you can fix the user experience or that you can create better features. Um, you're kind of like oh this person Loved this Uh, and then you're like continuing to create something that's like based off of that which like one person loved and nobody else did Um, so it just leads to poor decision decision making. Um, so as I mentioned on that lightning synthesis board I had like an assumptions and biases section. Um, and in that so before each session I just like brain dump some like assumptions or biases I might have about the session coming up and that just gets it out of your brain So you don't need to worry about it and and while you're synthesizing you can be like, are we are we Like using confirmation bias here. Like are we are we like playing up our assumptions because they're right on the board with you um, you can also include others like Synthesizing in a vacuum on your own it has to happen sometimes but including others Helps um helps them review your insights review what you're saying and maybe challenge them, right? Um, so those are some really great ways that you can kind of like avoid confirmation bias If you are doing it on your own and you don't have a chance to like bring anybody else in which you can do You can do this whole process on your own Just assess the risk if you are wrong So assess the risk if you are using confirmation bias or like falling into that kind of pattern or falling into your assumptions and biases Um, and and what I mean by assess the risk is like really like take your take your findings Like the information that you put into those little quadrants and say look at your assumptions and say, hey Is there anything that's going on between the two? You know um, so Instead of 24 to 30 hours and I do the math It's six to seven hours. So I didn't erase synthesis for you But what I did is I greatly reduced the amount of effort and time that you need to put into your synthesis If you do this on the go. So after every session you're tagging the session Um, you are starting to write insights after the third person and you're really going going going so that at the end You've already done the work. It's like the opposite of delayed gratification It's like really being on top of it and and I promise like it might seem like oh like an extra just 20 to 30 minutes That's so annoying But trust me if you're sifting through like even just seven sessions It's going to take you a really long time because you're going to have to remember things You're going to have to go through things again And instead what you're doing is you're really just like downloading the information right away so that it is accessible to you accessible to others and inspiring people to take action Oh, thank you I hope that that was helpful um for at least some of you. Um, there are a Bunch of ways that you can reach out to me and connect with me Um, and I I would love to um hear about how this goes. Um for you as I mentioned You're going to get a bunch of these resources. I have a bunch here For you. Um, so you're going to get a bunch of these resources. Um After the after this talk, um, and I hope that they are helpful for you and really getting you started And kind of helping you with um with uh making your synthesis more efficient Hi everyone, uh, thanks. Thank you for that. I think it's a nice leading and it's always nice to uh to to balance user research and product management. So I hope I give you a different Side of this now So today I want to talk to you a little bit more about getting more from user research for time for product managers And I can uh fully empathize with this because I spent a lot of my careers feeling like a time for product manager And before we go into it, I want to tell you a little bit about me. Um, so I love board games running and rugby Two cats and a dog and I think some of you saw my cats, uh appear on the camera during Nikki's presentation and As we said the opening of this any dish from my perspective with fried loomie is going to be a winner Uh, and then at the bottom are some of the companies I've worked with in the past Um before we go in as well on delivery hero because a lot of people haven't heard of delivery hero per se Um, it's a portfolio company and it operates different local brands all around the world So the brands you may have heard of it's uh, paya, beef food, telebat, food panda, uh to name to name but a few so, um Today I talked to you a little bit more about our agenda I want to talk a little bit about lean in the context of user research really to kind of kind of build on that That lightning synthesis concept that Nikki was talking about. Um, some of the most overlooked opportunities I have tended to find as a as a product manager of what I've I've done And also what I see in our community Uh an overlooked opportunity And then I want to also give you kind of four methodologies I've done to try and get a little bit more leanness in in the way that we've done User research in the past some will work some someone but hopefully it'll just give you Some things you can add to your toolbox So, um, I kind of want to tie it to this first section setting ourselves up for success Um, and what do I mean by that? I think the first thing to say here is that we have often heard about like lead and lean discovery and lean delivery I think often we translate lean to meaning lightweight. Um, something that can do quick and easily and sometimes it is sometimes that is part of it But I also think um that this definition and full disclosure. I stole this definition from Marty Kagan um, but lean is fundamentally about tackling risks early um designing Collaboratively and not sequentially and like explain more about why I think that's so important in a moment Uh, and then just solving problems and not just shipping features So I want to keep that idea of you know lean not just being lightweight But having a kind of a more overarching vision behind it as we go through this So I've always thought a product development is about building the right things fast Now I feel like that's one of those things It's a very simple statement which masks a lot of complexity, right? How do you decide what are the right things? Uh, and how do we move fast against them as a as a product development team? And for me, this has always been kind of the the key question, right? You can optimize um for Let's say speed or quality and how do we as a product development team? How do we optimize for both? And I think one of the most Overlooked things and I say this as someone that was guilty of this for a large part of my career Um on the most overlooked things is not involving Um enough of the team in the process of discovery Um, and I will I'm going to go out there and say you'll be leaner as a team if you involve everyone in the discovery process I want to talk a little bit more about why? Uh, why that was my key learning kind of like the the the moments that I've had that kind of got me to this conclusion so The headline of this talk was kind of you're getting more from user research for time poor product managers And then my question I guess to us is like why are we time poor? What is it about the way that we're working that makes us feel time poor and that we have to look for the lightweight opportunities and those there's quick responsive to things And generally in my experience, it's because we built ourselves into a bottleneck situation um often with a focal point for the team Um, and and it feels like lots of things have to travel through us for you know our input or our guide advice In some cases our approval and sometimes that's okay. I sometimes it's absolutely a part of our job I'm not trying to say that teams shouldn't have product managers or product owners But often I think we over index and a lot of the community a lot Sorry a lot of the The conversation the community and historically has been about you know protect the team, you know Protect their capacity protect their focus. I think it's true in it and it comes from a good place But what I think is lots of the times that we over index too far and what we go We go from protecting the team and you know protecting their the ability to focus To siloing the team and keeping them away from the the context of why we're building things and what we're building them for And and then the problem with the product manager bottleneck is ultimately it's going to slow down the team's pace of delivery of value And I'll explain a little bit more about why I think that's the case in a moment Um fun fact the undermines the autonomy of the team I would tend to find that most of the colleagues that I work with be they Developers be the analysts be designers be they quick qa be they my business partners They're not just there to build the thing if you tell them we'll do the analysis Like the very clever individuals don't have a stake in interest in what we're doing And giving them the context Particularly to help make informed decisions both in terms of what we build and how we build it I think that's really key and I think the product but the product manager bottleneck is a really undermining fact And so this is a visual that you may have seen before It comes via John Cutler here. I'm a huge fan of and and the amplitude organization And he has this visualization of the product development process And he kind of it's sympathizing quite a lot and says listen It goes all the way through from opportunity selection Through to you know running the thing in in production And he says, you know, there's this evolution over time and the the more cross-function the more collaborative your workflow is The healthy you become until hopefully we reach that um that ideal state of a product team Yeah fully cross-functional we start work and finish work together. Uh, and we reduce those number of handoffs Um, this is this is the thing that comes up in quite a few kind of areas and it's something I've seen in in In the reality of the situation is like every single one of those handovers Becomes a pain point for you or the team And I think when we hand over anything every time we do that we lose some part of context We lose some part of the clarity and kind of time is back to user research user research is In in various guys is about understanding the context of a problem or the context of a solution Right and every time that we filter that out or it passes through another handoff We lose some of that context and it diminishes at each step Okay, and I think this on the on the right this I found a video on LinkedIn today And I thought it was absolutely incredible and like I've seen this happen right We go through different phrases like we let the user research go away and get this in the insights And they do a synthesis and hand it over to the product manager the product manager again Then obviously misses a load of the context passes over the developers and like what we end up shipping because we've just We're just doing handover between groups of humans We lose that context and I tend to find that the the more you can do to shorten that the better I think the other example if you ever as a kid Play this game of telephone where someone will tell you something and then they have to tell the next person And after five or six loops you find out what you know what message is there It's going to be very different and I think it's the same in product development every step in the process Every time you're taking one step away from the context of what you're trying to solve for Makes it really hard to understand that problem if you don't understand the problem properly It's really hard to solve into that problem So what I want to say here is I think your value as a product manager Comes from acting as a knowledge facilitator not as a knowledge controller And I don't think people do this militiously That's certainly not my belief behind this But sometimes as product managers, we like to solve problems and I saw this comment come up in the chat a few times Like how would you stop product managers jumping straight to the solution or trying to solve every problem? I was like you don't need to and this this can take us a time It takes us time to kind of get comfortable with this But really your job is to create an environment where your team can solve every problem and that really comes down to context um And sharing this kind of so going back to this and kind of what john culter was talking about here Was by bringing those humans in your team And outside of your team to be fair into the process You're reducing these number of gray arrows these external handoffs or even internal handoffs Which also introduced this level of friction But the more you can get everybody in the same page the more autonomous that they can be Right, and there's another great marty cagan quote If you're just using your engineers to code you're only getting about half their value I think this is just as true when we talk about our analytics colleagues our qa colleagues our business partners, right? Our stakeholders view on the problem that um I tend to find that the more you can bring these humans together in a cohesive nature That's what a really cross-functional collaborative team should be It's not just about having all the humans in terms of all the skills But it's also making sure all those skills have the context of the business or customer problems that we're trying to solve um So the problem bottleneck the ideal situation is you want to make sure that your teams have the context By which to make good decisions um So your teams can respond to obstacles questions blockers without Your input necessarily and i've seen this a few times that we tried really hard at hella fresh To do this where are Those are the team that wanted to be involved in the the the context and use the research. Sorry the cats are moving Oh dear Sorry about that. Um Who wanted to be involved in this process could do and we actually had a very high level engagement There were some engineers that were like, no, I just want to create want to build some awesome technology That's fine But we found that the majority of our colleagues engineering design And our business partners wanted to be involved in this and I remember A certain situation that came out of this and so we continued discovery in various guises and then we had different things going on at the same time And came to one day and this designer and a front end developer said, hey, we remember some research a while ago that We struggle with customers In terms of how they perceive the pricing appellate fresh that people cancel and sell discount on their account So we've decided to who wants to do this experiment around how we communicate discount pricing Related to a a different Product we were working on at the same time So we had the core designs and the iterated them on the fly to support this and to me If we hadn't involved all these humans in all the different types of research They wouldn't have had those building blocks They wouldn't be able to make those connected tissues to operate autonomously So when I when I go back to the idea of why are we times star p.m It's because people feel that we need to be there to approve because they don't have the context They don't they don't have enough information to make a decision and generally speaking connecting this back to user research That is so key for for building that up So that's my main thing to you and these are just some pictures of like work drops that we've done This was from a lunch listen and learn And so this was to do with listening to customer cancellation calls at hella fresh And so we'd go through would be doing and kind of a little bit To I think as well so what came up in some of the chats that I was like we were as we went through the calls We would take posting notes and then we would do groupings after every several calls And in this room you've got some back and developers web developers product analysts business partners Stakeholders product managers from different teams to try and help us with our own team biases And and we we did this time and time again in different contexts again These were all kind of lightning synthesis But what that meant there was every single member of that product team And I'm saying the product team here is a collection of all the humans not just people with Product in that title. Um, they had the context for the problems they were solving Um, so with that more Conceptual starting point, um, which I hope was it was interesting. I want to give you Some tips for your toolbox and four things that I've always found really helpful in a way I've just been a bit going back to the lean come in terms of just being lightweight That helps us de-risk in a little bit and move collaboratively Here are some of kind of my four favorite ones that we we can do Okay, so this one is a little bit heavier. I will I'll admit this is I start with the heaviest one first Um, but this is a fascinating approach So so what the store which basically you give your live product to your customer And you let them walk you through typically how you use it. Um, it's very generative very open You're not necessarily asking to do task completion or measure and get anything like that But you just want to see and hear about how your customers talk about your the product And one of the best things I ever did to this was make sure that the engineers were there And I remember in one the customers stumbled across a bug Um, and the the the product designer who was conducting the interview at the time was like, oh, sorry about that They refreshed it and it all went went normal But then one of the develop one of the front end developers was in that call and I looked over he was he was taking notes And he switched over and actually started fixing the bug because he never he didn't he didn't hadn't seen that context And he built a lot more empathy with the users So just seeing customers and how they use the product again were were closing the number of um Number of jumps between the the problem space in the context and what they're doing I thought that was just a great moment. Um, also I think I think it was And in the chat that was talking about this in terms of while you're going through these kind of interviews or whatever Um about making notes live we would do that often a google document We have two or three of us going a bit of a primary note taker who was actually good at it And then we'd be adding our thoughts as we went along wasn't necessarily tagging But it was definitely adding thoughts in a collaborative way Um the second one, um everyone kind of likes the idea of this at service level and then he's kind of terrified it terrified about it But this was something they did at Stripe for A lot of their early years in the organizations that all new joiners were required to spend time doing customer support tickets Or all work and so they understood their product and they understood the challenges that their that their users were facing And then Stripe is incredibly user-centric Company Taking the time with your team to go away and do customer support tickets will generally build a high degree of empathy with your colleagues in customer support very very quickly Um, but it also helps you as a team get closer. And I think I remember for a long time We always used to have these reports on ticket volume ticket volume for Different, you know contact reasons those contact reasons have a lot more Uh color to them shall we say once you've handled the ticket yourself, you know 10% of customers are canceling because they couldn't manage their subscription or couldn't when you actually talk to customers You go back to niki's uh point you you pick out a lot more patterns I think it's a degree of empathy there. I'm not saying that you then immediately build a You handle five tickets and you resolve those five problems. I'm not saying that you have to go away It's a a group deeply from being those insights together But again, it builds a lot of empathy and you can do that and you're probably thinking Well, how does how how is handling customer support tickets lean? And again, it comes back this fundamental principle is like How can you share as much context as possible with your team? How do you shorten those feedback loops between where the problem space is With your users with your customers with your business And and to the teams that be able to solve it So if you're spending less time having to explain this again and again or We present it or rework because you've not solved the problem that in itself is a more lean model to approach these Um, this one is my favorite for me. It was always thrown my mom Uh, particularly when I was at hella fresh because my mom was a hella fresh user Um, and I would speak to people who use the product and I would send them prototypes and mock-ups and you get Fascinating insights. My my favorite one I ever had from my mom was she I sent it with her The the the markup and she asked me a question. She was like, but I don't I don't understand what that letter Q is for I was like What would you mean the letter Q? What are you going about and what she was talking about? She's talking about the search icon and it was a search icon that I'm pretty sure everyone in this call Can identify the search icon has been a circle with a line in it, right? As it is meant to mean a magnifying glass my mom thought it was the letter Q Now I'm not saying again that every customer didn't fall into that trap But it was it was an interesting way to do a little more kind of Gorilla type research So if you're you know, if you're on a small team or you don't have dedicated user researchers You can do these small more informal things You need to be conscious that they are informal And you know, if you've not got a wonderful user researcher that's how able there to help you much like with quantitative data Uh, you can go wrong if you don't know how to use it with qualitative data You can as well But again, this is about building up context and trying to kind of compress those feedback loops that you have as a as a product team And then this is my my one of my favorite ones Nikki touched on this a little bit. She talked about her having these shorter clips Um, you can do this, you know, if you go if all of your team don't want to necessarily come and do synthesis Um as a way to kind of build empathy and shorten those feedback loops You take those key clips either from session replays or from user interviews and you play them back You watch them as a team you, you know, get some drinks and beers or whatever If you if you want to popcorn and then you can do live synthesis and live live live analysis together again You can compress a lot of the noise if you know, if you've got an interview it takes an hour For example, you can pull out some key things that people are saying and you can see with your team What you could do to respond to that and how you can move forward and again here The the tagging model that that nicky um explained earlier on in the session Was also just a really great mechanic for this So I think they're my kind of my four two of my more favorite like leaner methods that you can do to do a little bit more Like I researched but I think if there's one thing you take away from this I think involving your colleagues a lot more So you will have a lot less of a time staff pm because you can delegate you can delegate these out your team Your team is able to operate autonomously without you and you're able to kind of cut out some of those noise Or those middle meetings. It's probably the biggest thing I can I can advise and I said I know for me It was a big enabler in my career been able to move Faster as a team and as a product manager. It's also bonus tip for those of you in products and looking to progress in your career Learning those skills early will will lend you very well when you're doing the same kind of job in a product leadership role So there's my tips for you Thank you Feel free to correct on linkedin if you want to geek out about talking about product stuff I'm always happy to chat. Um, I also write very occasionally on medium and post even less occasionally on on twitter So I'll leave you that if you're only using your engineers to code if you only get about half their value