Product Owner: Core fundamentals | Nitin Prasad | Skillshare

Playback Speed


  • 0.5x
  • 1x (Normal)
  • 1.25x
  • 1.5x
  • 2x

Watch this class and thousands more

Get unlimited access to every class
Taught by industry leaders & working professionals
Topics include illustration, design, photography, and more

Watch this class and thousands more

Get unlimited access to every class
Taught by industry leaders & working professionals
Topics include illustration, design, photography, and more

Lessons in This Class

9 Lessons (39m)
    • 1. Introduction

      1:51
    • 2. Overview

      5:04
    • 3. Product vision

      4:45
    • 4. Product Backlog & Prioritisation

      4:13
    • 5. User Stories

      5:45
    • 6. Product Roadmap

      4:27
    • 7. Stakeholder Management

      5:03
    • 8. Product Owner vs Product Manager

      4:17
    • 9. Conclusion & Summary

      3:55
  • --
  • Beginner level
  • Intermediate level
  • Advanced level
  • All levels
  • Beg/Int level
  • Int/Adv level

Community Generated

The level is determined by a majority opinion of students who have reviewed this class. The teacher's recommendation is shown until at least 5 student responses are collected.

355

Students

5

Projects

About This Class

Product Owner: Core fundamentals

Hi all! This class is for anyone who wants to understand the core fundamentals of a product owner role. I'll be using a software product and place you as a product owner in the example so you'll know exactly what the responsibilities and outputs are. 

You'll learn:

  • How to create a product vision for your team
  • How to create a product backlog and get some tips on prioritisation
  • Product backlog examples
  • Examples of user stories
  • Examples of Stakeholder management
  • Difference between a product owner and a product manager

Core topics covered:

  • Overview - [2 minutes]
  • Product Vision -  [5 minutes]                            
  • Product Backlog & prioritisation [4 minutes]
  • Product Roadmap [4 minutes]
  • User stories [4 minutes]
  • Stakeholder management [4 minutes]
  • Product owner vs product management [4 minutes]
  • Conclusion and project details [3 minutes]

I'll be solely focusing on the core fundamentals so I'll be skipping anything to do with scrum, delivery, and team aspects so we can focus on the things that matter to the role. 

It's for all levels so anyone can follow who's got a bit of knowledge in product ownership. The example makes it easy to understand. 

Meet Your Teacher

Teacher Profile Image

Nitin Prasad

Passionate about product | Product coach

Teacher

Hi all,

I'm Nitin from Auckland, New Zealand. My goal is to help at least 100,000 aspiring people to get into product management. With over 13 years of working in the IT sector here and several years with SAAS companies in NZ, I've learned a lot and I'm looking to learn even more with you all! - Please review and connect if you watch a class. - Ever grateful.

12+ Years in SAAS
Shipped products in:
- Fintech (Banking, P2P lending & Expense management)
- Retail (POS)
- Transport (Hardware and SAAS)

Qualifications:

- Masters in Commercialisation & Entrepreneurship (University of Auckland - Business School)
- Launched 2 apps (iOS & web app)

Certifications

- Certified Scrum Product Owner
- Scrum.org... See full profile

Class Ratings

Expectations Met?
  • Exceeded!
    0%
  • Yes
    0%
  • Somewhat
    0%
  • Not really
    0%
Reviews Archive

In October 2018, we updated our review system to improve the way we collect feedback. Below are the reviews written before that update.

Why Join Skillshare?

Take award-winning Skillshare Original Classes

Each class has short lessons, hands-on projects

Your membership supports Skillshare teachers

Learn From Anywhere

Take classes on the go with the Skillshare app. Stream or download to watch on the plane, the subway, or wherever you learn best.

Transcripts

