[Music] foreign ER and partner of Silicon Valley product group before founding svpg to pursue his interest in helping others create successful products through his writing speaking advising and coaching he served as an executive responsible for defining and building product for some of the most successful companies in the world including HP Labs Netscape Communications and eBay I'm as part of his work with svpg Marty is an invited speaker at Major conferences and top companies across the globe he is also the art of the author of two books inspired how to create Tech products customers love and empowered Ordinary People Extraordinary products we are so excited to hear you in this session which is called leading complexity with with context and not control over to you Marty all right thank you very much thank you and uh you know thanks for inviting me to this series I love the idea of this series in particular uh I've been talking to Marcus about this topic for multiple years um so I have a talk that is not a normal talk I have lots of sort of typical talks I give but this one is a special talk really just for this community this group uh where I and and by the way I have been paying attention to those of you who have shared what role you're in this is super helpful to me because my uh my theory is that most of you are are coaches or trying to be that sort of change leader at your company and help your company get better or for many of you help many companies get better your client companies get better so that's a group that I feel very uh deeply about and and care a lot about this um I will warn you that um a lot of what I'm going to talk about is probably going to be uh um ranging from uncomfortable to disagreeable you're gonna have to decide but I'd encourage you to to consider this I think we have um one of the things I have found in the sort of coaching Community is virtually every single person I met is very well intentioned they have a sincere desire to really help other people get better and that's why I love people like that however um I think the community as a whole has been misguided and I am going to try to use this time with you to convince you that in truth much of what you have been taught is not helping you or more importantly your clients so I absolutely going to save plenty of time for Q a at the end if you feel real strongly about anything feel free to just interrupt I don't mind that um but uh I I want to give you I wanna maybe get you to rethink some of the things you are thinking today about helping and for those that don't know I mean you heard a little bit about my bio but what I'm really all about is um my focus is on the best product companies in the world as defined by those kinds of companies that are forced to consistently innovate in order to stay in business so it's all about consistent Innovation that's my world that's what I mean by the best product companies and because I was just by dumb luck really I worked at Netscape which was incredibly lucky for those that don't know that was the first internet company and I worked at uh eBay which was the first Marketplace company I mean the truth is a lot of the people that went on to go to great product companies came from one of those two places so I knew a lot of these people and they would call me early Google early Amazon early Facebook early Twitter all these companies would start and I got to know them and um uh my world is really about sharing how they work and trying to close the gap between how they work and how most companies in the world work but I have to admit I'm losing that battle I think collectively we are all losing that battle more companies are working terribly I mean just terrible than ever before and so um I think we need to step up and look at um uh how we may be inadvertently contributing to that so that's where I'm coming from one of the things I started with is I wanted to just make sure um you know because we are all dealing with complexity we know that so I went to the you know my my sort of like you know the friends I have at these companies it's a pretty little big list and I asked them like you know so what what when you talk about dealing with complexity what are the things that you care about and interest no surprise they're the same things everybody cares about just just they're these are the things all of us deal with so one of the things I had this theory that the challenges are no different the challenges of a Bad Company versus the challenges of a good company they're still the same challenges there's no Silver Bullet that makes them go away however the way they deal with those challenges is where it gets interesting so let's talk about this now the first thing I want to do is kind of get something out on the table that is going to be a theme through this entire talk but and but I think this is the reality that we have to really talk about today when somebody says you know they're agile I don't even know what to believe that is so tortured and damaged as far as a brand but let's talk about this let's talk about two teams and I can list many examples of each of these so team red let's talk about team red they are they've got an agile coach maybe one of you they've got a scrum Master they of course have a cspo or a pspo trained product owner they follow scrum rituals religiously they do Sprint planning they do daily stand-ups they do demos they do retrospectives all the things we'd like them to do they're probably following scrum maybe they're following kanban but that's what's going on however they're not empowered by any meaningful definition of the term they're there basically to implement a road map usually coming from a bunch of stakeholders and also the team releases monthly or worse a lot of them are releasing quarterly I even talked to a company recently that's still somehow releasing yearly and what's remarkable is these companies consider themselves very agile in fact go further they consider themselves textbook agile now let's talk about team blue team blue thinks agile is a bunch of [ __ ] and I hear that from companies all the time I hear it from teams at Amazon I hear it from teams in Netflix I hear it from teams that stripe it's like no agile is a bunch of BS look at all this nonsense out there and they say no we don't have any agile roles we don't have any agile coaches we don't follow any scrum or kanban rituals however they're truly empowered by the sense that what we mean they are given problems to solve the team's able to go figure out the right solution and they're doing continuous delivery continuous deployment and by the way not for the last weeks usually for the last many years now you tell me which team is more agile this is you know that's not a hard question team blue is the only one doing any meaningful form of agile one of the talks I'm going to reference uh through my talk so the person who actually introduced me to crisp years ago was Henrik nieberg who he gave the the introductory talk and I I will tell you I'm a huge Henrik fan I'll listen to him explain anything doesn't matter what it is he is I just love listening to him he is a gifted Storyteller and a gifted I think he's a gifted coach uh and it was so funny to me listening to him because I'm going to reference the Spotify model as we go but um it was really funny he sort of says yeah they're agile so of course they're empowered of course they're doing frequent release vehicles and I'm going Henrik I wish I wish look at all these companies out there in fact I don't know what the real answer here all I can do on this is say anecdotal but you would all have your own experiences how many of the teams you know are actually releasing you don't even have to be doing continuous delivery deployment they could be doing release every week or even every two weeks that still counts as agile in I think in my book in the real book and how many of them are actually in power versus just feature teams or even worse delivery teams almost none of them so you have to ask yourself what the hell is the point of agile if that's what people are doing and of course people are doing a lot worse than team red even I'm going to talk about that so it is not uh you know we need to step back now the theme of this talk is going to be looking at another way of phrasing it is what is agile really is it a process like scrum or is it a set of principles like you find in the manifesto what I would argue with Team blue is they are actually living the agile principles and when you talk to them about the manifesto they go of course these are obvious we've been doing this for we believe this forever but these processes they're a joke now I think it's deep there we're going to talk about why companies get pulled in the direction of formal process but I'm going to be honest with you good product companies their team blue they're not team red okay now I have to also confess to you that for nearly 20 years I've been recommending teams move to Agile if they're not so don't get me wrong I'm I clearly and why do I recommend they move to Agile because of this that's because I've been I think of it in the terms of they're going to be empowered they're going to do frequent continuous release vehicles and that's um agile is often the forcing function for them to get there but if they're gonna move to Agile and not get there I'm you know I'm not gonna talk about it that's just not helpful so coming right at you this is not useful uh we need to revisit and rethink what we're talking about here so let's step back because like I said it gets worse it gets a lot worse fundamentally there are two ways of coping with this complexity that we all face once we get Beyond just like about a dozen engineers and the main way that I see most companies dealing with it and partly this is the fault of the coaching Community is they deal they attack it with process now the most egregious form of that out there and you know another thing Henrik showed was that slide that almost made me cry but it showed you know how do companies deal with scale uh and and agile and of course he was showing off that oh look the Spotify model is number three or number four but that's not what I saw what I saw was number one buy a long shot was this piece of crap safe now we need to talk about and my goal through this session is that every one of you understand why this is so toxic to the companies you're trying to help so first of all I want to go I have to sort of fess up almost well four and a half years ago I looked this up last night four and a half years ago I wrote an article because people kept asking me about safe and I said hey the problem is I don't know a single good product company isn't safe so how am I going to write about it but I kept getting asked about it so I reached out and I talked to people that were running safe they're not in what I'd call the best they are all absolutely not in the best and anyway I published an article that said things like there is literally nothing agile about safe which is super easy to see I don't know why I mean that's just marketing right they added the word agile in for marketing but hopefully you'll see this and I I also say I don't know a single strong product company that uses safe which is you know what's really remarkable at the end of the article I said hey I only know the people I know I I can't pretend to know about all the companies in the world because nobody knows all the companies in the world and I said but I can tell you I do work with most of the best product companies not a single one of them uses it and I also said at the end of my article if you do have good experiences and you work at a serious Product Company please let me know reach out to me just so you know four and a half years later I have had well over a hundred people reach out to tell me that safe is a piece of crap but none of them have reached out and said it actually works for us and we're a consistent we are a product company meaning just to be clear I said this earlier but a good product company is a company that depends on consistent Innovation that is like a Spotify for example the only reason they're still here despite competing against two of the best product companies in the planet apple and Amazon is because they are good at product that's the only reason we're going to talk more about them but this the truth is I still don't know a single good company that uses it and I also said in that article that if a good company did adopt safe I'm pretty certain they're best people would leave now these are really I mean that's pretty harsh wouldn't you say that's pretty harsh um but I want you to understand why I was able to say this with such confidence and when I said it in four and a half years ago I didn't know really I mean maybe I was just missing all these great companies that were using it the truth is it's continued to grow like crazy but what we need to talk about in this talk are the two really important questions the first one is what is it about that piece of crap that is so attracted to so many companies I know what it is it's not a mystery but we need to talk about that what is so attractive and number two why is it that none of the consistently Innovative product companies use it what the heck is going on I want you to have clear understanding of the answers to those critical questions today this is a big deal and I suspect many of some of you many of you you know the truth is there is a lot of money to be made as a coach helping a company to implement deploy safe that's what it's for it's a machine there's a lot of money to be made and I don't get me wrong I'm not judging you have to feed your families but if you genuinely want to help the com your companies that you're trying to help I want you to understand why you're not helping them at all so this is important so that's what I want to talk about here now I want to start here by sharing with you because I find this really remarkable so it's not just that the best product companies don't use a process like safe most of them don't like formal processes at all you could put Less in the same bucket I actually don't know anybody who's unless I don't even know if it's relevant but um but it's not good I'll tell you that and I understand why the good companies don't use it so one of the leaders think about this approach and I find it remarkable because the truth is they are all uniformly afraid of this happening to their company and I can say I don't know of anything else that these leaders all agree that they're scared about right so Eli who of course has lots we could talk all day about crazy Elon right now but he's right the problem is that big companies process becomes a substitute for thinking I think he's spot on there allergic to process for those that don't know Steve blank he's uh well the father of Lean Startup um he is uh four times successful entrepreneur teaches entrepreneurship it's Berkeley and and Stanford but he's right as companies get bigger they start to Value process over product over time as organizations grow the process people start dominating management and the product people end up reporting to them what he doesn't say is and then the product people decide to have to go somewhere else in order to practice their craft how about Bezos at Amazon he talks a lot about the difference between a day one and a day two company a day one company no matter how old you are a day one company acts like a startup uh and no matter how old you are a day two company acts like a big bureaucratic process machine and the point is if you're not careful process can become the thing it happens very easily in large companies but process is not the thing I don't know if any of you took me up on my suggestion to watch The Lost interview with Steve Jobs but here's a little clip and by the way I consider that an absolute master class in product if you haven't and it costs four Euros to watch so um it's best thing best best four Euros you'll ever spend but let's talk about what he thinks about process people get confused companies get confused when they start getting bigger they want to replicate their initial success and a lot of them think well somehow there's some magic in the process of how that success was built so they start to try to institutionalize the process across the company and before very long people get very confused that the process is the content that's ultimately the downfall of IBM IBM has the best processed people in the world they just forgot about the content and that's so what happened a little bit at Apple too we had a lot of people who were great at management process they just didn't have a clue as to the content and in my career I found that the best people you know are the ones that really understand the content and they're a pain in the books you know when you put up with it because they're so great at the content and that's what makes great products it's not process it's content so you know I honestly can't point to anything else that all those leaders consistently are scared of but it's true you have to realize when when Steve Jobs said that IBM was kind of like we think of Amazon today they were they had been great and they lost it they lost it and that happens to so many companies and by the way he recorded that before he came back and turned Apple into the most valuable company in the world so it was very unusual I would encourage you to watch that video but so let's talk about the alternative now Henrik described one company that uses the alternative um Spotify and um I think I said this before in my view Henrik is an incredibly gifted coach uh I I'm he's the one who actually introduced me to crisp years ago and um but that said uh the first part of his quote is spot on the most important thing is not your process the second part of his quote is not really helpful or really even true um well what I'm going to talk about and I'm pretty sure Henrik would agree because so much of what he said in his talk was actually getting to what's important but I and I feel a little guilty because uh in my my understanding is Henrik is a bit of a Swedish National Treasure so um this is with love uh I hope Henrik uh maybe henrik's even listening and he can join us in the Q a but but I am going to um talk about a few things here that are you know I watched his video and because I I love hearing more of the uh Spotify origin story I did get to work a little bit with Spotify nothing like him but I actually you know Henrik didn't really he didn't really tell you what you needed to know about Spotify and I need to tell you that so first of all he didn't answer what is it about the Spotify model that enabled their record of amazing consistent innovation I couldn't hear that I couldn't find that and even maybe more important because this applies to so many of you I didn't hear a word about why did so many companies that try to adapt the Spotify model make fail to make any meaningful Improvement I see that all the time by the way I need companies that say yeah we're on the Spotify model but it hasn't really done anything um and I'm like well show me your Spotify model and what do they show me this does anybody actually seriously think this is the Spotify model this is noise this is irrelevant try you know the fact that they like to call a cross-functional empowered product team a squad it's irrelevant who cares now Henrik did say in his talk that they they named it different things so people would um would ask the question what this really means and I could tell you definitively that has failed because so many people use the term Squad but they don't change it to mean what Spotify means so what's the point it's just another way the point is who gives a [ __ ] about what the terms are for this we don't care that is not the Spotify model Spotify model is much more important and this is and I just stole these little fragments off of henrik's wonderful illustrations but this is what the Spotify model really is and it's not a process at all first of all it's not a process where's the process they don't even care if you're running scrum or kanban within the squad they don't care it's where's the process it's not a process it's a culture it's the way he likes to describe it or it's a set of the way I would describe it the way Netflix would describe it the way Amazon would describe it it's a set of first principles it's a set of things we believe about how products should be built for example the biggest one is Spotify very and this is why I say Henrik knows all this stuff he just doesn't you know I I want him to call this out I want to call it out for you why did Spotify succeed it's not because they named things goofy names it's because they had these principles and I see these same exact principles at good product companies across the world and you know I'm not I know I'm beating up on my Swedish God Henrik here but he he sort of said what I want you to do is copy paste adapt do you remember that you should copy paste the doubt that is terrible advice and that doesn't work that's the biggest reason so many companies that quote adopted the Spotify model and didn't get any value maybe if think of it this way let's say I made Swedish meatballs for you and you loved my Swedish meatballs and you said you know can I have the recipe and I'm like sure here's the recipe and and let's say you decide to adapt it and maybe you adopt it by removing the meatballs do you think you're gonna like my Swedish meatballs if you remove the meatballs no it's gonna not be good Swedish meatballs and that's what happens people people listen to him they adapted it and they lost what was important now unless I was waiting for Henrik to say and these are the principles that were really important and made the difference and if you want to adopt the Spotify model it's not about the nomenclature it's about these principles so this is what you as a coach you need to understand if you want to help a company it's about these principles number one probably the overarching one is there it's a way of working that's optimizing for Innovation over predictability now by the way safe is the exact opposite safe is a process that's designed to optimize for predictability many of you know that's what waterfall is good for safe despite the marketing it's pure waterfall pure waterfall it's just got all the buzzwords thrown on that ridiculous image but it's it's all you know anybody knows knows it's [ __ ] so it's just uh buzzwords but it now of course it's fine it's fine to optimize for predictability but not if you're a tech product company that depends on innovation so that's why I say with confidence no good product company would use safe because it is optimized for a different problem I also love I mean I just love these things that have been there for a long time and this is why I as soon as I you know met Spotify and talked to them about how they worked I'm like these are all the same principles that it just took me a little bit to get through their silly nomenclature differences but that was easy trust beats control focus on motivation the whole idea of squads which is just you know it's like a mini startup it's cross-functional all this is what we mean by an empowered cross-functional product team well how about small and frequent releases decoupled releases how about this idea that agile actually means more than scrum the reason they succeeded is because they didn't get trapped they didn't get fooled by all these processed people they knew to ignore them the principles are What mattered impact more than velocity another one that I've been talking about a lot lately because it's such an important first principle I don't think a product team has any chance of success with Innovation if that product team doesn't have direct access to users and direct access to the stakeholders of the business look at what they've got there just minimize the distance between the maker and the user they understood that too the point is oh how about an experiment friendly culture we call that product discovery that all the principles there are the same principles I see in the best product teams that's why I love Spotify a long time ago that's why I still like them now a lot of companies uh will ask you know well can we adopt the Spotify model my answer for years has been you can do a lot worse than adopt the Spotify model it does it's a it's a good model and it can work the problem with it is it's not packaged in a way that people see what's important I'm going to say since I'm saying all these Blasphemous things about Henrik I don't like those big diagrams the culture diagrams you know they're famous big diagrams I think everybody loves them don't get me wrong I understand that but I don't like it because there's too much on there people don't take away what they need to take away what it would I think it would be much more impactful and if you share the model with people break it down talk about each principle now the truth is there are some principles that you could be like are they really critical or not that's fine but there are some principles that really are truly first principles when I first met Spotify the most important thing I saw and this is what I look for in any the single most important thing is there Engineers were empowered and by the way that is not true and safe that is not true unless that is not true in uh most of those processes unfortunately as we all know you can use the method of scrum and be totally unempowered if you're just we say if you're just using Engineers to code you're only getting about half their value so that's a first principle Spotify sets the dial on an empowered engineer to 10. by the way so does Netflix you heard Joe Justice Tesla sets it maybe to 20 you know they set it all the way past the dial uh but this is the most important thing and if that's not happening I don't really care about the rest I know it's not gonna work so there are certain principles here that are first principles and are absolutely essential but if you want to know why Spotify has succeeded still and despite so much competition it's because of this it's not because they call groups of teams a tribe it's not because they call a cross-functional team a squad it's not because they have guilts it's not they could have addressed those things a dozen different ways it wouldn't have matters what matters is that they understand these critical principles and this is and you have to be able to look at what Spotify does and then look at safe and you can hopefully see how different they really are and why one leads to success and one doesn't I'm just looking uh yeah I cannot pretend to be able to interpret what Dave Snowden is trying to say so I will just take your word for that all right so let's talk about how do top product companies deal with complexity let's look at this and I would absolutely include Spotify they have long ago earned their place in that list of top companies so first there's there's really three things first principles which I started talking about and then thinking and then talking it's funny because when I talk to my friends at these companies about well so what do you think is the key you know they all use different words for the most part they're talking about the principles and they're talking about what I'm terming thinking and talking but this really is the alternative to scaling with process so let's talk about let's talk about some not all but some of these first principles well I mentioned this one just before this is what I look for in every company I first meet and that was true with Spotify and it's true nothing is more important than an empowered engineer that's Bill Campbell he literally explained that to Steve Jobs before in an early apple he literally explained that to Jeff Bezos at early Amazon he literally explained that to Larry and Sergey at early Google and it's not an accident that all of those companies built their way of working around this foundational first principle I was taught this at HP Lab at the time I worked there was known as the most consistently Innovative Product Company in the world but that's what they taught us on empowered engineer so an Empower engineer is not a mercenary it's not somebody that's just given a backlog and said go implement this it's somebody who cares just as much about what they build as how they build it this is a critical first principle what does it mean for a team like Spotify says to work like a startup or think like a startup this is what we mean by an empowered team leaders should articulate what needs to be done and why and then let the team decide the best way to do it one of the things I loved about henrik's talk and and one of the things I hadn't heard before was he shared how the leaders of Spotify got up in front of the squads and said look we do some things really well about helping you manage your music but one of the things we don't do well is help you discover new music for those of you who saw that hopefully you remember him talking about that niada even had a photo of the leaders explain well I think that's what it was leaders explaining this that's what good product leaders do they provided the context they shared this is the problem this is why we need to solve it figure it out and of course there was lots of product Discovery work that went on and they came up with I mean the the origin story for discover weekly is an awesome origin story it's an often sorry an awesome product Discovery story they did a great job with that I will tell you as a Spotify user I rarely do playlists anymore I because the the generated ones from discover weekly are generally better than my own that's how good they are so that's another first principle though we need teams of missionaries not teams of mercenaries you saw the Spotify principle of motivate that's what this is that's what John door is trying to say you need motivated teams in fact a motivated team of Engineers can do almost anything it's amazing it's what keeps me in this business how about Leslie for those who don't know Leslie Kilgore she was one of the early members of uh Netflix she was ahead of their marketing actually and she coined the phrase you know their model is you push decisions down to the product team sound familiar this is very much what Spotify does this is what all the good companies do and by the way the polar opposite of what safe does safe is a command and control model top down the decisions are made above and passed down to the program level then to their they call them teams but they're not teams anyway lead with context not control instead of command and control that's what control is for it's context which is short for strategic context that's like tell us the problem tell us where we're trying to go tell us what other teams are going to do so that we can do our part you probably know Jess humble he wrote the book um accelerates one of my favorite books for the engineering side of the equation I love this quote if it hurts do it more frequently that's another one of the principles in Spotify this is why frequent small reliable decoupled releases is the foundation of any good product company they need to be now that's not just a um a purist thing and you don't have to be continuous delivery I I prefer if you are there's a lot of advantages for our customers and for us but at a minimum you have to do release trains no less than once every two weeks at a minimum if you're not doing that why do I say that because if you're not doing that you're not taking care of your customers we can talk about why I can point you at articles if you want to read about why but you're not taking care of your customers and a good product company is all about taking care of their customers and innovating on their behalf Reed Hastings the co-founder of Netflix he's talking about product teams in a team topology highly aligned Loosely coupled it's another one of those Force first first principles we want to structure our team so that they're highly aligned Loosely coupled again you'll find that in the Spotify model too Mark Andreessen the co-founder of Netscape he was my boss there and the co-founder also of Andreessen Horowitz now but um you know he the way he phrases the need for an experiment and experimentation culture is um the most important thing is to know that you can't know and good teams not only know what they can't know but they admit what they don't know and they go figure it out if we knew we would just build it that's why it's so easy in a process that's focused on predictability we know how to deliver on time on budget I learned that literally 40 years ago it's not hard but it means shrink to fit it means cutting it you give up all hope of actually solving customers problems it's literally output over outcome but of course what matters in the product world when you're busy when your livelihood depends on consistent innovation what matters is results and that depends on knowing what you can't know and then we go figure it out that's literally why we call it product discovery Diane Green the co-founder of VMware the riskiest thing you can do is not take risks it's all about being smart with risks you know we look when we're coming up with a good product we're looking for a solution that's valuable usable feasible and viable all right those are examples of first principles now if you look at henrik's images when he showed you know the engineering culture at uh Spotify there was like 20 principles in there buried in there along with lots of pictures and lots of stuff but if you look closely at it you'll see these first principles that is what matters now I don't I'm not saying that every company that wants to use the Spotify model should just exactly use theirs but I am saying you better get the meatballs right you better get the important things if you get those important things and then you know every company is a little different uh Netflix feels very strongly of that that process rules are insulting to their people so they literally don't like things like an expense report policy they think that no if anybody we hire is smart enough to be reasonable on an expense report is that important I don't know you know um there are other examples of that you can see examples of that in the Spotify um you know Amazon's got things they feel religious about they feel religious about a technique I'm going to talk about in a minute which is called the six page written narrative do you have to do that in order to be a successful company I don't think so do I recommend it absolutely so there it's not a first principle but it is a really useful technique so there's differences in companies that's the part you can adapt to your culture but if you don't get the meat right you fail all right so let's talk about thinking what does it mean to think uh and I mean this this is really important what are we thinking about we're thinking about three big things product strategy it's a huge element product discovery and big product and policy decisions these are the main things we're thinking about and that's uh the leaders and this is the source of so much complexity we have to solve for these things now there are some good ways of doing that I haven't mentioned stripe yet they're probably one of the best product companies right now hitting on all cylinders but um yeah uh think deeply to move quickly now that's a uh that's a first principle they believe in I didn't see it in the Spotify one but uh I think they would like it they may even do it I don't know but that's sort of the point if you're trying to think better this is this is why we do that I love this quote you probably don't know Leslie Lamport but he invented one of the very first word processors uh and I benefited from that but I love this quote if you thinking without writing you only think you're thinking because I really do believe that that's why Amazon feels so strongly about the written narrative the so-called six-pager and you know it's something I really do believe writing force is the author to really think much more deeply to articulate your logic your priorities take accountability for your recommendations there's no wiggle room no hiding place this is the thing they don't allow PowerPoint presentations because they think it's far too easy for somebody who's a charismatic speaker to get up there and wave their hands and people tend to go along rather than really listen to what they're saying and whether they know what they're talking about so it's uh it's so it's part of their culture okay Apple's got weird things in their culture everybody's got different things in their culture all right and then the last one is talking and what are we really talking about here well we're doing a lot of coaching this is one of those big differences between good companies and the rest is coaching we're also talking about first principles so that you can pass these on to your teams and we're also sharing that strategic context the vision the product strategy the team topology one of the things I love seeing is how so many more companies are understanding the role of coaching today I love this Andy Grove quote for those he was a long time CEO at Intel you know what gets in the way of good work there's really only two things the first is that your people don't know how to do good work because they weren't taught which is what coaching is meant to do and the second is they do know how but they don't care they're not motivated that's why you saw the motivation first principle for Spotify Bill Campbell's quote coaching is no longer a specialty you cannot be a good manager without being a good coach now I want to distinguish because a lot of you are coaches and as you know in the coaching Community there's kind of two kinds of coaches I mean our our dream world is every coach does both of these things but in the real world uh it's often too there are coaches that know the content and there are coaches that just know the art of coaching do you see what I mean by that so in the product world where we're talking about the reason your manager needs to be a good coach is because your manager's primary job is to coach you on the skills if you're a manager of product managers your job is to coach them in being a great product manager if you're coaching tech leads to teach them to be a great Tech lead and same with designers it's I think it's impossible to do that if you have not done that job yourself and my evidence for that and this is going to be rough for some of you to hear my evidence is the vast majority of people teaching product owners in cspo and pspo classes have never done the job at a good product company so what are we doing we're creating people that know the rituals of the process that but are absolutely clueless when it comes to the substance of the job this is one of if you've read anything I've written you know this is a hot trigger button for me but we have got to fix that the people that need to train product managers are people who have done product at good companies if you've let done product at Spotify for five years okay let them teach product people you notice I'm avoiding the term product owner I think that it's a bigger problem in Europe than it is in the rest of the world but and I'll admit I didn't see this problem coming originally and I should have I thought who cares what it's called well it turns out we should care a lot because product today we have all these people that know the rituals in scrum but they don't know the job of product manager and the whole product model falls apart if you don't have a competent product manager and I will tell you I have never met somebody who's only been trained as a product owner that was anywhere near competent as a product manager so we need to if if you're trying to help a company stop trying to teach them to be a product owner if you've not done this job get somebody that has done the job just like would you teach an engineer how to code if you've never been an engineer seriously but for or a designer if you've never been a trained designer a serious designer but for whatever reason we think we could teach somebody to be a product owner I honestly think that the industry has not done the product Community any favors by doing that so I'm I'm interested in a title product owner and even worse anti-pattern is a product manager who is not the product owner by the way that's the model in safe if you haven't noticed so there's a hundred different ways that is a toxic terrible way of working how about Microsoft the the new leader Sacha who's so much better than they're his predecessor and is really turning that place into a product company again the leadership framework now at Microsoft's got three pillars modeling good behavior coaching and caring about your people how about at Apple long time Tim Cook there's a the Apple Leadership Model there's four pillars one of those pillars is teaching and coaching one of your four responsibilities as a leader how about Sundar at Google the top trait of a successful manager at Google is that that person is considered a good coach by their employees by the way the second rated trait is that they are considered an empowering manager and not a micromanager and then back to Spotify to bring it home here I love this quote I learned it just recently talk is cheap so we should do a lot more of it I love that that is a big part of the culture that's what we do we need to share and and coach and share the context all right I have thrown a lot at you I just have one more thing because most of the coaches I know they genuinely want to help their company learn to work like the best that's what I hope you do and I hope this talk motivates many of you to rethink how you're actually helping if you're even helping and if so if not how you can change when when we talk when I meet a company that genuinely it's usually a CEO that reaches out to me and says all right we know the way we're working is not working for us Amazon's now coming after us somebody else is coming after us we have to learn how to be a serious Product Company we have to start innovating how can you help the company do that there are three things number one you need to get them to change how they built so I don't care if they've been doing agile for 10 years if they're not doing frequent small independent or or decoupled releases at least every two weeks they're not agile and you need to give them some tough love you need to tell them you're not agile at all it's not about the roles it's not about the rituals it's about do you have consistent frequent reliable release vehicles again no less than once every two weeks if not you gotta fix that second changing how you solve problems this is what it means to move from a delivery team or a feature team to an empowered product team changing how you solve problems now the teams have to step up they're not just there to code they're not just mercenaries they are there to solve problems which means product discovery which means you need three critical core competencies real product management notice not product ownership real product management real product design and real tech leads serious engineering those three competencies come together they're supported by others like data analysts user researchers but those are the three core competencies and their job is to run these experiments to get us to a solution worth building and finally the third and this is what's meant really by moving from an I.T model or project model whatever you want to call it to a product-led company which is changing how you decide which problems to solve which opportunities are the best ones to pursue which threats are the most serious threats a lot of you are not even concerned with that because in the old model in the it model it's not even a question the stakeholders decide those things but in a good product company like all the examples I was giving no the product leaders are responsible for that and that's hard you have to pick the things that really can move the needle like when the leaders at Spotify said we need you to help people discover new music that was them as a leader deciding the most important problem to solve if they would have gone and asked a salesperson they wouldn't have heard that they go and ask a stakeholder they wouldn't have heard that but this is what the leaders do there are skills involved in all three of these obviously continuous delivery is the skill for the first product Discovery for the second and this is really first and foremost about product strategy all right I know I have thrown so much at you if you do want to learn more there are some books you know inspired talks about product Discovery and empowered talks about product leadership love this by my partner Martina who is it's talking about product marketing we have one more book underway it's going to be a little while because it's a hard book to write called transformed which is really about transformation and it really talks about those three big things I just listed changing how you build changing how you solve problems and changing how you decide which problems to solve and it got several it already has several first-person detailed case studies of successful Transformations with most coaches we talk to that's what they're asking us for more than anything they will they know the examples that fail they're all over the place company needs to transform they hire somebody like McKenzie or Accenture they bring in something like safe they get nowhere other than spending millions of dollars and so they know what doesn't work what they don't know is what does work and the purpose of that book is to share that okay so I will I would love and I've actually I'm right on time which is just more dumb luck than anything else that's great Marty but I I Marcus let's do some questions but for anybody that um does not get their question answered jot down my email there um so that you can feel free to send me a note all right and I can say Marty is amazing at answering emails and you're very fast at responding to and you've been great so far with with feedback and so so thanks all right so let's open for uh questions please use the chat to write a question and and before um you wrote an email to us in the leading complexity crew a couple of days ago and you said that this would be uh um a wild ride or something equivalent to that and I I can just say it was a fantastic presentation so let's open for questions uh let's see what we have so the first one for Maria I would like you to elaborate on team red what was the problem with having roadmap isn't the six pager plan I need another hour Maria that's those are big topics um so the first of all six pages not a plan just to be clear six pager is a rationale for a decision first the truth is you can have lots of forms of six pager the most famous one is called a prfaq which is still not a plan it's a vision uh but the most common example is actually a this is a decision we need to make around our product this is our recommendation so it's still not a plan uh now the other part of what you're asking though is uh what's the problem with road maps I'm just trying to figure out a short way to answer that um if you're interested the book inspired starts with that actually uh and you can Google it uh article called Product fail that kind of summarizes that but the fundamental first of all there doesn't have to be a problem with road maps but in other words if you're a good product company and you are doing product Discovery and afterwards you put what you're building on a roadmap that's that's just a simple useful communication tool but in 99 out of 100 cases or so that's not how the roadmaps are used the roadmap is done instead of product Discovery and that is a whole different topic it's one that all the good product companies understand it's you heard me say the first principle know what you can't know a road map in the old way is created by people who are so arrogant they don't know what they can't know they think their features are going to work they think they know how much it's going to cost and just by the way since so many of you are agile coaches they think ridiculous techniques like story like uh um story Point estimation is how you're going to figure out what's going to be involved in building something that's just that's so amateur and it's time to step it up if you're going to help serious product companies you need to do way better than that should we grab another one from Manuel one of the major problems I'm struggling with in my pursuit of trying to implement a cultural continuous Discovery Etc is product designers and PMs to claim that we cannot release before we have reached a certain minimum feature set because you never have a second chance to make a first impression and will ruin customers opinion if we release too early I think you would like that one yeah I mean that is a good question that's not unusual that debate has existed forever mostly what it tells me though is this is an organization that needs some education on the techniques and Discovery so what another way of framing that question Manuel is that there are some risks what you're saying is that we don't know remember I said there's four risks in product Discovery all the time value usability feasibility viability what they're saying is we don't know we have to give it our best shot and by the way in a lot of companies it's true you only get one shot not because you know the first chance to make a one chance to make a first impression or whatever it's not because of that it's because management doesn't put it on the roadmap for another iteration so you literally just get one shot that's um that's all describing a company that doesn't understand how to do product Discovery because product Discovery is all around addressing these risks so what you're really saying in that question is we're not sure if what we have is going to be perceived as valuable enough that's what you're saying if you were sure it was going to be valuable no problem go to market if you're not sure what do we do it is true that sometimes companies way overdo it and they over engineer in order to do a simple test in other cases they will they worked for four months on it's known as the four-month MVP and they push live a piece of crap and nobody wants it and then nobody is interested in doing anything so that's they can each be true so what we do in product Discovery is we will test on a limited set of users a little bit limited set of customers and we will make sure we have evidence about the necessary value before we even have our engineers build it so the main thing I know I sound like I'm trying to sell books man well but that's why I wrote inspired because I kept meeting teams that thought what this team you're referring to is thinking and they don't understand no we have really good techniques for doing this Manuel do you have a comment can you eraser yeah I I do have a comment because actually um at least that's my interpretation of what I'm observing in my company is that there actually it's the other way around they're overconfident that they know best so I'm in a context where we're selling software to musicians and a lot of our product designers our musicians themselves so they have this attitude of I know what's best for my product so I know what to build well by the way that's a really common problem uh that they think they are the customer um you heard you saw on that Spotify principle of close the distance between your real users and your team it's the same thing even if you have somebody who knows the domain really well that is not a substitute for putting in front of real users and customers and that is so easy to do so now if what's really going on is there's some arrogance there right the product manager thinks they know and they and they might be right but they probably are not um even if part of what they think is right A lot of it won't be so you need to force the issue of putting it in front of real users quickly good companies often use the heuristic of put that idea in front of real users in no more than two weeks not two months not four months no longer than two weeks because you need to learn what you're right about and what you're wrong about the other thing I'll say Manuel is because this is a really important point is it's easy to know too much about a domain um we did you notice I know another company in Sweden since we're talking about uh so much about Spotify just down the street from Spotify is a company called klarna that you may know Clara is one of the leaders in a space called buy now pay later it is basically disrupted the credit space it wasn't just clarna it was also after pay it was also a firm these different companies invented a new way of doing credit it's pretty remarkable that none of the credit companies came up with that innovation why because they thought they knew the rules of credit now this may be the problem too if you pull somebody from the music industry they know how it's always worked but they might not know how it should work or could work the biggest thing I would say number one make sure you are testing your ideas with real musicians or whoever it is but also the biggest single thing even more than that make sure the engineers are there because of this you know you just gave me a little clue that this product manager is pretty arrogant one of the signs is they don't think they need to talk to customers a bigger issue is they don't think the engineers need to talk to customers and and consistently this best source of innovation are our engineers great so Cara you have a question do you want to jump on stage pose the question let's see maybe I can go ahead oh you're Mick it's not working all right uh I can read it in an organization where Engineers are separated from the customer by multiple later layers of product and management what are the ways to help people in those layers understand that they're getting in the way so what we just talked about it is very much what we just talked about um and I think it was yesterday uh or maybe no it was Monday Monday I published uh my latest article which is called um the foundation of product and one of the things you'll find as one of those first principles in good product companies and you can absolutely see this in Spotify is that there are three things that are simply non-negotiable for that squad or cross-functional product team one is direct access to the actual users that's what we were just talking about direct access and I was emphasizing by the engineers too so product manager designer and Engineers number two is the product manager needs direct access to the stakeholders so the people who are responsible for sales marketing Finance um privacy security any of these legal product manager needs that relationship because coming up with a great product is both something your users and customers love but also works for the business and then the third is that the product manager and the product designer with this one is within the team the product manager and designer needs daily access to their engineers and you can't have anybody in between any of these three and just to not to beat a dead horse but but safe is not set up this way it's set up quite the opposite so that means that means Cara that you need to make sure that your engineers have direct access you need to make sure your product manager designer has direct access and often there are people that wanna you know they're usually well-meaning people uh you have a customer success team and they say it's our job to do that or you have account managers and they say it's our job or there's nobody at your company that's in the way but when you talk to your in a B2B context you talk to the company you're trying to sell to and they say oh you have to interact with our I.T person here because they're the ones that manage the vendor relationship and they'll talk to the end users none of those are acceptable and in my article I said if product is always about picking battles this is a battle worth fighting you need to make sure you have this access otherwise you will very likely fail uh and I can't say that about that many things I really think this is a make or break thing so Kara this is essential now most of the time a little education of the CEO and you're done and I will say there's very few companies that don't really don't understand this now the problem the biggest single problem is process people they think that there's a different process like safe that you should be following and this is not part of that process that's why connect jobs yeah go ahead yeah we've got a question from Helena beyond the do you want to jump on stage and post a question regarding to scale I can't try can you hear me perfect yeah let's go okay so I'm curious about when you have really large systems like designing a car when you have all of these teams coming together to create one product in the end yeah um I don't really want to use the watch scale but I will do it anyway what would your can you elaborate on on how would you recommend that you sort of do the working together to make sure that we get one chord in the end yeah well by the way I mean that's what Joe Justice talked about too he was describing Tesla building a car in a very uh you know extremely uh rapid Innovative collaborative way of course that was the way there's a little religion involved in every company and you may know Tesla is very high on co-location so they've kind of defined their model around that um anyway we can talk about everybody's but the real answer to your question and I I like that question because people don't understand this and and In fairness this when I first met Spotify this is what they wanted to talk to me about this question because they had already figured out how to empower product teams cross-functional teams and they were doing amazing work but if you remember early Spotify do you remember what a Frankenstein it was do you remember how like oh my God I can't just I can't even subscribe for my family plan it's like a little bit here a little bit there it's all over we call those products Frankenstein products where each team is doing beautiful but nobody is making sure it was really coming together no company I've ever met does that as well as Apple by the way which does what you said every day they I never saw a company do it at that scale so consistently but the answer in all of these companies the answer is this is what leaders do this is what leaders are supposed to do and I mean leaders product leaders the head of engine the leaders of engineering the leaders of design and the leaders of product for example when you you know I just got a new pair of the uh Apple earbuds and all I did was open the device up and all of a sudden all my other devices recognized it did the right thing how does that happen most companies even if they're way smaller than Apple can't do that how do they do it because they have literally designed managers reviewing the designs of their product teams and me and telling teams like okay this is good but it's got to work now with this and there needs to be we have to have one way of doing this so the leaders play a major role in fact I I should have been quote included this quote it's something I say is all the time I try to emphasize is an empowered organization does not mean less leadership it means better leadership because addressing what you're saying is that you know the other thing I would mention to you is um because it sounds like you're working on a large hardware systems I love those kinds of products by the way they are some of the most fun products in the world but there's a new book out that I absolutely it's my favorite of the genre which is called build it's by Tony Fidel and he's talking about how the iPod did this how the iPhone did this and then his own company how the Google Nest device did this or the nest device which was bought by Google and so you can get a good insight to you know he's talking about it more from the CEO perspective but it's really good so yes the short answer is this is the job of leadership okay thank you sure perfect we got a question from Zoran yeah thank you very much uh it's so nice hearing you Marty uh I have a question for you we have just started working with empowered teams in six months ago and we see teens really thriving but my question to you is teams that are not really there and what you see who do you see needs to lead them like in the beginning before they become this mature empowered teams if the culture and the organizational structure and the Mandate is already there uh we're trying to figure this out and see you know how we can go about it and I'm just curious on your your view on it good all right well the short answer is this is the job of the managers to coach so and it's normal by the way that you know that for any given team you have to look at this on a squad by Squad basis you don't really want to empower a given product team until they're ready because then you you would risk setting them up to fail and that's very dangerous we don't want to do that right we want to make sure they're going to succeed Now setting them up to succeed means making sure you first of all that you have this cross-functional skills on the team I a lot of product teams I meet they literally don't have the product design skills and then the single biggest issue I see and I already said this I don't want to overdo it but they have a product owner that's not skilled as a product manager that's the biggest and I will tell you that the number one reason empowered teams fail is because they do not have a competent product manager and then the stakeholders don't trust that person the CEO doesn't trust that person the engineers don't trust that person so it all falls apart but who's responsible for getting them trustworthy their manager in fact Ben Horowitz who's uh the partner for Mark Andreessen Ben worked at Netscape as well as one of the best product Minds I've ever met Ben likes to say the single most important role non-sea level role in a company is that first level manager of product managers because they're the ones responsible for making sure every team has a capable product manager great answer thank you very much I really will take with me the thing that if they're not ready to be empowered we shouldn't Empower them it's a key takeaway thank you okay great question from Helena relating to products and services do you want to jump on stage and add some color to that question otherwise I pose it so uh could you please elaborate and help oh no so that was wrong it was Ingrid it was Ingrid sorry I I mixed up the names so Ingrid what would you tell the bank that was wants to make all the services uh that support their actual products products so uh Ingrid you want to add some color to that question sorry I couldn't find my uh unmute um yeah so this bank that I'm working with has their heart in the right place but obviously I mean they're doing all the wrong things so I'm sure to work for a while here but I'm trying to help them understand that the services that are component parts of their actual products are not products and they're trying to make them products so I I've tried everything I can think of to help them understand why they're not uh and I just thought maybe you would have um maybe a pithy take well first can you clarify for me most of the time at a bank we talk about two kinds of things there there are products like a savings account or a checking account and then there are products like online banking that lets you modify those are when you say service do you mean the checking account or do you mean something different no I mean the actual uh services that support the uh the product in this case it's it's loans commercial lending alone alone so alone is a problem right but the services that support that so for instance uh e-signature you know DocuSign um yeah uh I can't think of what the other things are now um all of the tools that they use to uh pull together the data for each of the borrowers but you're saying you don't see that as a product well so maybe I'm wrong but if the loan is the product why would we productize all of the components of that product well you I mean you're kind of I think getting confused because of the language um so and once you were looking for a pithy way I I have quite a few I've talked to quite a few Banks actually and you know Banks finally thanks to stripe they're all scared and now taking product much more seriously so that's the good news uh because they're long overdue but one of the things I often tell them is just just look uh if if it if we were Amazon if Amazon was going after your customers how would they think of this it would all be it's all the product all of it is the product alone is a part of that product just like when Amazon sells books the book is part of that product they call the book the merchandise just like a bank might call the loan the actual the loan offering that loan product but everything around that loan and you just gave great examples electronic signatures uh balances payments all of the things around that loan that's what product does that's what product is and our job is to create you know the best experience around that loan product now that's the easy short answer and that's kind of stage one stage two is to say look how can we use the data we're collecting from this hole to actually make better loan product and that's happening in the insurance industry it's happening in the loan industry it's happening in lots of places and that is really what Amazon would do um that's what they are doing like look at what they're doing with an online pharmacy sort of Reinventing the pharmacy they're not just thinking of it as oh well there's a pharmacy that issues prescriptions and we do things like payment they do a lot more than that yeah okay that's very helpful I appreciate that you bet okay let's take the last question from Malta are you ready to unmute yes thank you thank you very much thank you Martin great to be here uh and great to have you my question would be as follows so uh when you look at ITIL implementation I'm really sorry that my camera is not working but when you're looking at ITIL implementations and service providers I often see layer up and layer of portfolio managers stacked upon each other in front of the service owner and to defend this move by saying oh no we need to Shield our product owners from the craziness of our customers um and it's really uh difficult to break through there and break this 30 year old habit of layer stacking well look uh they need what's called an intervention um they are so far broken that way of thinking and you said it by we need to Shield our product owners from the craziness of our customers there is nothing more wrong than that statement right there and so what's going on is their leaders now they probably have some CIO that has no clue they're probably running one of those formal processes and that's the model so they they need an intervention now that might only happen if they decide that they have to change that's one of the challenges for coaches is if a company doesn't think they need to change it's very difficult to get them to change but that is a you're describing a very broken company and they need you know somebody needs to sit down now one of the challenges coaches often face is the agile coaches often face is that um they're not the people they really need to talk to are the CEO but the CEO is not going to talk to the agile coach so that's where it falls down the CEO needs somebody to work to talk to that's why they go to so often the places like McKinsey and Accenture is because they feel like they can talk to that person unfortunately those companies don't really know what to do they want to help and they want to charge them but they don't really know what to do but yeah I have to say that it's Accenture that's what I said Accenture has no idea about this stuff yeah okay thanks a lot thank you sure okay thank you so much Marty for this interesting session all right just like you said [Music]