 So my name is Mohsen, Ghazi Zadeh, I am an Agile coach and trainer, work mainly with mid-sized companies and Fortune 500 companies and I basically have been doing this for the past 12 years plus. So I was introduced to Agile when Agile has just become a keyword in the industry and through that basically I went through different courses just like you know many of you guys I probably took certified Scrum Master course with one of the early instructors and from then on I just stayed in the Agile environment because as you can tell I believe in what it does, I really like it, I feel it's something that actually benefits companies and individuals so I do this because I really love it and that has been a great career choice at least for me ever since I started it. All right, I want to quickly kind of go through why Agile is important. I believe the first thing is that yeah we are in the fourth industrial revolution that's what they say that we're in right now and a lot of sectors in the industry are trying to actually go back into becoming Agile. The very first sector was technology and then retail and banking went next and right now I actually have a few clients in this sector of pharmaceutical and energy which are trying to you know get started and go for a better Agile model so that they can actually catch up. But the reality is the only 4% of some of the 2,500 companies surveyed actually have truly made it. This is the part that I always I love to talk about when I talk to individuals is that when I go to places most of the time they're like we're Agile and I ask why and they say well we have standards and we do two-week sprints so we're Agile. And the reality is that Agility is not really I mean those are tools it helps you become Agile so when you actually have two-week sprints that's great when you actually have stand-ups that's very good but Agility as a whole is not two-week sprints and stand-ups and we're going to actually look into that and that's where we're trying to figure out exactly where product management sits in because that's actually a very important part of this. So if you look at original traditional companies and how they wear and here I have actually exemplified companies like Nokia, Eastern Kodak and Motorola. How many of you guys remember that you're having a Nokia phone? A few of us did right and nowadays nobody really talks about Nokia anymore really. I mean even in LA we had a place it was called Nokia Center now it's called Microsoft Center so I mean even to that extent the name was taken away but what happened with those companies? They were dominant and where they wear Motorola was a dominant company that I remember Motorola Razer cell phones were like the slickest thing that you could have in the early 2000s it was like if you had that phone you were hip and you know the same thing with Nokia. Nokia actually made great products but then what happened? They missed something and eventually right now they're basically phasing out Kodak. Same thing I mean Kodak was to a point just like how Google is right now so you would say hey you know what bring a Kodak that man that you know bring a camera and just like now when they said hey why don't you Google this or Google that or things like that I mean it was part of the lingo and so forth. The reality is that one of the things that these guys missed was that they didn't see the change in trends happening and the change in trend is this. Companies are emerging startup companies just like you know again you know I'm assuming this place is a startup company as well. They are coming in and majority of the time from a product strategy perspective startup companies in order to be successful this is what they do they look at their competition and then they look at exactly where the competition is the weakest and once they identify the weak point of the competition they go and start competing at that level and the problem with the competition is that they're so big and so giant that once something very small and agile comes and starts doing offering for their customers they can't catch up they can't necessarily you know fast enough go back and try to mitigate what the gap was that this competition is now trying to compete at right. So most companies what do they do they acquire another company majority of the acquisitions are not because the product is such a great product it's just that the product is really filling a void in my big ecosystem so therefore I'm just going to go and acquire and so I don't have to compete with them anymore so now they're part of me and I'm going to figure out what I'm going to do with them later and most of the time in acquisition of course we've had successful acquisitions like you know things like you know perhaps Instagram or you know YouTube or things like that but there have been failures in the market as well. One of the failures of acquisitions it was when a company called Tivo was acquired. Tivo was acquired because it was a great product but at the end of the day it just didn't work out and it could not they could not market it so they had to just put the product into rest right okay. So agile organizations of course you know they're they try to brand themselves that live in systems and the reason that you know that brand actually works or that terminology works for them is because they're constantly evaluating things and because their system is so agile they keep on changing with what they believe their market trend is. This is this can work at any scale. I'm going to give you guys another example like all of you guys have heard of Google. Google is a giant company at the moment. It's very very big. One of the reasons they're very successful however is the fact that the way that the product strategy at Google works is tightly coupled with how they actually you know look forward to innovation. So product strategy as well as innovation coupled together in an agile model actually creates what Google actually does have from perspective of tools or products or offerings or things in that sort. How many of you guys have heard of containerization or Kubernetes? It's a you know it's a it's a Google innovation product. It came out in 2014. Back there somebody was going like this and a lot of people are actually like this because nobody really knew what was going on with it but the technology is really powerful. It brings in the right amount of redundancy to your system. It somewhat is competing with something like VMware for instance and things like that. However not everybody could adapt it and by the way Google has basically got it perfected for themselves introduces a product and they're moving past it because now they're looking for the next thing. Meanwhile the rest of the industry are trying to actually move towards something that they were at probably five years ago. Okay. Agile organizations they focus on because a customer on market and majority of the time customers are embedded within them. They have a very tight couple conversation with their customers and they're open inclusive and non hierarchical. They embrace uncertainty and ambiguity with greater confidence. The reason is that they the way they look at it is that an uncertainty to them is opportunity. It's not weakness. So when they look at an uncertainty they're like huh what is it that we can do which is different and because the model is so agile and so fluid and so powerful they can actually go back and start implementing it and actually make make a name for themselves or compete. Okay. All right. Generally I like to say that Agile companies are just better equipped for the future. Why is this important? Well because companies want it exist. They don't want to die down. So if you're not equipped to live for tomorrow you probably have to have an end of life today. This happens on human being level. This happens on life level and this happens on company level. Everybody has to actually think through it from that perspective. Okay. So when you look at definition of Agile everybody agrees that you know it's about quickness, lightness and ease of movement. I like this definition a lot which says agility is defined as the ability of a system to rapidly respond to change by adapting its initial stable configuration. Normally these are some of the things that I'm going to go back and forth with you guys but because we are a little bit short in time I'm just kind of probably just you know try to go through it pretty quickly. Normally my question is why is the word system in brackets and the response I normally get it's a typo and it's not a typo it's actually there for a purpose because there is a definition associated with system. In any Agile environment one of the things that we have to be very aware of is the fact that we have to have system level thinking and system level thinking is something that is a differently a culture shift for majority of the companies. I told you guys that I work mainly with you know large companies or mid-sized companies and the reason I do that is because they are the ones that actually need the most help. A company which is sized you know between you know 50 and 100 people I would be surprised if there is really strong silos in there. You know if you're a product manager and you want to talk to a dev manager you probably can find them in the hallway and a cafeteria but when you were talking about a company which has got you know different locations and so forth a product guy and a dev guy if they're supposed to talk they have to set up a meeting and so forth. So Agility is at a different scale and a different level when it comes down to that. But the reality is that this fact doesn't change for any other organization no matter what the size is because you're all a system. The best example of always been giving about systems is Taco Bell. Taco Bell is a system. Here's how the system works. So basically when you are hungry hopefully when you walk into a Taco Bell store and that is when you walk into a Taco Bell system this is how the system works. You're going to look at a menu that's in front of you. You have to choose items that you wish to have with you know respected portions and sizes and so forth. You make your order. You have to pay. Once you pay there is a pause in this flow because another system starts right after you actually pay for your order right and that inner system goes and starts preparing your food. They take your order you know whether it's a burrito you know quesadilla whatever it is they actually make it they package it and they bring it up and that's when that system is done and your system starts working again because that's when you actually take your order either you dine inside or you walk outside with your food. Makes sense? All right so the reality is that every system has an input and an output and they actually start working together and that is important to know. Why do I say that? Well as a company if you want to be agile you have to have system level thinking because anything that you do in your department is going to affect somebody else. If your department is you know let's just say you have an accounting software if your department is about to you know make any change to a form that actually does you know accounts receivable inputs you probably are affecting a report down the stream on your report and you're affecting some sort of a calculation for taxes so and they probably are done by a different department so system level thinking is you thinking through the fact that when I'm making this requirement how am I affecting somebody else? Why do I say all this stuff? Because product managers as a whole are key elements that actually make this happen. There's individual interaction over processing tools working software over comprehensive documentation customer collaboration or contract negotiation and responding to change over following a plan and then right after that it says that is why there's value on the items on the right value items on the left more. I guarantee you if you actually start walking up to somebody who's a scrum master most of the time I you know I'm willing to put money at this and ask him exactly explain to me why items on the left are something that we actually value more they can't tell you so today you guys will find out the answer so you guys can go back and talk to your scrum masters and hopefully school them a little bit all right so in an agile environment a healthy agile environment has a team tripod and this team tripod has got three roles in it one is called a scrum master or facilitator the other one I call him product owner or product manager and the other one is technical lead this is the tripod that is needed for any team in order to be successful we're going to go over that and we're going to focus on product owner mostly the reason real quick I want to touch on the scrum master because majority of you guys probably are in contact with one of them you know they run your stand-ups in your and they're a little bossy probably right exactly or some of you guys are doing both roles which is wrong as well but that means that you know that things are not set up correctly so a scrum master is a facilitator at heart a facilitator is at its core has to be able to have system level thinking and understand end-to-end how things are working problem is majority of the companies when they decide that they want to go agile somebody comes to them probably a coach like me and says are you a project manager they're like yeah that well from now on you're a scrum master and guess what all you have to do is you set up a 15 minute meeting at a daily basis you ask people what they did you try to resolve impediments you run a meeting every couple of weeks and you get six figure salaries yeah and you don't have to do a lot of PMI work on things like that when you were doing the PM you know project management you know traditional stuff because we're agile we don't do documentation so far you know wrong stuff this is a misunderstood rule but again this is a product management school so I'm going to try to focus on the next one as much as possible this is majority of the time the conversation that a product manager has with a VP when can you get this done we'll get it done tomorrow this is what's important about a product manager when it comes down to a role in an actual environment because as a product manager you have to be able to articulate to people who are doing the work what is it that they're supposed to do and help them with information so that they actually help them and hopefully your project manager or your scrum master helps facilitate this exercise so that through this information they can get better estimates so they know exactly when they can do this stuff so why do we want to plan that's a separate subject but let me tell you one thing when you guys plan properly you actually reduce risks for your environment you actually reduce risks for your for your products and for your teams every time we plan properly we you know enable ourselves to actually do a better and higher quality delivery there's two roles that I used to talk about and one is called the product owner and the other one is called product manager and I want you guys to remember problem is most people believe product management is a better role because it's got the management you know ward in there at one point I was actually hiring for for for a product owner role in a company and we're going to go over these two real quick but it was interesting because I went through certain interviews and I would ask people I'm like there were a couple of candidates that were thinking that okay there you know we want to bring him in for a in-person interview but I needed to actually make sure that they are okay with this so I'm like you have to understand that this role when you come in and if you actually get it the title is going to be a product owner not a product manager are you okay with that like no I'm like why it's like I like product manager I'm like I get it but you agree that the role is a product owner role yeah I get it but I like the title product manager so literally this one lady she actually didn't accept the invitation for an in-person interview because she's like I'm a product manager and I want that same title that's an issue with the industry so you know be okay with it let's figure out exactly what's the difference between these two so a product owner is solution technology team facing contributes to the vision and program backlog owns teams backlog defines iteration accepts iteration derives iteration goals and iteration content basically if you are a in an in a role which is team facing meaning that on a day-to-day basis you're actually working with the team and the delivery of product is important for you and your objective is to make sure that we deliver the value that we have said that we would deliver then your role is a product owner product manager on the other hand is of course market and customer facing identifies market needs works with marketing and business development teams owns the vision roadmap program backlog drives release objectives and establishes feature acceptance criteria basically a product manager is facing outward towards the customer towards your market towards your competition and these two roles have to actually work back to back they actually work together but it's two different and distinct roles if you want to be set up for success you must have these roles fully established and they need to be distinct because if you tell somebody that you have to go to customers do demos for customers get customer requirements and come back and also work with the team you're basically setting them up first for failure not success and most people take that on the problem is this most of the companies that have been to a product manager they actually take this on as as as what they believe is their role and what's what they what they don't realize is this every time we don't properly you know that they give a team a requirement we don't set them up for success we just don't and the worst thing that you can do with an engineering team is when you actually allow them to guess because an engineer by heart is the guy who wants to create and a guy who wants to create that creation is a never-ending thing they always you tell an engineer to factor a code he could factor that code forever because there's always a faster way right somehow somebody has to stop them and in this case this is why this this work in the tripod of working with product and engineering and and project manager is management is very important okay so product owner is the what person tells people what to do it's important to stay at that boundary as well whether you're coming from an engineering background or a business analyst background i really don't care if i if i was a bun who's who's who was going to train a product owner i would not care what their background is i would tell you later on as far as what i care they know but i really don't care about the background as long as they stay within what they want the worst thing that can happen is when a product owner starts telling people how to do it that is exactly where there's going to be conflicts and at the end of the day it's going to just basically i mean in this case meshing the two roles is not good just like how i'm not a fan of having a project manager and a product owner doing the same be done by the same individual i just am not i know organizations sometimes they let go of a project manager and they don't hire one you know like this person can do it most of the time is the short-sighted decision on their side because they're like oh well so and so well they have time this is nothing you know they can do this and so for the reality is that the real the the the the actual role itself is a full-time role and they have to properly train and accommodate for it okay so po serves as customer proxy writes epics and user stories in accordance with program objectives these two are very important so that we can actually you know writing user stories are important right before we start this session there was a gentleman here who you know we were getting coffee back there and he was like you know i want to tell you something about you know we're agile because i think it was talking about this place and i'm like awesome and it's like but you know sometimes when you're trying to you know create a form for people creating a form doesn't really need a user story does it and i'm like oh it does in my opinion and i articulated for and why you need something written as far as the requirement every time you don't specify a requirement and and i'm not and i'm not advocating for like you know writing like pages and pages of requirements i'm talking about high level stuff you want to make sure that you you stay at a high level this is the part that when you do workshops and you training and and all that that's where you actually start getting a hang of it that's so what's the right way of writing a user story but every time you allow anybody to guess you're basically setting yourself up for for a nightmare because you're like you told me that this form is only half it has to only take you know first name last name and and an address it's like no i told you phone number it's got to be a part of it well i didn't know that well i told you the worst thing is that conversation i told you and i know you didn't write it down that's why user stories are there user stories gives you that scope you want that scope in order to properly demo and properly show work and the result of what you've done so as a product manager or a product owner and both of these i mean again depending on what role you decide to play this is something that you do in order to create focus for your teams your teams without these they cannot do what they're supposed to do in order to deliver products another thing that a product owner has to do and this is very important is make trade-off decisions there's going to be a time that you are standing in front of your team and your team is like you know what we got only a week left and we can't do everything that you are asking us to do what do you want us to deliver first that is a very legitimate question a product manager or a product owner as they are standing in front of their team they have to be able to make that trade-off decision and you can never make that trade-off decision if you don't understand what your priorities are and this is a very very big statement i've gone to companies and i'm sure you guys have experienced this they're like this project is our number one priority awesome oh by the way this one is also our number one too like you cannot have two number one priorities it just can't happen every time i hear that what that tells me from it from a coach perspective that tells me that that company or that group doesn't have enough criterias to evaluate evaluate priorities and that is not cool because every time you have two number one priorities you create conflicts and that conflict by itself is an impediment to delivering proper value for for your for your company or for your system so remember everything you do as product managers in any environment if you want to be agile your job is to create focus every time you focus and you create focus for the teams teams deliver every time you take them out of focus the teams will fail and the only reason they fail is because they don't know what to work on so they try to do two things at the same time i always tell people this is interesting we we make claims at times that yeah i'm a multitasker okay so my personal belief is that we as human beings are not multitaskers the only multitasker that i know or i have seen are mothers with their newborn babies other than that we are very much a single threaded beings and every time i personally i can never multitask i could never do it i mean people will read right through me when they're on the phone and i'm doing something that i run on the phone and i'm doing something that's why i'm trying to talk to them or like are you looking at something different i'm like yeah i mean i don't know i just give it away but the reality is this this goes into because an organization is made up made up of people so if you don't provide them with the proper priority and proper proper focus they can't deliver okay all right so i talked about value because as product managers you guys will be responsible for producing value for your customer or for your company and here's what i want you guys to remember as definition of value value is planned in conference rooms like this that's when you get together and you talk about what you want it's developed when you actually hand that you know plan or a requirement to your to your to your developers and they start doing work with it but it's only realized and manifested with somebody pays for it no matter what you to create if nobody buys it we got problems you can have the best kicking ass you know application but if nobody is planning on actually pay a dollar for it then it has no value now you guys i'm not going to go through this uh uh exercise but you guys have heard about a minimum viable product some of you guys have heard about that very good there's so reason that minimum viable product caught on and people are now starting to you know use it at least the terminology is something that everybody is uses a lot but the application of it is when i go to companies i realize that the application is somewhat not um it's not properly defined the whole purpose of it is to be able to test to see what is the stomach of your market for what you're about to actually put out there now minimum viable product is something that you're doing when you're when you have established company with proper customers and so forth and you're trying to ensure that your product roadmap is in the right direction minimum viable product also applies to innovations but it's slightly different thing we're going to touch on that towards the end of my slides however i want you guys to remember for instance if steve jobs was going to do minimum viable product on iphone in 2007 probably iphone would not have taken off the way it did so you have to understand that as product managers your vision and how you articulate what is the minimum that i need to actually test the market with right now is very very important there's a company uh which have been branded with the pioneers of android i don't know if you guys um and and my memory sometimes just completely skips me this is a company that was established in 1994 they created something that was very close to what palm pilot was but that was before palm pilot started and i can't remember the name sorry these guys what they had it was a spinoff of sony it was fantastic the product was great the product was actually very very much ahead of its time however what happened was that when they actually launched the product only 3000 of it was sold and there's a documentary on this in showtime if you actually want to and i'm going to remember the name finally and i'll tell you if you watch it the product guy who actually articulated and put put that you know had the whole idea basically um envisioned and and put it through and and and you know had the engineers work on it when he talks about it he's like when the 3000 people bought this when i looked at the names of the people who bought it i could actually you know make out every single one of them because they were either my friends or family and nobody else bought it so you have to also understand that as product owners there is a leap of faith as sometimes that you guys are working towards and that leap of faith it's always better if you have better market data and better perception data of your customers before you actually go forward it's a separate subject to actually talk about r and d and how r and d falls under you know on your shoulders and how you can actually best make better decisions in order to successfully do an r and d project i just wanted to touch on that here because again all of these encapsulates what a product manager does okay all right so um here is the business model of an agile environment and the involvement of um product product management role in it and in this case i'm actually referring to product owners so you have business which if we were originally look at our the definition business or business analyst was going to be that product manager who was looking outside into customers and market you've got the product owner here you've got technology and you've got what you actually put out in the production world right so business talks to the product owner or product management talks to the product owner and tells them hey this is what i want product owner goes back to technology teams and they're like well here is what's coming down as far as a requirement for us to start building technology responds back with well this is how we're going to do it remember these are the how guys product is the what guy when this is when we're going to you know send it back and uh here are the risks there's always risks associated with with any product development the same thing gets you know communicated to business business then you know understands the how when and risks and they finally say yes and technology goes to work and they put something with production once something is in production it reports back to the product management or business in a form of growth revenue or footprint whatever was the goal of that product to begin with meanwhile production also reports back to the product owner in form of enhancements and defects so check this out product owner has got the most amount of flashes pointed to it so one of the requirements that i always say if you're going into product you know if you want to become and we have you know somebody here who wants to actually make a career choice you have to be bilingual and you have to understand technology and you have to understand business that is what makes a you know a good product owner if you understand how you're impacting your company and how you can you know collaborate with with your technology team to actually deliver uh the features your home and by the way this slide is part of my agile training so i always say scrum master sees the end-to-end facilitation of this that's why you know if they're actually truly at the core of their role okay so let's go back to the agile manifesto remember we reviewed it at the beginning and i told you guys nobody could actually say why these things actually are the way they are so we have the four pillars or the four definition at the beginning this is what it says later so individual interactions is basically when you create your stories and your storyboards that's when you actually put together that individual interaction that's when you discuss them that's that's when you estimate them that's when you actually try to collaborate in delivering them working software is your mvp you do the mvp you evaluate then you do the next chunk and then you evaluate and then the next one and the next one right customer collaboration is when you do planning sprint and demos majority of the time when you do a demo hopefully you invite your stakeholders and customers and they get to comment on it and they get to see it right and responding to change is when you actually do your iterative development so this is what it means in agile manifesto when you read those four lines now you guys know more than 99.9 percent of the agileists out there okay how to execute as a product manager or product owner again i want to this is a very very high level summary of this role within an agile environment but i really want to make sure that if you guys leave here at least you have something to work with so define roles and responsibilities when you go back to your organization and try to figure out where you stand are you a product manager or are you a product owner are you customer facing or are you team team facing you're doing both of them have a conversation with your boss and then you can have him call me and i'll tell him that's another thing right know your product why because you have to be able to do system level thinking you have to understand what your product does know your system of course because your product whatever you're responsible for is affecting the entire system as well right know your prioritization criteria because you have to be able to prioritize properly have a prioritized backlog remember that you are a what and why not a how don't tell people how to do it tell them why they need to do it and what you need okay all right provide focus be present with your team and i know there is one more demo as frequent as possible demo it the more you show the more you show visually what has been developed the better your the quality of your product is going to be at the end all right and i always tell people to celebrate your success be happy that hey we finished this make it visible okay so as an agile team how do we execute if you actually were to go forward with it i always tell people to understand your system you define roles and responsibilities know your customers hello decide what's what's right for you take a time to plan an estimate do not compromise or your retrospectives measure yourselves be transparent ask for help and celebrate your success okay this is an agile environment as a whole all right i want to guide i want you guys to also see a couple of slides the next three slides are basically just food for thought and hopefully for future conversations and future talks this is a quote by Henry Ford it said that if i had asked people what they want they would have said i want a faster horse this is what's neat about being a product manager and you have a having a vision is important a product manager with a vision is somebody like Henry Ford who can actually come back and change the entire world