Product Owner - Delivery fundamentals | Nitin Prasad | Skillshare

Playback Speed

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

Product Owner - Delivery fundamentals

teacher avatar Nitin Prasad, Passionate about product | Product coach

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

5 Lessons (15m)
    • 1. Introduction

    • 2. Breaking down goals & objectives

    • 3. Ready for development

    • 4. Evaluating solutions against acceptance criteria

    • 5. Summary & Example

  • --
  • 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.





About This Class

Product Owner: Delivery fundamentals

Hi all! In this class, we'll cover the delivery fundamentals. It will cover everything that a product owner needs to own and do to ensure the team can start delivering with clarity

We will cover these core topics:

  • Introduction (1 min)
  • Breaking down goals and objectives (5 mins)                           
  • Ready for development (4 mins)
  • Evaluating solutions against the criteria (2 mins)
  • Summary with an example (2 mins)

You'll learn:

  • How to define goals and objectives with clear success metrics
  • How to get ensure a user story is ready for development
  • Importance of evaluating solutions against the acceptance criteria
  • Excludes Scrum methodologies, Agile principles, and other processes.

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

Meet Your Teacher

Teacher Profile Image

Nitin Prasad

Passionate about product | Product coach


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)


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


- Certified Scrum Product Owner
- See full profile

Class Ratings

Expectations Met?
  • Exceeded!
  • Yes
  • Somewhat
  • Not really
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.


