Transcription
Hi everybody. My name is Itam Ahmederos, and, um, welcome to Project Management for UX. Um, in this series of talks, we're going to reflect on the skills that designers, and I'll make the case that not just designers, but anybody who's working on a UX project, what kind of skills they need in order to be successful. Uh, but before I we go into the content of this presentation, let me introduce a little bit of myself. Um, I'm originally from Brazil, but for the last eight years, I've been living in Germany, at least at the time of this recording. Um, after spending some time in Asia. So by now, I've lived already in a couple of continents. And for the last 25 years, I've been working on with UX related projects. I started, my background is tradition is originally graphic design, but for the last 25 years, I've been doing UX. So I learned a few things about project management, not the not necessarily the easiest way, a lot of trial and error. And in this series, I'm going to be sharing some of of this knowledge with you. For the last 10 years, I've been not just working on on helping teams create experiences, but also I think about strategy and and execution of strategy. So in this series, we're gonna, we're gonna, this is part one of a five, five part series. We're gonna be talking about providing vision and direction. And if you think, if you're wondering why we structured the series this way, these are the five skills that the the Project Management Institute, or PMI, um, recommends that project managers, um, have in order to help their teams be successful. This series is by no means trying to turn you into project managers. This is just reflecting on some of the skills that I think if everybody in the team that is trying to bring a UX project to life is trying to think about, like, what do they need in order to be successful? Um, I think these are great skills. So, um, so today we're talking about providing vision and, um, and direction for teams. If you are not gonna have to, if you're not gonna be able to stay until the end, um, here is the breakdown. Here's like a very short, the too long, didn't read this video. Right? It's my experience is not for this. It's to say that it's not for the lack of ideas that teams cannot innovate. Most of the times, the teams are stuck. They're stuck with not having a shared vision around what is the project is trying to achieve. And probably even more critical is like, they don't understand what is the problem that we are trying to solve. And problems we are trying to solve here could mean many things. Like problems from, from the user side of things. After all, this is a UX, we're talking about UX here, user experience. But also from a strategy side of things, like, what are the problems we're trying to solve that generates the business impact that the company is trying to achieve? Which is, which circles back to vision, right? The other thing that hopefully by the end of this video, you're gonna understand is that vision clarifies why we're bringing a product to the market, right? What does it, what does success mean for the organization? And finally, vision not only points out to where do we want to go, but also how we're gonna get there. And that's the project management side of things, right?
So, so let's get started here. Um, this is, as I said, this is the first part of the series. Um, if you've ever been in a project that, let's say, you know that people are capable, um, everybody has a bunch of ideas, but the project doesn't seem to move on, or we seem to get stuck on, on, um, on discussing making, let's say, we could go this way or that way, add infinitum. Well, most likely is, let's say, at least in my experiences, most likely there's a possibility that there's the team lacks a vision, right? And just to quote someone that I really respect, right? I say, great vision precedes great achievement. Everything needs a compelling vision to give it direction. This is coming from, uh, John C. Maxwell, um, the, um, leadership guru, right? And here's, here's an important thing to, to think about vision, right? If a team without vision is at worst purposeless, right? Let's say we're, we're just, we're just working, we are creating stuff, but we don't have a purpose. Um, at best, and this is where things can get really tricky, is like, if the team doesn't have a vision, then the team is subject to whatever the personal agendas of the individual team members are, right? And some team members can have a selfish agenda, other team members can have a very altruistic agenda, but everyone has an agenda, and everybody is walking in the, potentially paddling in different directions, right? So, and what do I mean by vision here? Like, I think that, let's say, maybe we should spend some time talking about vision. Um, there's many layers of vision, right? There's the company vision, there's the organizational vision, there's the, the product vision. But the definition that I, I like to give is, is this one where I say, the vision is the connected, the vision is, is the source of everything that that we that will help create the strategy of the product. What are the choices that we're making? And, and here I mean, it's hard to talk, it's hard to talk about project management and making plans if we don't have a strategy, and it's hard to talk about strategy if you don't have a vision. And, and just for the sake of making this, um, try to get this as quick as possible out of the way, the strategy is about answering these six questions, right? That you've seen on, on the screen there. The questions on the left, which is, what are our aspirations? What are our challenges? What is it that we're going to focus? This is all coming from vision. The vision is about the, the, the choices that we're making of what is the future that we're trying to create? What that future is going to look like when we get there? The questions on the right, what is our guiding principles? What kind of activities that we are going to take in order to, to execute on that strategy? Um, how we're going to measure success, which is probably a very important one. This is all about the tactics, right? And I think different coaches understand what tactics mean, but tactics here is replaced with project management, right? So, mistaking, and, and I think that, here's the last thing I'll say about it, is like mistaking strategy for, for plan is a, is a very common trap, right? Let's say, a lot of people, a lot of managers, they think, let's say, here's, here's the strategy, is like, here's a list of features that we need to deliver this, this, um, this release or this year, or whatever is the financial time, like financial organizational timeline that that you have, right? Um, and it's a common trap because a lot of people, they, it's very comfortable to say, um, we have a financial target this year, so for example, end quarter, end or year-end, and we want to communicate what, what, what is the value that people are trying to deliver. It's easier to think in terms of features, right? Um, but a strategy, in my book, I mean, what I mean by book here is like, in my understanding, it's about the choices that we're making, or the choice, or the things that we do not want to do, right? So we need this strategy in order to create the plan. And the, the strategy is about the choices that we need to make in order to get where we want to be, which is the vision, right?
So, so great. If the vision is where do we want to go, why is it so important? Well, vision creates this common language that helps the team work together, right? So a product vision communicates why we're building something and what is the value proposition that the customer gets from it. Again, because not a lot of people are used to having worked on, at least in my experience, usually it's not like most of the times, most projects they say, "Hey, here's the vision of where we want to be." Um, a lot of teams actually struggle with not having a vision to begin with. So when they, it is even hard to recognize when, when, when they see one. But what we are talking about vision here is, is this idea of something that helps us guide the actions and decisions and helps promote consistency of purpose, right? Because if you say, "Oh, we want to deliver feature X, Y, and Z," there's like a million ways that these features could be executed. And, and if nobody has a good understanding of like, "Well, why do we need to deliver feature X, Y, and Z?" then, um, then the team can can be, um, kind of held hostage by the different opinions about where do we want to go, right? So going back again to, to the explanation here. So think in, when you are working with team members and, and they are stuck on, "We could go this way or that way," think about the three questions on the left, right? Say, "What is our aspirations?" Like, what, what kind of company do, do we want to become, or what kind of team do we want to become once this project is delivered, right? "What are the challenges?" To actually, that's on the way, right? Let's say, what kind of, let's say, what is our competition? How hard is it to understand, um, the problems our customers, our users, and so on? And probably even more critical is like, what is, what is it that we want to focus on, right? The, the focus thing, I think, is probably the most critical one because, as I said, in the beginning, it's not for the lack of ideas that teams cannot innovate. Sometimes, if you, if you're, if you're, if you're working with very talented, very capable people, it's the teams are probably going to have more ideas than they're actually able to implement. So the focus and priorities usually is going to give the team that sense of purpose and direction, right? So that, that we, um, that we want to get. Um, so, and here, here's what I mean by, by the vision giving direction, right? Let's say, vision being derived from strategy. Um, so if you think about the surface, um, the, the layers that we are describing here, this is coming from, uh, James Garrett, right? If you look at any given application, right? Let's say, what you see on the surface, or what you see on the screen, is, let's say, things like buttons and, and menus and dropdown, um, lists and, and so on. So this is the surface of the application, right? So this is what people interact with. But there's all these layers below. Let's say, for example, there's the information architecture, there's the, the structure of how the, the pages or modules or, or functions of the application, um, interconnect. There's the scope, right? Say, why these features are part of the application, not those features, right? Each layer depends on the layer below. And here's something that I think a lot of people don't, don't realize and they take for granted, is that there are decisions, there are things on the surface of the application that are available or not available based on decisions that you made below, right? Let's say, "Oh, why this button looks this way?" Well, because, well, there's, there's a decision three layers down that, which we've done, that kind of puts, uh, puts us in this situation, right? Um, some of these constraints should be intentional, right? Let's say, we, we want to create these choices intentionally, not be like, hostage of, let's say, "Oh, we, we made this decision, uh, at the beginning of the project, now we, we put ourselves in a corner and we now have to pursue it this way, right?"
So, good. If vision is important, [Music] then how do we, how do we get there? Well, the first question that the team needs to ask themselves is, "Is there a project vision?" Right? And here's where things get really tricky. Um, if you go around the team and ask, let's say, "What is our project vision or our product vision?" They may or may not even know what you're talking about. So this is where, I guess, you have to, to, to use these words like, try to think of synonyms that, um, that helps the team understand what do you mean in terms of, like, how useful this thing that you're asking them is, right? So, for example, if the team doesn't understand what you mean by project vision, then you can ask things like, "Good, but what, what problems are we, what problems are we solving for the customer once this, this product or project is completed?" Or, "What is our user going to be able to do after we completed this, this vision?" Right? Let's say, so you want to, you want to have this conversation that is forward-looking, right? And from a, from a strategy perspective, and I know a lot of designers, they tend to jump directly to solutions. I think, let's say, "Well, my product manager or my, my stakeholder asked me to deliver this feature, so I need to, to work on it." I, I would encourage you to also put a little bit of a business mindset on it and think about it and start challenging the team, right? Say, "Is the project a good fit to the wider goals of the organization?" "Is the vision shared across the company?" And, well, I, I guess, let's say, if you are early in your career, maybe you're a designer or, or a developer working on a Scrum team, it's not like you have a lot of influence to look at the wider goals of the organization, or is this vision shared across the company? But here's where I want to encourage you to, let's say, you might not have the level of influence, but you're, you could be the one helping people connect the dots, right? Let's say. And, and just by asking these questions, you might have people think about it. Um, and, and here's something that I think is, at least what I noticed in my career, a lot of people think, let's say, "Well, that's not my job. I just worry about my work here. My, someone asked me to create screens if you're a designer, or if you're a developer, like, someone asked me to create this, this API." And, and I think, let's say, if it's early in your career, and, and you have other things to do, and you're trying to make ends meet in the end of the month, pay your bills, I think that's fine. But, but I think in terms of helping users, let's say, putting stuff in the world that actually helps users get something done and create a, create a future where we are surrounded by things that are useful and delightful means that you cannot just see something that makes no sense, or things that you could, that you see that there's something off, or you see that the team is steering off in a different direction and not do anything about it, just sit back, it's like, "Well, that's not my problem." Right? So I really want to encourage you as, as a team member to challenge, um, your, your stakeholders and think about, "How can, how can we make this better?" Right?
So, so here's, here's what a product vision does, right? A product vision communicates why we're building something and what, uh, what the value proposition for the customer is, right? And you might have a great idea about something that you think is going to be very useful. If the customer or the end user doesn't see that way, either they're gonna buy it and they're gonna be frustrated because like, "Oh, I thought that this feature or this product or this service was going to give me this, and I don't get that," and then they return it, which is like the best-case scenario. In the worst-case scenario, is they, they talk negatively, negatively about your product or service to their friends, right? So you want to make sure that whatever is, whatever is a problem that you try to set off to solve to begin with, is something that first adds value, let's say, other people think is a good problem to solve, and they actually want this, this idea of like, desire your product is desirable, and users can connect the dots between like, what is it that you're trying to, to do as a company or a product or service, and, and they see value on that that you're trying to deliver, right? So, so I, I guess I spoke a lot about the importance. Let's get direct to it, right? So here, here is, there are many ways to write product vision statements. The one format that I like is, is this one coming from Lombardo and Company, right? Let's say, the product coming from Product Roadmaps Relaunched. Um, so usually you try to think of, let's say, take a step back and try to think, "Who's the target customer of this thing that you're trying to put in the world?" Right? Let's say, project, product, feature, or so on, right? And, and what is the identifiable problem that that person has? Right? Then obviously, you want to create a name so that we all, we always are speaking on the same language. Try to frame it in terms of a category, right? So, for example, is it a laptop? Is it an iPad? Is it a, is it a mobile phone? I say, because these kind of like, what, what I notice in that a lot of teams struggle is not having a shared language either. Like whenever we're talking about this problem we're trying to solve, we keep using different words to describe it, right? So the product category, and let's don't underestimate how useful that is. And obviously, you also want to talk about like, in the product statement, you're trying to explain upfront, what is the benefit that the product brings to the customer? I guess in this case, the, the, the value proposition. And, and here's where you come with your marketing ahead on it, it's like, "What is the reason that users will buy this?" And here is like, when you bring everything home in terms of strategy, it's like, "Why is this product different than the competitors?" Right? Because if you're just, if you're just trying to copy something, you're already behind, right? Let's say. So, for example, let's imagine that I'm just coming up with a very crazy example, right? Let's say, so Google puts a new feature in the market, and you are working, let's say, your company does something similar to what Google does. The moment that Google puts on something on the market, and you, and your strategy is to do like, feature parity with Google, then I can guarantee that you are like five years behind on, on that already, because that's how long it takes sometimes for a feature to come to market, right? So, um, the, with this, with this kind of, um, structure, this is how you're gonna put this together, right? Say, and this is where I think designers, and, and I know usually designers tend to focus on the visual design side of things or in the interface, but I, I notice that with a lot of the skills that we have in terms of facilitation and asking people questions, we can do things like, for example, using our visual thinking skills to facilitate the discussion. So instead of trying to sit down and write a product statement, you could actually have a conversation with the stakeholders and start breaking down the, the product strat, the, the product vision statement into these building blocks, right? So, so this is a template coming from, uh, Roman Pichler, where instead of sitting, try to write the statement in one go, let's break it down and facilitate the discussion. Let's say, "Can we agree on what is the target group for our vision?" Right? "What are the needs that they, that we are trying to, um, to address?" Let's say, "What are the benefits we're trying to provide?" Um, "What, and, and what is the product?" Right? Say, "What is it, what is it that differentiates the product?" "What kind of category?" And so on. And let's say, if you really want to push this really hard, then you can even think about like, "What is the business goal of of this that we're gonna address if we deliver this feature to the market?" Um, so with this, and putting this all together, this is what a product vision statement would look like, right? Let's say, so this is, this example is coming from, from Microsoft Surface. If you're not familiar with Microsoft Surface, I don't know if by the time you're watching this video, I don't know if Microsoft Surface still exists. But Microsoft Surface is a, if you first look at it, looks like a tablet. Right? But at least from a vision perspective, Microsoft sees it differently. This is the example of their vision, right? For, for a business user. So this is not a casual user, it's not a student, it's not children. It's for the business user who needs to be productive in the office and on the go. So that means it's a product that they want to use both, both stationary, like in a desktop, or on the go. That means, here's the identifiable problem. The Surface is a convertible tablet, here's the category, right? So let's say it's not just an iPad in a sense. Let's say I can convert it back to a desktop like experience, right? This is what it means, convertible tablet. And here's where, let's say, the, the product category helps different, explain to the product team, um, what the, what the product is and what the product does. And Surface is a, is a convertible tablet that is easy to carry and gives you full computing productivity, no matter where we are. Um, it's both a benefit and there's also a differentiator, right? Because differently than iPad, differently than an iPad, Surface allows full computing. So it's not a, it's not a less powerful computer. You can do it, I mean, at least in the vision of what Microsoft is trying to achieve, you can do everything that you do on a desktop, you can do it on the tab, on this convertible tablet, right? And because it is a convertible tablet, you can do this wherever, no matter where you are, right? Uh, unlike laptops, right? Surface serves your on-the-go needs without having to carry extra devices. So that means I don't need to bring a mouse, I don't need to bring a keyboard, I don't need to bring dongles. So one could argue that this is actually better than a laptop, and it's better than an iPad, right? Of course, one could argue that, say, "Well, Surface doesn't deliver in all these these these values." But that doesn't necessarily mean that the vision is not at, is not less aspirational. And so, and so a product vision statement looks forward, right? Say, so regardless if we are delivering, let's say, at any given time on the product life cycle, did we achieve our vision? Maybe not. But at least the vision is pointing to that direction, right? So the vision describes the change that users will experience when the product is deployed to the market. So this is describing what the, let's say, going back to the value proposition of the user, right? But also what the company hopes to achieve by developing, right?
So, now let's talk a little bit about the future, right? The vision doesn't need to be detailed, right? The idea here is that it lets people share a common goal, and, and have this sense of journey, right? Say, instead of like coming to work and building features every day, there's this sense of, "Once we finish this, we're gonna be in this future." Um, from a project management perspective, there is something very powerful about visions because it means that more responsibility needs to be delegated. That means that whoever is the owner of the product doesn't have to think about every detail. Let's say, "I need to write detailed specifications of everything." If I just say, "Well, what does our product vision say?" and there's this general direction of what is the future that we want to create, so that means that now the staff is empowered, um, to do their work, right? Let's see, because they know where the, what is the goal of the product, what is the direction that they're heading, so that they can steer their own raft, I guess, in the, in, in the direction of the future. And probably, I think from, uh, the user experience perspective, especially from a design perspective, it allows people to be very creative, right? Because instead of saying, "I want this feature," or "I want that feature," the people that are responsible for vision, I say, "We want to allow users to do this or that," or "This is the future we're trying to create." So it frees up the people to be more creative and think about, "Well, we could, if this is where we want to be, we could do X, Y, and Z, right?" So, so there's a couple of ways to think about that. If we're talking about future, right? Let's say, I think a lot of, a lot of teams, especially the ones that I mentioned about future, and, and designers tend to kind of be part of, of, of this struggle that I'm gonna share now, is designers tend to be very creative, and they tend to think about the future like, "Well, we could do this, this, and this." And usually teams tend to think about the future in two ways, right? One way is to look forward, right? So that means I'm here in the present, and, and once we deliver this, we're gonna be able to do this, this kind of thing, increment, or, or innovation, right? But, and, and usually this is only possible if you, if you have some sort of way to think about what are the different, different futures there is there, right? Say, so there are features that are possible, there are features that are plausible, their features that are probable. But from a vision perspective, do you want to be in the peripheral? Let's say, for us to be successful as an organization or as a product, we want to create this kind of future, right? I personally think, and if I could be very direct and upfront with you, it takes quite a lot of skill to do this kind of future scenario planning. It's a, I mean, if you're thinking about, uh, people creating public policy, or, or companies that operate at a multinational level, or if you're thinking about governments, where governments or organizations want to be, then I think you could do this kind of scenario planning. From the, for the kind of projects that we are talking about in this series here, like the UX projects, I much prefer to do something that is a lot more practical, which is thinking about, um, something that I call "walk back from the future." Right? And the, which is this other way of looking like, think about like, try to imagine that you're time traveling to the future, and then you look back and how do you got there, right? So from that perspective, then your work becomes a lot, a lot closer to, instead of being like a scenario planner and, and, and, um, and a public policy maker, you're more like a science fiction author or a futurist, right? So, and, and there are many ways that you could do this. One, one way that, um, and probably before even sure, but let's talk a little bit about this, the idea of approaching this from the future is to ensure coherence, right? Let's say, because we want, we all want to be in this future. So let's, um, so time travel to the future, look up, look, look back at how we got there. And probably the most critical thing that I think from a project management perspective is like, "What kind of decisions did we had to make in order to get to the future?" Right? So that's where the vision creates this really coherence, right? Between the goals that you have today and the goals that you have for tomorrow, right? So here's an example of something that I mean, there's many ways that you can do this walk back from the future. But I mean, going back to some of the facilitation skills that that I've been talking about, one, one way that I really like talking about it is an exercise that I call "prune the tree." And the prune the tree can go two ways, right? Let's say you, it actually works both ways. You can even start thinking about the current state and then think about like, what are the decisions, what are the branches on the tree that will give us this future state? Imagine the leaves, the, the leaves of the tree as the decisions that you're making or the features that you're delivering. But I find this becomes a lot more helpful when you think the other way around. Imagine the tree, then you have the current state, which is known, right? Let's say we know where this, this feature is, or where this project is. Imagine the future states, and we're going to talk about future, what, what do I mean by future states in a second. And then walk back from that. Let's say, what, let's say, if th, if the tree has this leaf there on the very end, how do we trace back that leaf to the, let's say, what kind of decisions we need to make in order to get to that leaf, right? So, and, and here's how, um, you, here's how you think about the future states, right? The vision is a headline to this, let's say, the, the product vision statement is this headline to this richer story about the future, right? And from now on, I'm going to, I'm going to make a case that, let's say, it's a lot easier to communicate vision through storytelling, right? So this is where our work, both as designers, but also as basically anybody in the product development organization, it's going to be a lot easier to kind of create this shared vision if you start using some storytelling devices, right? So think about where does the interaction, let's say, if you, if you think about a feature or a product or service, where does the interaction take place? What is the problem that people are facing at that time, right? What is the task? Like, what is it that people are trying to do in that context, right? Are there other people involved in, in the work, and what are they doing, right? What kind of objects or devices that they are using, and what kind of things that they are doing or the devices they're using to help solve that problem, right? So, so from that perspective, and, and I know that's going to sound, this is something that was actually when I, when I first became a designer, this was a concept that was really popular back then, which is this idea of akin product development to movie making. And I think, um, a few people like Bill Buxton was a strong proponent of this when he came up with like sketching the user experience. And somewhere that along the way, that got lost. And, and I, personally, find it very useful, and I'm going to tell you why, right now. So, for example, this is, um, if you're familiar with the, the Batman trilogy from, um, Christopher Nolan, you might recognize the scene here. This is, this is the, the, this is the script of that part of the scene where, where the Joker is presenting himself to the, to the mob bosses, and then he, he makes the trick of the, the pencil to disappear, right? When you see the movie, you see there's quite a lot of work involved to make that movie, uh, possible, right? I said cameramen, lighting, gaffers, actors, and costume designers, set designers, and so on. It will be very expensive to make all of that happen if people just show up to the set and say, "Let's figure out now what we want to do as a, as a film crew," right? Which is why in, in movie making, people put a lot of effort on thinking about what the story upfront, right? Say, "What is the future?" And, and from that perspective, the script is the akin to what is the future we're trying to create, let's say, once this movie is done, once this one, once this thing is finished, this is what the story, instead of being an experience, what's the story is going to look like, right? So there's quite a lot of information in, let's say, the story is describing what's happening on the film, right? But for the people that are gonna execute on this story, it provides a lot of input on what needs to happen, right? Say, so, for example, the Joker is going to make a pencil disappear. Oh, that means the, the people creating props are going to need a pencil, and so on. I know it sounds very simplistic, but I guess what I'm trying to say is, it becomes very easy, and probably a lot cheaper, to think about your product, instead of just jumping directly to creating screens, to think about like, "Good, but what the future, what that experience is going to look like." Um, in this case here, for example, then the next step that a lot of filmmakers do is to do the storyboarding, right? So you, you take that script, and then you think in terms of, let's say, "Goodbye, what is happening on the screen?" And now we're translating the script into something visual, and the visual is going to provide a lot of input on, let's say, what kind of camera angles we're going to need, and what kind of lighting we're going to need, what is the blocking of, like, where the characters need to be. So from that perspective, um, you could actually do the same for your product, let's say, translate the vision. You get the product statement, or sorry, the product vision statement, and then start imagining the future in terms of, let's say, you have a script, you have, um, and then you have the interaction that's happening. It's a lot cheaper to do the interaction, to think about the future in terms of storyboard than it is to actually make the screens. In this day and age, I don't know if you really need to make wireframes. Like, I saw, I saw a lot of people, I mean, in my, both when I was coming out of school, even recently, a lot of people spend a lot of time doing wireframes. Um, I think there's pros and cons of each. Doing this, but I think a storyboard, at least in terms of, let's say, what is the sequence of things that is happening, it's probably very, uh, important. Not, it doesn't have to necessarily need to, like, high-five, low-five. I guess it's in the end of the day, it's only as useful as the kind of decisions that it allows you to make. And so, and bringing this back to what we need to do here, in terms of, let's say, what this series is about, is is someone in the team should be responsible, or at least facilitate the discussions that translate product, the organizational vision into the product vision, and, and probably into a project vision, right? And if nobody feels responsible for it, it's not going to happen. It's not like it's not like a chemical process like osmosis. Someone, like these discussions need to be facilitated, like a lot of things in, in, in product development, right? So my recommendation, and this is something that, at least it's a challenge that I take in myself, is if, if nobody's doing it, well, why don't you jump in and help, right? So, and it's not just about, it's not just about, let's say, "Okay, here's a vision." What that future is going to look like from a project management perspective, it means then, "How do we get there?" And this is where some of the skills that we're going to learn in this series becomes really critical, right? So, for example, you do have like facilitation artifacts and project management artifacts that helps us not only figure out the direction that we want to go, but also how we're going to get there. And, and so, for example, user story maps, Jeff Patton, very, um, Jeff Patton created this really wonderful, um, shared understanding, um, [Music] artifacts that helps us discuss the, the, discuss the direction, not only the direction of the future, but the, the stepping stones to get there, right? So going back to, going back to vision being a narrative or storytelling, this is where story maps, and, and I don't, unfortunately, we're not gonna have time to go into the details here in this video. I'm gonna make some, um, links available, um, in the description of this video, but this is where the two things come together, I say, if you have a storyline of where do you want to go, so something like a story map kind of connects the dots, right? Let's say, because you have the story that's happening as a narrative flow, and then you have the features, like the user stories that we need to implement to, to make that happen, right? So, so let me know in the comments, um, how much of, let's say, what has been your experience of, of, of interacting with product development teams? Like, how, how often do you ever come across things like, um, um, product vision and, and story, uh, story narratives or narrative flows, right? So, and I'd love to hear, um, what has been your experience, especially if you, if you have a good example, let's say, something that you thought it was really useful, let me know in the comments, right? So, and this is it. Um, thanks for for joining this first, um, um, serie, this, this first part of the series. If you want to know more about, um, this, um, this topic, um, you, I'm gonna share some links in the description, uh, below, but you can also, uh, check out this article, "The Importance of Product Vision." And if you're interested in learning more about presentations like this, then you can always follow me on social media. So, um, so thanks again for for joining. And just a, a, a reminder again, so if you, if you want to follow me on social media, I'm, I'm actually trying to be very active. You can find, you can find me on LinkedIn and Twitter. And just a quick recap, right? Is, is not for the lack of ideas that teams cannot innovate. Most of the times, it's they lack a shared understanding of the shared vision and a shared understanding of what the problem we're trying to solve. Vision clarifies why we're bringing something to the market, and vision points not only where we want to go, but how we're going to get there. So thanks everybody. I'll see you next time.