Business Analysis Fundamentals

1. Introduction: Hello there. My name is Adam. I'm a product manager and I've been in the world of product for quite some time now, has been developing products in several different industries and introducing people to the world of product down the line. It's an exciting world. And what makes it so interesting is the diversity, the knowledge that base the interactions, that feeling of completion you get with each and every new feature. So each your dream job is business analysts, product owner or product manager, but you have no idea what it's all about, then rest assured you've come to the right place. If you've already entered this magical realm of product, but you're still new to it. And you could use a gentle nudge than I am here to offer guidance with just the right amount of quality inflammation to boost your confidence, seasoned with tips and tricks as well as a couple of exercises to get that motor running. We will be speaking about product development lifecycle, and how to wrap our heads around all the questions. We will be speaking about roles and responsibilities and how to carefully choose what were wishing for. We will deep dive into framework's requirements management and refinement process back login stakeholder management, but also design thinking ways of working and self-management. And towards the end, we'll also have a taste of the skill set just as much as to figure out what it takes to get out there and don't that product. Perhaps you've already tried to digest hours and hours of videos. You must have read thousands of words trying to figure out what product management is all about. This means that you have already committed to this change. All you need to do now is take that commitment with just one step further and you have your breakthrough. And there are a lot of awesome courses out there, each of them focused on various product management topics. This however, is the one course that will introduce you to the world of product and will hold the door open for you while you get fully acquainted with the terminology and the concepts and the ways of working, you will understand what it's all about. You will no longer field puzzled or overwhelmed, and you will finally find it within your grasp to make the career change that you've always been dreaming them. I'm here to offer you a guided tour of what it means to be a product person. And for the practical exercises that we're going to go through. You will also have a taste of how it feels like to manage a product. All the way from tactics to strategy. All right, let's do this. 2. Product One-on-One: In our first session, we will be speaking about product, a one-on-one first step into the world of product. What would the product look like? The business dictionaries defined products as goods, ideas, methods, inflammation, objects or services created as a result of a process and which serve a specific need. Therefore, a product has a combination of tangible and intangible attributes. These are the benefits, the features. For example, when you want to buy a car, you might consider tangible attributes, such as its size and color, number of doors and so on. This means that you are searching for a product based on its tangible attributes. On the other hand, you might also consider intangible attributes such as price, quality, and safety test scores. So what's a product after all? Well, anything can be a product from a pen or a phone to a book, or a birthday party, or even a person I for one, became my own personal product when I switched from banking to software product development, I had to acquire new skills and also shape shift and enhance the way showcased my profile on the market. But why do you think we need product development? We needed to enhance quality and add value for the customers. We needed to improve performance and reduce cost. We need product development because continuous improvement is vital to any business. It is what's keeping us ahead of the game, are forming and providing the best customer experience. Customer centric is always a good attitude because that way we'll never lose focus from what's really important. And without customers, there is no product. So who could manage a product? Well, truth be told, anyone can manage a product and everyone involved in the product development lifecycle can certainly pitch in with ideas and feedback. But usually the person responsible for this is the product manager or product owner, depending on the organizational model. But sometimes it can be a business analyst or you can have all these roles working together throughout the product development lifecycle. Either way, if we are to speak about the person behind the role, then there's more to it than meets the eye. Catherine, former product owner, it's Shutterstock, has narrowed it down to six categories. You've got product owners obsessed with conversion rates and analytics are those who like to deep dive into user journeys and business flows. How others are addicted to social media and networking. While some of us are amazing, good building services, if data and algorithms are your thing, then you've got your special place. And you're equally special. If you're focused on mobile. Bottom line, there is no such thing as a universal product owner. If you are an employer, then it depends on what exactly is it that you're looking for. Whereas if you're the actual product owner, then you just need to pay attention to your strengths, your passions, and weaknesses, so that you go for the job that suits you best. How should we manage a product? The product owner role does sound sweet on paper and scary to. You're the king of the road on the way to production, the ultimate leader and the industry expert. But actually, being a product owner is not about being the most important voice. It's not about single-handedly generating one IDF of the other. It's not about being a designer or a programmer or all of these at once. Being a product owner is all about being the voice of the customer. It's all about facilitating teamwork, reaching the communication, leading, and guiding people along the product journey. It's about being positive and deficient. It's about making decisions on the spot with just a handful of information. All of these and much more. Here's an exercise for you. Take 15 minutes to come up with a product idea and highlight its main features. Don't over-complicate it. This is not about the idea itself. It's not supposed to be unique or a Nobel Prize runner-up for that matter. This is about setting up a starting point for all the subsequent exercises throughout the course. So we can be a smartwatch, or an app, or a toy, or a car, or a book. So basically anything, just make sure that you specify its general features. Like for instance, I want to create a smart watch for visually impaired people so they can easily access news feeds, social media content, color, inflammation, whether and public transportation in full. By the end of the course, you will have gone through all of the stages of product development. And this is your starting ground. Good luck, and see you on our next session when we will be speaking about design thinking as an awesomely creative way to design a product. Starting from empathy. 3. Design Thinking: Hi and welcome back. In this session we will be speaking about how to design things your way across. We could often use a guide, a five-step to success manifesto. And we might already have that knowledge buried deep inside under a pile of inflammation. And all we need to do is rearrange the pieces of the puzzle so that it all makes sense. So here's what's trending. Design thinking. Design thinking is a process. How to a technique and ultimately a cognitive process meant to creatively and efficiently bring a product to life. And the concept of design thinking dates back to the 1960s, and it was born as a mixture of creativity techniques and design methods such as Divergence, Convergence, prototyping, and sustainability. It's a human-centered approach, meaning that as opposed to a customer-centered approach where we speak about ease of use, improvement of flows, User-friendly interfaces. With design thinking, we speak about desires, needs, feelings, and added value. It all begins with empathy. Empathy is our capacity to reposition ourselves so that we get into the depths of what another person is experiencing. We therefore need to pay attention to what the other person says, does, thinks, and feels. While it might be fairly easy with actions and words, we do need a keen eye for detail and careful observation when it comes to thoughts and feelings. So if the product that we intend to create is a smartwatch for visually impaired people, for instance. Then we can think of our potential customers, walk a mile in their shoes and try to deep dive into their fears, frustrations and obstacles, but also their desires and their needs. We would then need to define. This is where we started working with all the information that we've gathered in the previous stage. We can therefore identify and define the problems by analyzing facts and data gathered so far. My understanding the causes and the effects by properly defining the problems and then by explaining the problems. Why do we need to explain the problems? Because that's the ultimate proof that the problems have been thoroughly understood. We can then proceed to identifying and defining the solution. And we can do so by compiling a list of possible solutions, testing the solutions and validating them, then we can comprehensively define the proper solution and assign its implementation. The third step in design thinking is about generating ideas. Thrown the table. Amy and I mean, absolutely Any idea that crosses your mind at this stage, it's all about generating ideas. It doesn't matter. It doesn't matter at all, whether it's good or bad or if it's the worst idea ever, will take care of that later. All that matters now is generating as many ideas as possible without any constraints, analysis, or comparison of any sort. So think outside the box below on ideas of others. Stay focused on the topic. And b Visual, go for wild ideas and go for quantity. Prototype is what we'll need to do next. This one is about producing the lite version of the product, one that is not very expensive. And we're in an experimental stage. The aim here is to identify the most appropriate solution. And how do we get there? Might testing and retesting by investigating, by improving and testing again and again until we have a better idea of the solution for the problem and the product alike. Testing is the final stage. There is rigorous testing going on here. And the purpose is to thoroughly test the complete product, considering the optimal solution as it was identified during the previous stage. So we test the product, we evaluate the solution, we generate new ideas, and we refine or redefine the problem. This leads to an iterative process because that's what design thinking is. You don't just put down your pencil once the tests pass. Testing, the product will teach us more about customers and it goes generate new ideas. Testing may also redefine the problem itself. So you see, this is not the end of the line. This is not just a simple five steps recipe for the perfect product. This is more than that. So here's your exercise for the day. You previously came up with a product idea. And you've also highlighted its main features. Now it's time to empathize. Think about your customers and walk a mile in their shoes, identify their pain points, their needs. You then need to define what is it that they're stumbling upon, highlight the problems and define the proper solution for each specific problem. And now come up with ideas. There's no such thing as a bad idea. So go for it and then start sorting your ideas and pinpoint the ones that best suit your purpose. Then categorize them properly, grouping them under the corresponding features that you previously identified. But let me give you an example. If I were to create a smartwatch for visually impaired people, as I said, my high-level features would be the following. News, social media, color, inflammation, weather, and public transportation. Why would I need call inflammation, for example, to be available on my braille smartwatch. Because as a customer, it would be a bit more difficult for me to just stop, possibly in the middle of a crowded sidewalk and access my phone's particular feature that would tell me just that. So this feature would enable me to access that information much more easily. Now, how exactly is that supposed to be working? Well, the following ideas might be suitable for this feature. It would display the name or the phone number of the person who's calling me. It would display options to take or reject that coal. It would display an option to call back and so on. Now some of these ideas might be good, some of them might be great, Others might be completely useless. I would sort them out later anyway. So for products I, I would only pick one or two of these ideas, then test them and analyze the results, then proceed with the process. Because as I said, design thinking is an iterative process. And that's just the beauty of it because it brings efficiency through clearly defined steps that allow us to concentrate on one thing at a time. Thus enabling us to bring out the best ideas and the best solutions, the best product for our customers needs. Good luck and see you in our next session when you'll discover that common sense should be your weapon of choice when having to choose between a wide range of frameworks and methodologies. 4. Agile & SCRUM: Hi and welcome back. In this session we will be speaking about common sense as a weapon of choice. Bland, build, test, review, deploy. This is waterfall, and it typically goes through a lengthy planning process followed by building the product and then testing the product, reviewing and eventually deploying the product. At this point, you may end up bringing the wrong product to market if the market demand or technology has changed since the original plan was developed. Some of the problems of this approach are that the planning must be done before any work begins. Then most of the times the planning is done without fully understanding the project during the development stages, often things gets sent back to the development phase, in which case, either the project needs to start over or developers are criticized for not understanding the plan and so on. So lots of back stepping and doing over. This means a very long time before you can get the product out the door. With Scrum. On the other hand, the process is broken up into smaller pieces. First, we do just enough blinding to get started with building the minimum feature set. We then build what was planned. We test, review and get it ready to be released. When that cycle is complete, we end up with a potentially shippable product. This process is repeated time and time again within a timeframe of one to three weeks. And the process is repeated yet again and again. You therefore end up with incremental release cycles called sprints. Sometimes you may end up shipping your product after the second sprint or the third, or the fourth, or later on. But you eventually end up shipping the product of the values and the principles of Agile software development are comprised in a so-called manifesto. Here it goes, individuals and interactions over processes and tools. This means bridging that communication through any means necessary is more important than following a specific procedure. Step-by-step times change. People change the ways we interact change. So keep up and adapt working software over comprehensive documentation. What this means is that it works on my machine has never been good enough. We may have the most exquisite integration guide, but it's all for nothing. If the API call gets a return to sender, customer collaboration over contract negotiation, everyone needs the safety net. We all have one in place, but still we don't leave down there. We worked together, we communicate, we get the message across the table accurately and in a timely manner. Even if sometimes the wind blows the safety net a bit to the side, responding to change over following a plan. I for one, consider this to be at the heart of the agile mindset. You build a plan and then something happens and the project is in danger. What do you do? What matters most to you at this point? I would say that it's in everyone's best interest to refrain, to adapt, to adjust the plan so that it accommodates the change. Keep the end goal in sight and be Agile. In Agile Scrum, there are three key roles that are needed for the framework to work well. The product owner is the person responsible for defining the features that are needed for the product. The scrum master is a servant leader to the team, responsible for protecting the team and the process, running the meetings, and keeping things going. The team can be made up of developers, testers, riders, anyone else that helps building the product. All of these people work and work together to get the product out the door. There are also three artifacts or documents, let's say, that are used in Agile Scrum, the product backlog. This is where the product owners create a prioritized list of features known as user stories that could go into the product. This least evolves and changes priority with every sprint. Then we have the user stories, which are a way of describing the feature set. They are usually written in such a way that they make sense to anyone who would read them. As a customer. I need something. So that, and here we have the purpose. The reason why this way of phrasing the user's story allows the product owner to specify the right amount of details for the team to be able to estimate the size of the task. The highest priority user stories go into the sprint backlog. These get estimated for size and are committed to for the next sprint. Last but not least, we have the burndown charts that show the progress during the sprint and the completion of tasks on the sprint backlog. These charts should approach 0 points as the work is being completed. We also have a couple of ceremonies that make up Scrum. We have this print refinement session, which is where the product owner, scrum master and team meet to discuss the user stories and estimate their relative sizes. This usually happens once or twice per sprint. Depending on the necessities. Sprint planning is what happens once per sprint at the beginning of it. And it is when the product owner, scrum master, and the team, they all need to review the user stories, such as they were previously estimated and arranged in the sprint backlog by the product owner according to their priority. The daily scrum is a brief standup meeting where the team discusses what they have completed since the previous meeting, what they're working on, and anything that might be blocked or require resistance. And then we have this print preview and retrospective, which occur at the end of the sprint. This is where the team demonstrates the completed work to the product owner and to various stakeholders. And then the team discusses what they can do to improve the process going forward. It can be done as one, but usually people would rather have them as two completely separate meetings. And I couldn't agree more because it allows you to concentrate on one thing at a time. Besides other stakeholders might join the demo session. Whereas the retrospective is just for the team. But Agile is more than just a framework. It is a state of mind. It's not only about removing impediments, but it's also about teaching and mentoring. It's not only about facilitation, but also about coaching. So you see there's a lot more to being agile than simply following a specific set of rules. No matter the role you have in the product management universe, it will be good for you to embrace agility in all of its forms. Your only endangered of becoming a better professional. There, a colleague, a better person. And since we've been speaking about this crumb approach as part of these Agile universe. I trust this is as good a time as any to mention that there is no such thing as a perfect framework. There is no standardized metrics suitable for every business, for every need, for every team. So do customize, do evolve, and grow up and reach towards the maturity of your organization. But do that your way. Find your own path. Follow your own natural course. Good luck and see you on our next session when we will be speaking about requirements management. 5. Requirements management: Hi and welcome back. In this session we will be speaking about requirements management. So what is requirements management all about? Well, first of all, it's about gathering information. How? Well you can do that several different ways, depending on the context. You can analyze documents. You can organize a focus group, or you can interview people, brainstorming workshops or reverse engineering. Or you can set up a survey. These are just a couple of commonly used techniques for gathering requirements. So whatever suits you best and you may combine them according to your needs. There is no special recipe, but keep in mind that the main purpose here is to clearly understand the requirements. Remember that with design thinking, we had to explain the problems to someone once we've identified them as an ultimate proof of the fact that the problems haven't been thoroughly understood. Well, this is pretty similar because we learned in our previous sessions that during the refinement meeting, the product owner explains the requirements of each and every user story so that the team members can understand the business need, estimate the effort required to fulfill that need, and raise questions. If anything is unclear, that the product owner can either answer on the spot or take that as an action point and come back with clarifications to the team so that they can estimate the willingness, the desire to quickly and thoroughly understand a specific business or a specific business situation is known as business acumen. What this means is that one also needs to understand the context that risks the opportunities, basically, everything that's related to the subject, thus turning oneself into a subject matter expert. Such a product owner is a valuable asset to any Agile organization. And since I've mentioned the risks, they need to be identified right from the start. When a project is initiated. Risks are furthermore identified, then assessed and incorporated during the planning phase of the project. They are controlled all along the execution stages and reviewed when closing the project. Please keep in mind that when assessing the risk, we need to identify the risk owner, the likelihood. Meaning, how likely is it that what is marked as a risk will indeed happen? The severity of the impact and the mitigation solutions. When he's speaking about requirements, we also need to emphasize on how these requirements yet to be presented to the team, uses stories, that is the naming convention. User stories are basically the middle grounding between the business stakeholders and the team, between the commercial need and it's technical fulfillment. User stories are the language that the product owner uses to bridge the communication and translate the information from one side to the other. And what makes a good story. That good scenario or two. Because if you'll go down the road of behavior-driven development, which I wouldn't hesitate to recommend. And then as a product owner, you will need to split each user story into multiple scenarios. Why? Because these scenarios will then be extended and turned into automated tests, which will help writing the actual code. The behavior of the functionalities, the main idea when it comes to be DDS, it is customer-centered. Therefore, it is much easier for both developers and testers to walk in customer's shoes. The scenarios are written in an easily readable language. Says the scenarios are written as such. They can be easily understood by all stakeholders. This method also reduces the risk of ending up with a piece of functionality that does not pass the UAT user acceptance testing. As for the acceptance criteria efficiency, we've learned in a previous session that it needs to have a clear title and to begin with a specific structure to define its purpose. As a customer, I need something so that whatever the reason may be. But then we also need to build the scenarios that I was speaking about. The scenarios follow a specific structure as well. First of all, each scenario also has its own title to define exactly what needs to get done for that particular piece of implementation. Then it also has a specific structure given, which is the prerequisite, when, which is the trigger, and then which is the expected behavior. Today, I have another exercise for you. By now you already have a list of high-level features for your product, but you also have a list of ideas grouped under each corresponding feature. These will be your user stories. Here's what I want you to do. First of all, prioritize your high-level features. And then big idea at a time and define the user stories. And these should each have a title and the following structure as a i1. And so that And last but not least, start writing the full acceptance criteria for your user stories using the behavior-driven development model. This means that each user story will have at least one scenario following the given when then structure. Let me give you an example. I previously said that I would build a smartwatch for visually impaired people. And one of my high-level features would be color inflammation. So I came up with a couple of ideas about how exactly it is supposed to be working. One of the ideas that I consider viable is the fact that once I receive a phone call, the smartwatch will display the name of the color. So here's how my user story would look like. The title would be, display the name of the color. When a phone call is received, then the structure would be, as a customer, I want to know the name of the person who's calling me so that I can decide whether to take that coal or not. Now the first scenario would it be entitled display color name and the structure of the first scenario would be, given that the smartwatch is paired with a phone when a phone call is received. And then the smartwatch displays the name of the color. This is the happy case scenario. We also need to write a scenario for when there's no store the information about the color. This would be our second scenario entitled display phone number if name is unavailable. And the structure would be given that the smartwatch is paired with a phone. When a phone call is received and color and aim is unavailable, then display phone number instead. So you can see that the given is the prerequisite. The when is the trigger, while then is the expected result. We will deal with the option of taking or rejecting the call in a completely separate user story. Because user stories must be small and deliverable in one sprint. And the team will then pick up your scenarios, extend them if needed, and build the automated tests and so on. But the idea is that the user stories that are structured this way, they sound like stories with actual words, sentences in plain English. And that makes them much more easy to understand for both business and technical people. And good luck. And see you in our next session when we will be speaking about the refinement process. 6. Refinement process: Hi and welcome back. In this session we will be speaking about the refinement process. Story mapping. It consists of ordering user stories along two independent dimensions. The map arranges user activities along the horizontal axis in rough order of priority or the order in which you would describe activities to explain the behavior of the system. And on the vertical axis, it represents increasing sophistication of the implementation. Given a story maps so arranged, the first horizontal row represents a bare-bones but usable version of the product. Working through successive rows brings additional functionality to the product. So we previously had that stage when we came up with ideas that were eventually turned into user stories. This map is made of the same exact ideas. And we should build a map before going any deeper into defining the actual acceptance criteria of the user stories. Why? Because as we go along and build the map, we may also define a new user stories or redefine some that were already created. So in order to avoid throw-away work and to allow us to concentrate on what's really important at each stage. First of all, we need to build the map. Once the map is finalized, we add all of the items to the Product Backlog, which is basically an ordered list of everything that is known to be needed for the product. It is the single source of truth for the requirements. And the product owner is usually the one responsible for the product backlog, including its content availability and ordering. Once we have all the items arranged and prioritized in the product backlog, we need to set up refinement sessions. These are the meetings where the product owner presents the business requirements and the team answers all the questions, takes action points to come back with answers if needed, and get estimates from the team. The user stories are estimated according to their complexity and they are usually estimated in story points. When we have a new team, we usually pick a baseline one user story that's been worked on by that team. And it's estimation will serve as a reference. It has to be a median size one, usually estimated a three story points so that if will have less complex ones, we can go as low as two or one story point. Whereas if we have more complex ones, we can go as high as five or eight story points, 13 story points or larger uses stories must be avoided because usually they are not deliverable in one single two weeks sprint. Then as time passes by, the team evolves, baseline may change the user story that used to be worth three-story points, maybe evaluated at one story point after a couple of months of working together. This is the exact same reason why the estimations provided by one team cannot be compared to the estimations of any other team. So you see, Planning Poker is a technique for estimating, mostly used to estimate complexity or relative size of development goals. In planning poker, the members of the group make estimates by blame numbered cards face down on the table instead of speaking them out loud. The numbers are part of the Fibonacci sequence. We usually use 1, 2, 3, 5, 8, and 13. Worst-case scenario. Anything larger than that, must definitely be broken into smaller pieces of requirements. So the cards are then reviewed and the estimates are discussed. By hiding the figures away, each individual in the group will use her or his best judgment to assess the requirements without being influenced by any other team member. One very important aspect is that the user stories must be clearly understood before their estimated. Therefore, if there are any outstanding questions, that team will not estimate. This is because most likely the answer they're expecting my severely impact the estimation. And also, if we have big differences between the estimations, meaning some of the team members gave and estimation of three, and others give an estimation of eight. We must carry out some discussions to understand why the big difference. Maybe some of the members are new to the team. So their degree of uncertainty is higher. Or maybe there's something that was misunderstood. And by discussing all of these aspects that led to that estimation, we have a chance at reaching some common ground. So basically provides similar estimations. But estimating and committing to a specific user story does not mean we're there yet in the Agile world. And just as in any other world, setting up the right expectations is of utmost importance. In order to do that, with regards to the user stories, we must define the definition of ready and the definition of done. The definition of ready is a list compiled by the team. A list which contains the criteria that an user story must meet in order to be taken into the sprint and committed four. This means that if any of the conditions specified in the Middle East are not fulfilled, then everyone is aware that the user story will not be taken in and worked on during the upcoming sprint. The definition of ready can be different from one team to another according to their experience, depending on how long they've been working together and so on. Let me give you an example of such a set of agreements. Specifications need to be clearly defined. There are no blocked user stories. There are no dependencies between users stories or a third party dependencies. Estimation does not exceed 13 story points. Designs and translations are ready and available if applicable. A similar set of agreements is defined to establish when a user story can be considered done and can it be closed? Here's an example. All tests have passed. Code has been reviewed, the documentation has been updated, and the acceptance criteria was met. And of course, user acceptance testing has been performed, or UAT, as it is most commonly known. And therefore the user's story was accepted by the product owner. And since we've mentioned the UAT, and that is the final stage when the product owner checks that the requirement, the feature was implemented as requested and as described in the acceptance criteria. The UAT fails, then the product owner refuses to accept the user story and the feature goes back into development in order to update the code and tests if needed, so that the acceptance criteria is met. So as you can see, the product owner has a great deal of responsibility when defining the acceptance criteria. And it must be done appropriately from the beginning. Otherwise, time and money will be lost, while the frustration will easily make its way in and hijack the harmony within the team. So here's an exercise for the day. On our previous session, you've defined a set of user stories. Now it's time to start estimating. Use your best judgment to estimate each and every of those user stories. And to do so, think in terms of complexity. For example, when ideating about my own product, the smartwatch for visually impaired people, I said that some of the functionalities would be display the name or the phone number of the person who's calling me, display weather information, displayed public transportation info. So the first one should be fairly straightforward. I'd say somewhere around five story points to display weather information that would perhaps involve a third party provider integration. Not really sure about that. So I would either estimated at 13 story points because the degree of uncertainty is much higher, or I'd put in a five story points spike first. That would mean a time-boxed investigation to identify the most appropriate technical approach. And the spike would be followed by the actual implementation story, which would most definitely have a much more accurate estimation. As for the public transport information, that would definitely be an aid or 13 story points item. Think about location, real time data and certifications and so on. Perhaps this one would be worth splitting into multiple smaller items so that each of them can be delivered within a single sprint. So go ahead, start estimating. And good luck. See you in our next session when we will be speaking about the backlog management. 7. Backlog management: Hi and welcome back. In this session we will be speaking about backlog management. We spoken or previous sessions about backlog and what it means. So we have product backlog, sprint backlog, items that are clear and have a high priority. They're the first ones to make it from the product backlog to the sprint backlog. So they can be worked on. An item is prioritized against others depending on its business value. And its business value is usually related to how much money it will bring and how soon after the release. But it's also valuable to business to not lose your license for an instance. So you see business value is determined through an educated reasoning and considers aspects such as cost versus benefit, time-to-market, legal bindings or compliance regulations and so on. But a decision must be made. And once the decision has been made to prioritize, we then have a structure. High priority items will have detailed requirements and will be closer to the sprint backlog funnel. The low priority items will have fuzzy and high-level requirements and will be way back in the product backlog. Still at the core of our decision to prioritize, there is always the customer and his or her needs. That is the most important aspect. And only if we get past that stage can we think about how much money it will bring? Where if the competition is forcing us to move on with it. The decision to prioritize may also be influenced by our relationship with our partners, or last but not least, by the risks it holds, but risks must also be incorporated when planning. Therefore, risk mitigation in Scrum involves flexibility of adding or modifying requirements are regular feedback and transparency, which ensures setting a high degree of awareness and also setting up the right expectations not dimension, an iterative delivery approach which reduces investment risk, risk management in Scrum, on the other hand, involves identifying the risk, analyzing the severity of impact, prioritizing risks based on exposure, creating action plans and monitoring accompanied by follow-up to ensure risk mitigation. There is, however, a different type of risk that comes with each and every line of code. When a change is started on a code base, there's often the need to make other coordinated changes at the same time in other parts of the code base, the required changes that are not completed are considered that that must be paid at some point in the future. So in order for the team to be able to maintain a consistent level of quality and release. After release, we need to make sure that we can ship clean and tidy features. Here's what you can do to ensure such a high level of quality. You can redefine the definition of done. Agile teams defined done as you're ready to release, which means that developers won't start working on a new story until this current item is practically in customers hands. To speed things along the use techniques like feature branching workflow, it's automated testing and continuous integration throughout the development lifecycle. Preventing technical debt is what allows development to be agile in the long run as well. The master branch with a code-based sets should always be ready to ship. That's priority number one, the product owner is empowered to focus the team of the most valuable work first, rather reducing the scope of the release than compromising on quality. Technical debt is the difference between what was promised in what was actually delivered. You can prioritize technical debt and the sprint planning just like a normal feature work. And let's educate ourselves on the true costs of technical debt. Since we've learned a thing or two about backlog management and since we already have all that we need from our previous sessions, Let's make today's exercise about organizing or backlog. We already have our features and the user stories underneath, right? And we've also estimated each and every one of them. So now let's just arrange all of these items on the board according to their business value. Once you have that in place, you should also define your MVP, meaning your minimum viable product, which is in fact a core set of functionalities that you can confidently place in front of the customer. All that's left aside, decoupled from the MVB that can be grouped in a subsequent phase. That this way you bring something to the customer in a short amount of time. You can then build on what you already have in production. The customers are excited by every new feature that you add to the product. Not to mention that you also improve your customer retention rates. So go plan, prioritize, and define your MVP and good luck, and see you in our next session when we will be speaking about stakeholder management. 8. Stakeholder management: Hi and welcome back. In this session, we will be speaking about stakeholder management. What is a stakeholder and who can be won? A stakeholder is either an individual, a group, or an organization who is impacted by the outcome of a project. A stakeholder can also be anyone who can impact the project itself. Stakeholders have an interest in the success of the project and can be either from within or from the outside of the organization that is sponsoring the project. Stakeholders can have a positive or a negative influence on the project. We can split them into four different categories. At the core, we have the sponsors or the owners of the requirement. They are the ones who ultimately carry the responsibility for the success of the project. In the wider circle, we then have the development team, the ones who come up with the technical solution and who makes sure that the implementation is properly performed. If we go one step further in the third circle, we will find the reference group, people who ensure that everything works properly, that nothing else has been impacted by the change. Or if it has, they make sure everything is aligned. And in the last circle of your stakeholder map, you'll find your customers, the end users of your product. There are the beneficiaries of all the effort that's been put into the product development process. We can also map our stakeholders using a two-axis table. Our vertical axis being the one illustrating the power of the stakeholders. While the horizontal axis will stand for their level of interest. So what we've got to do first is identify who our stakeholders are. We then need to work out their power, their influence, and interest so that we know who we should focus on. Further on, we need to develop a good understanding of the most important stakeholders so that we know how they are likely to respond and how we can win their support. As general guidelines, we only need to monitor like leave those stakeholders who have a low level of power, but also a low level of interests. As the stakeholder interests rises, we need to keep them informed and respect their interests. When we deal with stakeholders who have a low level of interest, but they do have a powerful position within the company. Will need to keep these ones satisfied and meet their needs. The hotspot of our stakeholder map, we'll highlight those ones who are highly interested in the project and also have a great deal of power. These are the stakeholders who we need to manage closely and keeping engaged at all times when we speak about power, whether it's about a project or a personal matter, we can definitely identify several different types of power. We can have legitimate power based on one's position within the company. Or we can have Bauer based on expertise, specialist skills, or knowledge. There's then the reward based power. When one has the ability to distribute something that others value. There's also refer and bureaucratic or charismatic type of power. So you see, we do need to pay attention to actively listen and discover our stakeholders to properly identify them and approach them in a manner that best suits their needs and expectations. All of this is necessary if we wanted to make sure that we reach the desired outcome of the project. And by doing so, we're also building a relationship with our stakeholders and we're making future interactions easier, therefore, eliminating a lot of communication barriers and smoothening or road to success. So how about this For today's exercise? Think of your product, think about your stakeholders, identify them, and then perform a power versus interest analysis. And then build your own stakeholder map and position them appropriately on the map. It is a good exercise and we delete all the time with each and every new project. It helps by bringing clarity with a direct impact on communication. Because we will know who to approach when and especially how to do it so that we agree on the deliverables and ensure the success of our project. And good luck with your stakeholder mapping and see you in our next session when we will be speaking about the skill set, what it takes to be an outstanding product person, and how that will have a positive influence on your personal life as well. 9. What it takes to become a (better) Business Analyst: Hi and welcome back. In this session, we will have a taste of this skill set. What does it take to be an outstanding product person? Well, you know, just like in football or engineering or in arts, it's either you're cut out for it or you're busting your ass, learning, building on top of what you've learned and then learn some more. But ideally, it takes both talent or passion and a lot of hard work and dedication to get there. So innovate and start with yourself. Innovation is a mixture of desirability, feasibility, and viability. So as part of the innovation process, the following questions must find their answers right from the beginning. Is it real? Is there a market for this product? Is there a true need in the marketplace? Can I win? Analyze the competitive environment? Is your proposition a competitive one? Is it worth it? Do we have realistic estimates of sales and revenue? Are the product costs acceptable? Our of the development costs affordable? Well, if you've got all your answers, then you've got your heart in the right place. Now let's see what you need to do to also get your mind in the right place. And for that, let's talk about mindset. The mindset is a set of assumptions, methods, or notations held by one or more people or groups of people. Or in other words, it's the way your mind is trained to work. These the way you are used to evaluate an act or react in various circumstances, each and every moment, day after day. It's the way you see life itself. Wish. There are basically two major types of mindset. There's fixed mindset and growth mindset. And the differences between the two come to life when having to deal with challenges, obstacles, with effort or criticism, or even the success of others. So you may choose to avoid challenges or to embrace them, just as you may choose to give up when stumbling upon an obstacle or persist and find a way to overcome it. It's the same with effort. You may choose to look at it as being fruitless. Or you may choose to consider it as your path to mastery. Learn from criticism, or simply ignore it. Feel threatened by the success of others, or choose to learn a valuable lesson from it. With each and every such encounter, it is your choice, it is your vision, your present, and the future it shapes. So choose wisely, reframe, change perspective, and discover yourself and work with yourself towards a healthy mindset and the fulfilling future. Emotional self-awareness and self-management also have a huge contribution towards success in shape shifting our mindset. And this is because emotional intelligence is basically our capability to recognize our own emotions and those of others, to discern between different feelings and to label them appropriately, to use emotionally formation to guide thinking and behavior, and to manage or to adjust emotions to adapt to environments or to achieve our goals. Adaptability, for instance, is proof of an effective emotional self-management, whereas empathy is an indicator of our social awareness. If we get to coaching or mentoring than that is yet another emotional intelligence component. It's the relationship management capability that allows us to interact with a high level of professionalism and awareness. And emotional intelligence is at the heart of an ideal mind-mapping process. A process where we need to avoid blockages to capture ideas and discover insights, or to reveal patterns. But we can only do that effectively with a certain mental distance and by stopping to examine ourselves. So critically. Mind-mapping is about creativity. Planning, productivity, and effective mind-mapping process can enhance collaboration, therefore increase the benefits. Mind-mapping encourages flexibility and generates clear results. Mind maps are visually driven and enable a free flow of ideas. And last but not least, mind-mapping is fun. It doesn't even feel like working, even though the accomplishments are far beyond expectations. So it doesn't matter if you are working on developing a software product or if you're a writer, it doesn't matter if you're a parent or a teacher or a student. Whoever you are, and whatever you need, clear the clutter and start mind-mapping. I can guarantee that you will have lots of fun and you'll be amazed by the outcome. I didn't mention earlier the concept of re-framing. Well, framing is the thought process that people use to define a situation and decide how they are going to deal with it. While reframing is doing this over again in a different way. For example, deciding that a conflict can be approached in a positive way rather than a negative way. So reframing is basically seeing a specific situation from a different perspective. And that can be tremendously helpful in problem-solving, decision-making and learning. We do that all the time, for instance, in retrospective meetings. Instead of asking ourselves what went wrong in the last couple of weeks, we ask, what can we do better? What can we improve that way? We'll avoid concentrating on the negative impact and instead come up with ideas to improve. So not only does the attitude get a lot more positive, but the outcome is also a lot more useful. You can also refrain by creating a persona. Personas are fictional characters, and you usually create them based upon your research in order to represent the different types of customers that might use your service or your product. Creating personas will help you understand your customer's needs, experiences, and behaviors, and goals. So what happens is that creating personas can help you step out of yourself. It can help you recognize that different people have different needs and expectations. And it can also help you identify yourself with the customer you are designing for, or with the person in front of you when dealing with a difficult conversation. So don't forget, aim towards a healthy mindset. Educate your emotional intelligence, reframe your way through the innovation process, and use persona's to walk a mile in customer's shoes. Good news is that you've already done most of these things by now. All you need to do now is exercise. Do it all the time and you'll just find yourself one day doing it all naturally without an effort and most definitely enjoying it every step of the way. And if you're in the mood for one final exercise, I'd like to invite you to build a prototype of your product. Imagine that you are going to be selling your product in a retail store. So what you need to do is take a shoebox and design the product that your customers will buy. Right? Details and features that will help you sell the product. Cut images from newspapers, and stick them on the box. Give it your best to ensure a highly attractive product ready to be sold. And since without customers there is no product, try selling your shoebox product to someone. The selling process ensures you are focused on the benefits, whereas the limited space on the box forces prioritization of your product's features. So I do hope you won't get a tough crowd, but either way, it will be an excellent exercise. Good luck, and thanks for joining me in this wonderful journey to the world of product.