1. Introduction: I run. Welcome to another class with me. Nothing beside. So today we'll look at product on a delivery fundamentals, so class structure. So we'll spend quite a few minutes talking about defining goals and objectives and the importance of sitting out the why. Then we'll look at ready for development, and this is all around the use of stories to make sure that you get that ready for your team. Then we'll look at kind of evaluating solutions against acceptance criteria and the importance of collaboration with your UX and your team. They don't summarize with an example another example as well. So really, this class is focused on two areas. One area is the product backlog because he, you'll have, you know, smaller items and bigger goals. And but how do we take those goals and gonna make them clear and be a team? Ben. Well, look at user stories and yeah, and you know this part is all about ready for Dellape Mint and also evaluating the solutions. And I just wanted to say that I do have another class called product on a core fundamentals . It is free on school share, so it's it's about 35 minutes. A very useful. It's got a lot of good feedback. So it suggests that you kind of review that. Yeah, I'll see you in the next part. 2. Breaking down goals & objectives: I run. So now we'll look at to finding goals and objectives and how we can go about breaking larger pieces of work. So we'll have to look at our product backlog because that's where you'll have smaller items . But you also have larger objectives and goals that will be needed. Teoh be broken down into furthers music story So let's look and how epics will help with that The epics, I mean, all they are are just representing bigger champs of product backlog. Adams. So you can think of a hierarchy like this. Goals and metrics is basically is the important thing is kind of like the white. And then you kind of get getting Teoh, um, you know the criteria in detail and then the actual task to get them done. Um, but the important thing about Apex is to have goals and outcome clear goals and outcomes achievable, measurable and, you know, well defined in terms of use experience. So you know what you're going after so you can have ah, quite clear objective success metrics. So you need to know what will indicate success, um, and metrics that makes sense as well and come easy collected so, you know, kind of going off on collecting unnecessary information and specific, qualitative and quantitative results. That'll met that kind of map up to your goal, out of scope. So it's important to consent to finding in scope in our scope for the epic or the main goal abjectly that you're going for. It really makes it clear for your team on. Do you find this that as soon as you've got about to find use experience, you can stop? You know, ringfencing what you want, what score and what's kind of nice to have. So let's look at an example, So personalized accounts of taken Azan example So custom image default images, you know, couple of the stories and then some tusks. But the main goal for this is customers can personalize any banking account with their own image. That's the goal. But you may also want to see that 55% of customers would, you know, change the default image, Say, six months from launch, uh, my be a clear goal that you're after, and then, obviously you need to use the experience that covers the floor success metrics. That might be a number of things that you want to track, You know, you might want to track number of accounts with custom image. Just put some examples here. You might want to see customer rating and feedback as well. Uh, you know, total number of custom images just to that map to your goal and then out of scope. So maybe cropping off custom images is out of scope. It might be a nice to have an example here, so yeah, so that's a clear kind of example of, you know, epic and components and how you can start defining your objective. So it's really clear. Um, another example. New York. I'm in here. I've said here it's improving the existing use experience Waiting Main menu. You might be redesigning something that you might want. Oh, measure the You know, the time it takes for you to use this never get because that might be the main goal, right? And you might also want to allow customers to switch the whole menu as an A B test, to to make sure that you give your customers some options. And in the success men trick an example. Here is a number of seconds to find each function Is this in one second, for example, you know, 10%. Listen, temporary customers select old men you because you obviously don't want too many customers going back to old menu given confidence about your new design increasing NPS potentially that you might want to track as well. And out of scope might be that. Hey, we're still trying to prove this new islets Just put something together and we can come to the technical stuff if you actually go ahead with it. Um, that might be something you want to consider it. This is an example. It might not always work out like this, but this is an example. So you can't have pitfalls and issues. See this quite common in industry undefined goals. And our comes or leads to an endless and Amos iPIX epics that you know, sometimes treated as containers. Shouldn't really be containers. It should. It should have purpose, and you should know what you're targeting. You can't have multiple picks. That's fine that, you know, as long as you don't lose the why and you can't kind of unify the team toe the goal that you're going for missing success mint trick. So Yeah, common quote, if you can't measure it, can improve it. You really didn't need to know what you're measuring. So to get to your goal so you can. Once you have launched at you, you can take that measure and start making sure that you're getting to your goal aan den under find score. So you know, if you want to limit it, Teoh, you know, just a number of work on him. Still get you Get to your goal. Um, we really need Teoh. Kind of make some decisions around your in, scoping out of sculpt and to have a well defined it. So I hope this gives you a good insight into epics and, Yeah, see you in the next class. 3. Ready for development: I run, So now we'll talk about ready for development. And this is looking at the use of stories. In the previous examples, we looked at a couple of uses stories, and we discussed how it was important to have additional information like designed life frames and dependencies and further announces to make sure that the story is completely evolved, defined for your team to back up. But we never got to the detail and actually looked at a story and actually dived into it. So listen, let's do that. So refining to use story in this example of used personalizing my account. But the customer Mitch, which we've seen before, and we've looked at how to want to have a given men then, but a clear test criteria for the tester toe test you story. But they're definitely gonna be questions from your team. For example, you know what is the default image? What if customers try and upload other file formats? For example, can you use a cropped image with all these different questions and other questions will come up? Um, it's important to for as a product owner to actually start looking at them well before you get to your team and start thinking about these questions, Um, and working with the team. So let's look at that, said decision. So once these questions do come up, you need to sat recording them. So you need to work with the U X team, for example, to select a default image. And make sure, um, that the far format and restrictions US defined work with the Eurex on the user experience involved. And yet work with the immediate team tied into find gaps for you. Use the story so one sets or done, you need to record your decisions. So here, in this example here have spoken about a few different areas of in the U X. You need to record the actual details, which might be provided by the U X Team Onda recording the use the experience with prototypes and designs, inflows for use, a story and the technical aspects as well. And you you may need to discuss with the A team or if there any other questions that might be remaining fully. Use a story. You may also find that out of this you get additional use stories that you may need to refine further or you may need to add to your product backlog for later. If it's a nice to have, for example, here cropping selected image and resetting to default. So some pitfalls and issues avoid technical detail because that's your team, Really, you should be coming along toe Help use help you to understand what's required to get this to done. It's really about the criteria and acceptance criteria should be in plain English onda again. That's great for stakeholders who may read through the story so focus on the criteria and avoid the technical details. Collaboration is keep so reaching to mutual agreement, mutual agreement. But the criteria scope anticipate scenario with your team will really determine the success because it's clear if it's testable and there's the Scorpios will set out. Then there's this chance of any bugs and issues that come out of it testable and achievable . So collaborated with your test engineer inch Alexei sees feasible and you know it's not a bloated and it's not going off track. And I'm sorry. Um, you know, to yeah, too much out of this, Corp, Really? So you know, I hope you got a sense off how to give story toe ready for development and how to avoid the pitfalls and issues with views of stories. Thanks 4. Evaluating solutions against acceptance criteria: my rants, and I will talk about evaluating solutions against acceptance criteria. This is about collaborating with the your ex team to make sure that they experience aligns with the criteria. So we look at the user's story because they use the story one sets defined as we spoke about the previous class recording the decisions You'll you'll get a you the experience that, you know you would have collaborative collaborated with the U X team. But you really need to make sure that that experience aligns with the criteria that's being set out with a goal for your effects, right? If they're not aligned, you're not gonna have the right outcomes and you're not gonna have the right solution. So you need to really work with the user experience team. Acela's your immediate team toe. Understand? You know what's feasible and whether the use experience meets the criteria and also meets the scope off your hip. And this is really a collaborative effort, so you might need to hold a couple of sessions or might be new Refinement station, where, you know you have a good, robust discussion on Book of the User using experience and and stop toe you know, either change treek or modify the experience to make sure that it meets your criteria. So just some tips. Make sure it's well balanced. Um, make sure the solutions are feasible. And just recalled the nice to have. So this is a must ABS. Talk to your team about the technical feasibility. Better experiences achievable and feasible. Um, yeah. So I hope it gives you a little bit of sense of what's required from product owner to really understand. Ah, the because the key role and making sure that the criteria matches the, uh, use the experience in the solution and so thank you. 5. Summary & Example: Tyrone. Thanks for reaching the end of this class. I did gonna end with an example. So let's go through that. We looked at IPIC Components, so I wanted to go through another example. So in this example here, I've got a goal for the epic as secure log in and I've got these. The stories has been set up in logging with a pen, um, goals and outcomes so customers can log in with afford to depend and something we may wanna kind of measure is 20% of customers will set up dependence and three months of launch using experience covering the report floor. So this goal is really to allow customers a log in with afforded dependent, simple success metrics. So you want to measure percentage of accounts with them of our pen, Mr. Logging load time and seconds. Potentially customer satisfaction on that, Something you may want to measure out of scope. So, uh, the U X team, maybe even product. Or maybe the engineers may have said. What about fingerprint? Log in and you might wanna go. Okay. That's, you know, completely out of scope. Separate piece of work. Separate thing that we want toe you know, have a goal and travel separately. So let's look, it uses stories. So I've got one user story here. Just is an example. But sitting up my pen, um obviously want to sit up the pen to set off, Of course, of the questions. You know what happens but never been set up. Really? What happens? You know, use a gets a pen, maximum number of digits, ex cetera. So you need toe like we spoke in the previous class about recording to the decisions and making sure that you have all of use of stories defined and ready for development. So you need to refine this and, um, have it ready and discussed with your team on. Then we spoke about the user experience with his technical feasibility. It's about assisting all the different solutions against acceptance. Create here. Um, so just make sure that it's well refined. That's balanced, all options are explored. Um, and you recorded the nice to have. So it's very clear what you're building against and making sure that you're that the solutions matched your criteria. So that's a quick example. Um, yeah, that's pretty much it. So thank you. We're going to his class. If you have any questions off your comments, please do. And I love a review from all of you on this class. And I look forward to seeing you in the next class. Thanks.