1. Introduction: I run. Welcome to the product owner Core fundamentals, class with meanings and preserve. I'm really excited to take you through this in the intra. I'm gonna explain the way this course is being set out. So the first pad is overview, which is gives you a broad overview off water, part of Donald when it does and how they interact with but the company and there and then we'll move on to the responsibilities and output for the immediate team. Men will look at the responsibility now for sports organization, Um, so we'll cover the product vision that product backlog privatisation use the stories and, um, stakeholder management as well. And we'll also look at the difference between the port on a roll and the park manager wrote , because it's really good to understand how these two roles work together and fit together. And then the conclusion will review everything that we learned, and we'll talk a little bit about the project. It's always good to have a sitting, and I thought, What better than placing you as a product owner for a fictitious company called Money Bank LTD. Do you own a product which is a mobile banking APP, which has over 100,000 users available on Android Google Play store and that banking APP has account balance transaction view transfer funds between accounts and other bank accounts as the solutions. And just imagine that you have a team of engineers, three mobile engineers and a test engineer, and this is what your team looks like. Hand. This is a really good where toe picture yourself as a product owner as we move on to the second part of this class. 2. Overview: I run, Welcome to another class. So in this class we will take a broad overview of the product on a roll. In the first part, we spoke about the sitting where you was a soft report on efforts fictitious company called Money Bank LTD. With a team of engineers and a mobile banking app as a product for hunters of thousands of users. Along with the solutions mentioned here, they took it the team. So this is the most important part for the product owner because they will be spending Muslim amount of time with the team. Usually the product owner is embedded within the team, and they're sitting with them working with them on a day to day, working with them, collaborating with them and solving all the problems together. As a team, articulating the vision for the team is the most important roll for the product on it. This is setting the product direction so the team getting can get inspired by supporting the team of the product requirements is equally important in core aspect. This is writing the tickets and writing enough information for the so the team can solve the problem being the subject matter expertise tied to that as the product of Arab is required to understand the product, understand how it behaves, understand the intricacies of the product as well as potentially how they use experience should look like working with the U X team. Prioritizing product backlog is also usually important because ideas can come from within the team and outside the team. This is a key aspect of the role. A product backlog can be small or large, but the partners role here is to understand which items are more most valuable for the team to work on. Monitoring is also issued aspect to the role in this example. We've got thousands of users giving us feedback potentially on a daily basis, as well as feedback coming from other stakeholders from the company, for example, customer service department. His role is to look at the speed back to see which which feedback is valuable. Feedback is adding the most value to the product. They're often required to balance product enhancements with technical improvements. Often your team will raise high value technical improvements Partners role here is to compare between product enhancements and taking from Umbro mints and have a robust discussion with the team toe. Understand what badly the technical improvements will have on the product. This largely makes up roughly 70% off the soffit product on a rope, and some companies may be a lot less or a little bit more. But there's definitely another aspect of the role that we need to cover. The other aspect is the organization. I've listed some roles where the software product owner is most likely to be in correcting , but for example, the hitter marketing I t op si hit a product and head of customer service. So let's look at that. Collaborating with other product piers on back of atoms in dependencies are really important because your team is likely to be working on changes to your product. That may have may have dependencies and other teams ensuring that their inner conflicts with other teams. You need to work with your product piers on a day to day basis, working with I T ops and your team to coordinate releases. This is really important because you are likely to be making changes with your team to the product on a daily basis. You need to ensure that their inner conflicts with the wider business activities that are going on. Providing training is also really important as you making changes to the product you have most likely required to train customer service team so they can help out the customers as it changes are being rolled up, you may also need to provide documentation detailed documentation on these changes. Contributing to the product roadmap is also a key aspect of the role in some companies working with the product managers to understand new problems to solve and also to be involved in discovery stations, where you might be meeting customers real customers and understanding new problems which might turn up to new products. Product additions to your own product, delivering for presentations of the wider company. So working in a large company, you meaning to provide deliver presentations to the wider company on changes that didn't happen recently and where you're planning to take the re plan to move the product. Er so this is roughly 30% off the road 3. Product vision: I run. Welcome to another class. Today we'll talk about the responsibilities and output on the product vision, so have discussed your team. Now we need to give them some direction. So that's go through that on the left Here have shown that currently they've got a product without a direction. But on the right hand side, we need to start painting them culture on what the future looks like. So let's go through that again. It's important to remember sitting. It's a mobile banking app. Got a bunch of solution solutions. But that's about it. How do we go about defining your vision? So we everyone end up is a shared vision, and how we get there is by talking to your stakeholders and you team. So let's get there first. So let's talk about that first. So with your strip stakeholders in the company, so definitely be feedback an opinion. And it's important together, all of that as well. And from a team point of view, it's important to have a vision. See decision to share their thoughts as a might uncover some valuable suggestions. So then there is invalid customer feedback as well that you could incorporate into your vision and data on your current product usage. And there are rules have always be some invalid customer feedback like ideas and so additions that may not align with your own views on the vision. So here are some examples, so one is feed that could be from your customers that you know the APP doesn't load on centre phone. I'm certain cooperating system That might be an indicator, a key metric like account banned. Slow time might be taken away too long. Another one might be that your marketing goal might be. That's to get to 500,000 users, but 2020 months. Engineering vision might have some key words in there that you may 20 years, so things that help division Partick Metrics called it qualitative customer feedback. Looking at things like surveys, looking at your feedback from your ratings from the APP store, looking at the company vision statement, pulling out words that you might that might. That's why you engineering vision, marketing goals, tiger markets and some legal aspects as well. Things that don't help is definitely looking at you can put your competitors are doing because they mean they won't be aligned with your own product and your own company customers wish nous, internal ideas and metrics that may not make sense as well. So what does all of this look like? So the output is a product vision, and usually it's a concrete strategic and one that was a clear part. And as we've discussed before, we got a shared vision. We collaborated with that team and stakeholders, and it also required separation and frequent reviews. So it's on a thing that set in stone forever. Here's an example. So we've got themes. Scalability is experience, multiple platforms and innovation, and we've got a little bit of detail to explain each of those teams. As you can see, it doesn't have a timeline attached to this vision. There are different ways to represent a product vision. In this case, we've chosen not to add timelines and quote all quarters or years to it. But this amount of information it gives your team something you get inspired by, and they can see that there's growth to the app, this new things that are coming, new things that they working. They can also see where they can add value. And as we've discussed before to shared visions that they would be really invigorated to start working towards this vision and, along with the thieves, were given just a little bit more information. So, for example, in the use experience column, we've got deliver a seamless experience of customers of love. And so it's not restrictive. It gives freedom, um, as well. But in some cases, like the fight start iris app, it is restricted. And that might have come from the business to have a goal to happen iris at or from customer fever or in the innovation space. New banking features so you can keep it broad toe. Allow discussion, and you can generate this further. This is an example of a product vision. I hope you found this useful. 4. Product Backlog & Prioritisation: I run. So the next thing to talk about is the product backlog and prioritization. We've discussed your team and also discussed your team now having a product vision so they have some sort of direction and clarity. The next thing to talk about is a product backlog. So all that is is a list of items, tasks and actions that will help you achieve your vision. It's a little bit more detailed than your product vision, and it kind of goes into the descriptive things that need to be done in order to achieve you written. So here's a list of items that I have prepared for our example, and I'm also themed it and categorized it, which match our vision. So at the top of the list of the things that you want to address right away right now, today and as you go down the list at some, you will want to achieve it in a later point in time with the bottom of the list, making up the least crop prioritized items, which you address much later on. Also the top of the list of items that will have the most amount of information and as you go down the list, it'll just become less clear and we'll have less information. While this representation here is quite simple, the product backlog can actually be represented in many different ways, using many different tools. But what we're going to focus on is in future lessons is how to be actually sat defining some of the product back problems. So how do we get to this list to achieve the list? Likely? Dio We spoke about the vision we need to get to a shared back off. Shared backlog is something that's representative off your views from your team as well as from your stakeholders. So allowing you teams to add items to the backlog is really important because you'll have technical, important technical items as well as ideas. Other ideas from UT talking to different stakeholders in your business, for example, marketing, legal and Customs service, for example, allowing them to come up with ideas and sharing their thoughts on where they see the product, either from having customer feedback or, you know, for example, in marketing, having their own goals and marketing goals that they wanted that they have. It will be a really good idea on, then it really formulates a really clear picture from the company of what? For all the things that within your business, including a team that you want to have in this product back lock. So you want to get to the shared backlog. So another responsibility of a product owner is to prioritize. So we've got our product version done here. What scale, abilities, experience and a few other things. But often you'll end up making trade offs and timely decisions. So do you want to address the U X futures right off the bat versus, you know, um, scalability improvements were testing, and these kind of prioritization decisions will need to be made to meet your product vision . So there are things that items that could delay or derail the vision as well. So you might be working while you're working. Let's say on the scale ability you might find as a product owner from your customer service team that there are urgent issues and production that need to be fixed, which went to the reality rail your product mission by a couple of days, sometimes even weeks, depending on the type of feedback that you get. Uh, from, say, stakeholders as you're working on, um, achieving your ah vision. So again you need to make tradeoffs between high priority items versus things in the backlog. Quite a so. I hope they give you a sense of idea of all the responsibilities from a product back low point of view and privatization. 5. User Stories: I run back into another class. So now it's time to talk about user stories. We've got the team, and we've got a product vision, which we spoke about earlier. I have just spoken about the product backlog being a list of items being a little bit more detailed than the product vision. Now we need to go one step further and really understand how we can start defining some of these price battle of items. So one of the key responsibilities of apartness to stop defining these pork uses stories that make up these items within the product backlog. So what is it? Well, it's really just a description off the software feature or the user experience, um, to keep it really simple. And the responsibility for the product Lana is to work with the team on also independently is a product owner to fill up the description and with enough information so the team can complete or carry out the task. Oh, the product backlog about him and your assistance again will depend on your skills and experience, So if you're a technical person, you might be able to assist your team. But the technical aspects of the office off the feature. If you're not so technical. If you're from a business point of view, you can definitely had the business goals and and ex cetera. So let's go through some examples. Classic for medical use a story. There are different formats, but yeah, a scenario based given men, then there. There's a certain term for this, which is it's called gherkin one going to to detail about that. But, um, scenario based in this example. In this way, for example, so scenario the behavior that you're gonna describe, given, which is setting the context on the action and a testable outcome, along with some additional information that it might be some your ex. Some designs of a supportive data, depending on the user's story, get really such allows you to define exactly how it's gonna be have and how the tester on your team concert testing the functionality that's going to be built. So let's look at some examples. So in this example, we've spoken about were taken an item from the book part of product backlog by them, which is personalizing your account with a custom image. Now it doesn't have to be just one story sometimes if it's, ah, big enough of a functionality and definitely have multiple stories, which may form into a group called Epic. We're not gonna go into too much detail about that, but we're gonna give you a couple of examples, so you start to feel for the responsibilities of the product on a roll here. So in this case, personalizing my account with a customer image, we want the scenario to be the user clicks on the account icon button. And given that the users on account screen when they click on the account icon button did they can access the gallery from the mobile phone, let's say, to select an image, they consider it an image and sit there and Mitchell the specific account. But defining it in this way, you're giving a clear description of how the the system should behave and what the outcome will be for the user. And so the team is quite clear on I won't be building and why. And the scenario and the tester Ken's test, um, some specific floors to actually make that to test it. Let's look at another example is the access additional options from the log in screen. So let's say in the scenario, we want to build some additional options in from the logon screen. So the scenario could be that the user clicks on the menu button when they when they're on the log in screen, they click on the media button. This additional options and they conclude in a contact US button, for example, and they can get a list of all the business areas and the phone numbers. Another example, sir. Um, you know, they're really exciting to define how the you know how that what the function of people look like. And this is again, or part of the responsibility of the product owner to really start defining this and as we touched earlier rounds about having the domain knowledge and being the SME off the product . So you really understand how it works. Of course, there's, um, additional information that the product owner would need to interact with, say, the U X team dependencies. If it's with other teams, um, and further analysis or it could be no data points that need to be given, um, you know, long would they use a story? So I hope this pain to a really good picture about the importance of user stories and how it fits. Um, but the product back look part of backlog that we discussed earlier. So to wrap it up, use the stories really start to get are probably at the most detailed level, um, off the product, on a role where they're getting really deep into into the work and really signed to help the team understand the exact behavior. Now there will be a lot of technical things that doesn't need to be defined because you need to allow your team. Teoh. Um, I guess start to implement. Um, we'll get these stories to a done step on, and that's where you can rely on your engineers and your testers, but you're definitely taking them along with taking them through that journey. And you it's really important to get to this detail. 6. Product Roadmap: Hi Run. Welcome to another class. We'll talk about the product roadmap now, so it discussed the product vision with the team and having a product vision. That's great. We're just so spoken about the product backlog and how that's important and how it works. Now it's time to talk about, um, the road map and who's involved. So we couldn't talk about the hit of product here or the wider product team that you need to work with, um, to get this to done. So the responsibilities here is to work with the head of product to define division, and we spoke about division earlier, but it's really it's a collaborative effort. It's not done on your own, and most most organizations, you will have the support off more product people to kind of help you with that vision. Onda also the immediate road map, which is what we're talking about here. So when we said the initial vision Reince capability, use the experience well, that's all great, and we had, you know, the product back old items. But there's something else in between that some really needs to stop taking shape with. But it's a bit of forecasting s so we can start to see what Q one Q two. What will look like in the short term 3 to 6 months time? Because the vision really didn't have any timelines. Well, now we need to start looking at a road map, so it's quite clear I'm how some of these things will and start looking out in the short term midterm. So one of the responsibilities is to provide an apple, which is a well defined roadmap with kinda rough forecast, not deadlines. But if different forecast. And this will happen as you'll hold in a multiple stations. What product managers and senior managers and kind of start working through that vision and sat sat going here, What's what's the most priority? You know, what's the highest priority thing that we should start doing? Um, in a road map should start taking shape. Also, identifying dependency with other teams and frequent reviewable will help that as well. To I have shown an example here where we've got 2020 the whole year split up into quarters , and we've taken the themes from the vision. But what you see here is, you know, it's kind of like an extension from the vision. Right? So you've got Cuban through acute three. It's all about still scares scalability, but more about the user experience, so that vision is not being completed in one year. So it's actually take potentially quite a few years to get to that vision on. But this road map here is showing the MAWR short term goals so your team can see that OK in the next year. We're kind of working towards that vision, not completing the vision altogether, but you can see parts of it here. So in Q two, you might be working on improving menu layout in some or other screens. But then it gets a bit fuzzy right after, you know should start to get fuzzy after 3 to 6 months because obviously you want to be adaptive to the market. So hence, while there's a TBC in Q four could quite easily be a TBC for Q three as well. But in this example of just kind of defined 3/4 so now you're team can now have a product roadmap. While the vision is too important, they probably not gonna look at that on a day to day basis because, you know, that should be really in the back of their mind. Cigar? Oh, yeah. You know, if there is a cool vision, But, you know, these are the things that we're focusing on the next 3 to 6 months, because the vision will go through some federations and there might change a swell. And the road map, you know, past 36 months. Well, you know, that could change as well. But it's now citing to give a more granular view off that vision, which is what's called a product roadmap with kind of forecasts as well, not deadlines. You know, holding these deadlines to your team. It's more more about a full cast. I hope that gives you some insight into product roadmap. Um and yeah, report to the next listen. 7. Stakeholder Management: I run. Welcome to another class. We'll talk about the importance of stakeholder management. So we've just spoken about the product roadmap. Um, well, Casino. The team has a product vision, but we just spoke about how breaking that product vision into and a forecast did kind of like a product roadmap, which gives a little bit more detail, short term view that can change after 3 to 6 months, which was really important. We spoke about the product backlog in the importance of having a list of items that have prioritized and, you know. And then we spoke about how Teoh create stories that make up the part of back log in details of, You know, these stories can be tested and and your team can actually start delivering some of these features. So now we'll talk about the importance of the wider organization and stakeholder management piece, which is a really a big piece. We'll talk. A few aspects about this so in the example, have got here ahead of marketing 90 top seed Peter product and customer service. These are all kind of Kiev roles that you'll be interacting with them. The organization, as a product on it So Stakeholders. So what's the responsibility of, given the example here of, ah, customer service the responsibility here from a particular point of use to keep pain in the steam, informed of upcoming changes well in advance. So we'll talk about an example I'm certain after, but it's really important to let me know what the impact of customers, um, will be. But changes that are coming up and we're to jury questions of thing it questions from customers. So the outputs really are from soft from the product owner is to do a live demo and hands on training for bending his team. So they're really understand what changes it coming up making so they can answer questions for their customers. So let's look at an example. So let's say that were built the Apple pay product, which is, you know, which was later on down the road map. But you know that table both that impacted customers is quite high, this high risk. It's a great product feature as well, so we've also included not only been because they had a Michael Lily here was also really, uh, will be really interested because it's most likely to be a highly micro feature that could drive activity in the market. Um, so it's gonna, you know, it's gonna impact both of these teams. So outputs really here is to provide Lillian and team really good customer quotes while we were building. Maybe we're testing this. What? Some customers have already requested it. I am. So so then Lillian, the team can and that into the product briefs on the marking breeze, also to provide key selling points and the features and how easy it is to access and houses . How easy it is to actually performed the actions off this. And it's likely that you need to prepare F A Q sheet of Ben and his team. Aziz. Surely customers will have lots of questions, and they may have may have stumbled across a few issues. I'm such really clear for Ben and his team to know how the answers are some of those questions. So that outputs here, you know, I hope you got an understanding of how the puppets out, for example, like this so they'd circuits the head of marketing role and the responsibilities from product on this point of view on this role. So released to keep Lily in a team informed of upcoming changes. I'm just like what we saw grew up for their just ahead of customer service as well. But here it's a bit different because it started. If I keep benefits, sitting points, price points and customer courts and feedback. So if we can think of Lily a Zeta marketing, they're going, how can we attract more customers? Oh, there must be some really nice beaches that's coming up from the product team. Um, so let's talk to them. And that's where the connection happens. And the output it really is. Teoh give a live demo to Lillian a team, but also Dennis to give detail content on the functionality. Um, how it works. And also, you know, does it cost for a customer actually adopt a prepare or to select Apple Bail User Epple Bay ? You know, what are the selling points and key benefits and some quotes and feedback that you've got from customers already? You're looking forward to this, so that could be all used in the marketing brief, so there'll be a lot of collaboration between product owner and marketing space. So as you can understand, on the product owner. Really, You know, there is a lot of stakeholder management, and by stakeholder management it's communication. And it's about working with, um, these different roles and they're responsible. New responsibilities is really to work closely but then and toe hand off the right amount of information so that they're able to do their jobs effectively. And, um there, that's stakeholder management. So we'll see you the next class. 8. Product Owner vs Product Manager: Hi, Ron. Welcome to another class. So we'll talk about the product Ona role. This is a product manager role. So I've covered a lot in the last few classes we've spoken about. The team has spoken about the product vision and the road map also spoken about the backlog . And, you know, we've also spoken about the use of stories that make up the product backlog, and it's working about prioritization as well. I'm so you know, there are a lot of different aspects to the product on a roll on. Then we spoke about steak Golden Management. I'm just now previously, um, you know, a couple other topics that I kind of related that I may have not gone into too much detail . There's obviously team oversight, a swell as you're working on the use of stories and collaborating with your team to get these two done. Um, and obviously the roadmap InVision management So working. Teoh kind of get to that from the vision to the road map. You know, I'm working with stakeholders. So is a You know, there's quite a few responsibilities and outputs, but what then what does the product manager do? So let's look of that. So the park manager, funnily enough, you know, is actually responsible for the product vision. And while I mentioned that the product owner you know, you need to set the product vision for the team. It's true, but they need to work with the product manager really full that, um and so the product manager, apart from maintaining and creating the product vision, you know, is really looking at the problems to solve. Um, you know, running discovery sessions, and I'll cover all of us in a separate class altogether. But just to give you an idea that it's quite different to the product owner rolls of responsibilities and output. So they're looking at the problems to solve. They're also looking at commercialization. So if you can think about, you know, ALS the plans that you see on all the software you know, APS up there, you know the free to premium plans. You know, thinking about the costing and pricing in which peaches should fall into what you know. Some of that is shared with marketing. But you know, the pricing on to come up with the pricing into commercialize of which party should can be commercialized and having that thinking around that is really important and strategy to So you know, which market should we go after? You know, timing win win should be, you know, launch apple pay. You know, before you know a certain computer is going to do it etcetera and verticals. So, you know, do we do we want to create products for certain Senate industries that we're after on DSO There's a lot of different type of thinking that's involved. And you, As you can see, it's not close to the team. So the team that the product manager, it's kind of working with this pretty much everyone across the business. I'm from marketing through the, um you know, data signs through to the scrum team a little bit, um, you know, to get their ideas on the product vision, but then strategy as well. So, uh, it's it's Ah, it's a I have lost Can a skill sit and kind of role and stakeholder management that's required. Andi. I'd say the core of it is the product vision and the problems to solve, really, to come up with new new products, you know that will then be a would be able to be commercialized is probably the toughest, and I'll cover this in a separate class. But you can see how different it is Teoh product on a roll. So if you're asking yourself, will they do any of the aspects of the product owner role? The road map is probably the closest that they're kind of gonna work on. I'm definitely not the product backlog. All the user stories or training. Um, you know, while they might be some crossover in training, it's most likely gonna be that the product owner gonna owns all that, sir alos tasks. The hope that gives you a bit of an insight. Yeah, we'll see the next plus. 9. Conclusion & Summary: I run if you made it this far. Well, we've come to the conclusion and summary so well done and eso let's go through it. I'm gonna cover awful the different topics we've spoken about and give a little bit more context. So let's start off with the product vision. We spoke about how the product on it works of the product manager. Actually, the as we discussed, the product manager should own the product vision. But there is a little bit of collaborative if it here to come up with a decision for the teams that they have a direction. And we spoke about how important this is, along with the product roadmap and the product backlog items of sort of what spoke about how that's important as well, to actually achieve your vision and the prioritization and the conflicts that you have with making decisions with, you know, new stuff coming up. And so that's another responsibility as well. For the product owner spoke about the use of stories, and it's ah, you know, big output, as well as actually make up the product backlog and working with the team, Teoh really get to the detail off the woodwork back of items so that the team can actually start working on them. You're supporting them with additional information as well. And then the product road map so they can have a really good team can have really good idea what's coming up in the next three months. So it's a little bit more detail. So these are all the different things on the responsibilities and puts, and you're probably asking, Is this it? And no, there's definitely more. That's probably too big aspect today. Haven't covered to detail to detailed, which might do differently. The next class, which is, you know, the team itself. We haven't spoken about the dynamics of the team and what's involved from a software for it . I just want you to really work with the team in the nurture, the team and, you know, apart from just division sitting in the road map and put it back on Adam's ex cetera and the other specters to actually delivery, How do we actually get this out done? Get the stories done, and how do we deliver? So there are a lot of methodologies out the frameworks out there on that you can implement and use with the team to actually see get all these items to done. But what I have done is covered poor your fundamentals of a software product owner and what outputs and what responsibilities you know, that kind of attached to that role, which I hope you get a really good understanding. And we also covered how the product owner and the product manager quite different with product managers. Quite strategic. Um, and where the product Ana, is quite detailed working with the team. Didn't we also spoke about the other people in the organization that are important and hit a customer service and head of marketing and how you supporting them and what content you need to support them as well. So it's not just your team. You're also looking out a little bit wider from Daniel team, and you're working with other people in the business. And so I just wanted to say a big thank you. I hope you find this useful off post more resources in the details. And so at the end of this, I'll have a really cool kind of simple to full are, um, project where you can actually try and implement your own vision and maybe come up with your own backlog. Because if you can start to do that, you will be able to emulate what a software product on it does in the real world. Of course, you need domain knowledge. I'm so in the product project, I will try and give you some domain knowledge background and try to prepare you so that you can, you know, create a product on your eyes. I hope you find this useful. Yeah. Follow me on Twitter and you have looked at my look at my articles on Linked in and Medium . So yet all the vests and yeah, I hope you enjoyed the course.