Lean, Agile, & Design Thinking by Jeff Gothelf at Mind the Product Singapore 2019

[Music] [Applause] [Music] hey folks good afternoon you made it one more to go and once again once again I find myself in the unenviable position of being between you and beer all right but to get through this I'm gonna tell you a lot of stories I love telling stories my kids my wife I kind of fit up with that but you kind of have to listen to my stories so I'm gonna tell you some stories about that I want to start with a story about my favorite movie okay I love movies my favorite movie is Goodfellas okay how many of you have not seen Goodfellas just might get a sense do we have like two hours take a break watch it well watch it it's great movie Brunt's with 25 years old now which which is really um kind of depressing a little bit this is my favorite scene in them it's a gangster movie if you don't know what it's got an all-star cast it's got DeNiro I'm sorry stuff it's got the Niro it's got Pesci it's got Ray Liotta and this is the this is my favorite scene this is um a late-night meal that's happening at Joe Pesci's mom's house now what's happening in this scene is De Niro Pesci and Ray Liotta have a problem in the back of ray Liotta's car it's in the boot it's in the trunk and they're stopping off late night at Joe Pesci's mom's house to get a knife big knife so they can solve the problem that's in the back of the car now they get it's it's late night they make a little noise in the kitchen she wakes up it's an Italian household so of course she invites them to eat they sit down they have a meal doesn't matter that it's midnight or whatever it is and through the course of the conversation of the discussion over dinner the conversation turns to this which is a painting that Joe Pesci's mom painted and as they're passing it around Joe Pesci says one of the most iconic lines I think in a movie filled with iconic lines and I actually have the clip here's 30 seconds long this is this is what he says listen my painting so what and this guy's saying what do you want from me great one Doug on one way one Doug going the other way he has the middle saying hey what do you want from me why was this relevant to anything that we're talking about today what's that fair question okay here's how I was having a conversation with a client of mine in in the US and this this gentleman was in charge of transforming a division of the bank into kind of a modern digitally powered banking division and he said this to me he said look I'm trying to get my team's to work well together I got I got my team's learning agile one-dog going one way right I got my product folks started learning lean and lean startup in those types of things I got one dog on the other way he had a third dog in the race it was the design team which was good I was happy about that he's like I'm teaching them design thinking and he's like where is the magic the synergy these the the shared understanding the vocabulary that we're talking about the the cadences and the promise of these processes it's not happening everyone's speaking a different language everyone's working at a different pace everyone's working towards a different goal and I'm here in the middle saying hey what do you want from me right I trained everybody in all the right processes right this is what I'm supposed to be doing and this really got me thinking about these these processes you heard a lot about frameworks right how do we actually figure out which one of these is the right one right is there a right framework is there a right process kind of following up from from Jen's talk now the reality is this if all you have is a process hammer if that's the tool you have to solving your problem right everything looks like a nail that we can fix with agile or with design thinking or with Lean Startup right and this is an interesting challenge for organizations particularly large organizations and legacy organizations that are trying to become leaner faster more efficient now it's fascinating about that is that generally speaking startups don't have this problem right startups have a limited number of people they have a limited runway they have limited time to make mistakes so they work very quickly and they try to find that product market fit that allows them to scale and to grow they don't worry too much about whether they're lean they're agile they're designed thinking all of those things but some startups succeed and if they start to grow and become bigger companies right the problem starts to become more acute right we start to hire people we start to hire specialists we start to build bigger teams and the questions start to come back well which process should be used right should we be agile should we be lean does it really matter we're big we're successful right we can't possibly lose at this point it's particularly true of of large multinational corporation and so they continue to work without really trying to solve this particular problem assuming that because they're big and because they're successful what got them here will get them there will continue to move them forward and allow them to continue to grow and yet every organization that I work with and I work with large companies primarily meeting size and large companies they all say the same thing they got these talking heads in the background saying we want to be lean we want to be agile John talked about this morning right the the startups want to be end ups the end ups want to be startups right how do we actually come recapture that spirit of being lean and agile and as they as they head out as organizations head out to try to figure out what's the right recipe what's the right framework the reality is that there are no shortage of recipes for you to choose from as leaders of transformation as builders of products as makers of digital services for rekindling that innovation that agility that efficiency in your organization in fact one consultant try to put it all in one chart yes listen I I feel for this guy he took a lot of heat for this chart and look this is a horrible chart and and but but it's not horrible because of the aesthetic choices that the gentleman who made this chart made right this is what you're looking at here if you're not familiar with that this is this is an attempt to map out with a kind of a London Tube map aesthetic the the agile landscape all of the things that you could potentially do to improve the way that your team is working you could choose to do every one of these stops on here is a practice a method philosophy a tip a trick you know everything's on here everything design Sprint's Kanban xp5 wise you name it it's on there and if you are in a position where you're trying to figure out what framework works for us how do we actually build the kind of organization or recapture the kind of organization that we used to be and these are your choices I don't blame you if you feel like this the first time you kind of head out to try to figure out what to do all of this and in fact most larger organizations I don't know if that's true in Asia certainly in in in the US this is everyone's favorite right now it's at scale this if you're not familiar with this this is the scaled agile framework which has lots and lots of big beautiful diagrams and executives love this and they love it for a very specific reason it's because they can see themselves in the chart and they're at the top and that means that I don't have to change I can tell everybody below me what to do and most recently you know safe trying to kind of broaden their perspective on the world a little lean UX into that so you know I like it another you right again you can't just add words into a chart and make it make it actually work in the real world so let's talk about this for real let's get very specific about these three things agile lean and design thinking and then I want to talk about kind of ways to actually meld those processes into a good way of working so what's a Jalal about what agile came about from 17 software engineers frustration about 18 years ago they were front these 17 software engineers were frustrated with the way that software delivery was happening they it was taking too long they were missing deadlines projects weren't shipping they simply wanted a better way of working and so after a long weekend on a mountaintop in the western United States at high altitude where the air was thin they wrote the agile manifesto they descended biblically from the mountain right we have written this for you right now look the reality is this it's caught fire right it is religion and I could chuck your companies all over the world right and look and if you read the agile manifesto in which most people have not there's actually not a whole lot in there about process it's really more about a philosophy of working there's nothing in there that says you will stand up every day at nine fifteen or fifteen but it's not there it's not there in fact what they're basically saying is what I tried to summarize here in this tweet write it if you're working on a team right softer development is complex as we learn new things if we change our priorities if we change our our plan based on learning then we're being agile that's basically what the agile manifesto says right as you discover new ways of doing something or where you were wrong and you change course that's being agile right that's responding to change over following a plan but sadly what's happened in the real world is that organizations have hired to use the jobs to be done language have hired agile not for learning not for course correction not for agility but for the efficient delivery of high-quality code for the production of software because for some reason there's this belief that this is what engineers need to be doing all the time right and and God forbid a software engineer stops writing code for just a second right and it's it's a it's Apocalypse it's the end of the world right and and really the thing that we are managing our teams for most organizations when they're managing their agile teams is this it's cranking out the software right let's just get those features out the door because there's this belief that if we make more software we deliver more value well look we have got to get out of this software factory mentality we've got to figure out how to recapture the spirit the original spirit of agility that we're looking for because the reality is that more code doesn't equal more value it simply equals more code and so we have to change our measure of success and that's the thing we're gonna talk about next because at the end of the day right just because you can build it doesn't mean that you should build it right the airplane that I arrived here on had seven fewer wings than this one and it worked just fine right yes and yours did too so let's think about how to recapture how do we recapture the the brain on this agile process well lean does a really nice job of this right lien says look we have got to rethink how we deliver goods to people right traditionally goods have been manufactured as a push process we're going to produce a hundred thousand units we'll push them onto the market and hope that people buy it that's risky today we simply can't take that risk let's flip that on its head let's build a pull model a pull model says that we are going to look for signals from the market to tell us how many things to make and then we are only going to make that many things because we can't predict the future and we don't want to congenial Ong the way we are going to empower the people closest to the work to make the most critical decisions that's roughly what lean was saying very very quickly a lot more there but that's the kind of a 30-second summary that I'm gonna go with today now the principles I want you to take away are these first of all you can't predict the future okay you can't and so you're always moving from doubt to certainty and so to reduce the risk of going too far down the wrong path we work in small batches sprints for example or a small batch and at the end of each one of those small batches we pause and we reflect right what did we learn does it still makes sense to go this way if the answer is yes we take the next small step forward not the next nine small steps the next one and if the answer is no then we have to change course okay these things start to come together nicely now Lean Startup comes along and really starts to apply this to technology in a meaningful way that's broadly accepted Eric Ries writes the Lean Startup and he says look everything that you're working on is an experiment right you can't predict the future you're trying to answer the question not can we build it but should we build it and we're looking for these early minimally viable iterations of our product sounds great right except if you've ever had a boss or a client asking you to build something for them no one wants to buy experiments right people want to buy products systems solutions to these things right and so then how does that fit into all of this well bringing our friend design thinking design think he's gonna solve this right if it's not Lean Startup and it's not exactly lean and it's not exactly agile this must do it right now what is design thinking well the most people this is design thinking right this is the world that we live on right and you're not doing it unless it looks like that right to other people this is design thinking right just really just you know I da ting by the lake so just watch this for twenty more minutes Design Thinking is simply taking the designers toolbox right and applying it to solving business problems right and you've heard a lot about that today you heard Bernie's talk about it right the same exact thing this idea of empathizing with the people that you are you're solving problems for defining the problem I da ting prototyping testing right sounds familiar right guess what it fits really nicely into that Lean Startup loop right that's the learn part of build measure learn fits nicely and then what we try to do is take these two things that seem to fit well together and mash them up with this agile process now the philosophical version of that agile process should work cleanly but the reality the way that's applied today leads us to situations like this basically these Frankenstein processes that don't work for anybody right just like my my client at the beginning of the story right we're doing all of these things and it doesn't work so how do we solve it well fundamentally we've got to move away from this concept of integrating processes right it's not fitting lean into agile into Lean Startup into design thinking but it's looking for the principles that underlie these ways of working right what are the the agile philosophies right the Design Thinking philosophies and figuring out how they apply to the way that we do product development work digital development work now look I have got ten principles for you to consider about how to change the way that you work and I've got examples for each okay so I'm going to move through them relatively quickly and then if you've got questions catch me at drinks okay let's start with number one principle number one customer value and business value are the same thing okay most organizations try to optimize for short-term business value but if you make your customers successful if you respect their time if you create delightful experiences when appropriate for them if you solve real problems for them in meaningful ways they will reward you they'll buy your stuff they'll tell their friends they'll buy more they'll buy repeatedly from you they'll be your biggest advocate all right let me share you a story that I love I learned this one online Gibson guitars is out of business bankrupt gone a hundred years really really sad why why are they out of business well they went out of business because the guitar buying market shifted and Gibson panicked they brought in a new CEO who was an advocate of innovation innovation for innovations sake not really thinking through what the real customer needs were but hey let's invent all of these new gadgets and let's hope that people continue to buy our products as they always have for the last hundred or so years except it didn't work right what they fail to realize was where the customer value us it turns out that the market for guitars had shifted radically in in the make up of guitar buyers it has actually turned to be about 50% women these days and it turns out that women guitar buyers not all of them but a lot of them right they don't care about kind of legendary guitar gods which is what the gibson website looks like right what they care about is how to play guitar can you build an instrument that I can learn how to play guess what Fender guitars attention this is the Fender guitars website they're thriving while Gibson's out of business because they're delivering customer value they understand the market they understand the needs and they're selling instruments to women and then teaching them how to play right and they're building an experience that's welcoming that's inclusive to this new relatively new growing guitar buying population right and again this is about how you tell your story sharif told us right the power of storytelling earlier today right fender is telling a story we're listening to you we care about you and we're building products and services for you and what we've got here are is a user centered perspective on this right our success comes from paying attention to the market and our measure of success changes from creating the thing hey we innovated and made all these gadgets so the change in customer behavior that we want to see that tells us that we've actually met a need for our customers we call those outcomes and you've heard a little bit about that as well outcomes tell us when we've delivered customer value right because people have changed their behavior and to be very clear outcomes tell us when we're done right shipping the product is the beginning of the conversation the change in behavior tells us when we're done let me put a fine point on this okay who knows what this is call it out rotary engine exactly this is this is the the rotary engine a complicated piece of machinery that if you took it apart wrote down the specification and gave it to any qualified person anywhere in the world they would reassemble it and it would look and work exactly like that this is in theory a far simpler system right a little bit of asphalt maybe some sidewalks a couple of street signs that's about it if you were to recreate this anywhere else in the world it would not look like this it wouldn't operate like this if you were to recreate this in Stockholm or in Sydney or New York or Barcelona anywhere like that it doesn't work like that why because outcomes force us to understand the context of use for our products force us to understand who the customer is what matters to them and how they'll interact with the systems that we build for them right we can't just blindly deliver our products to a new market and hope that they work you heard that in the panel earlier today outputs versus outcomes now the interesting thing about all of this is that outcomes change how we plan how we budget and how we prioritize all of this work and again you heard this over the course today right a man is talking about hey why are you micromanaging my feature right because I've got a sense of the kind of behavior that I'd like to see in the customers over time and what we have to do is start to change the planning conversation from I'm gonna build you these 15 features - I'm gonna start to change customer behavior over time in our roadmaps have to change lots of conversation on roadmaps at the conference over the last two days we want to start to think about what are the behaviors that will help us achieve our long-term strategic goals and then really think through what we might want to build for our customers over time because we don't know we can't predict the future and as we start to put these things in the market we start to learn what works and what doesn't and that may change our planning downstream right and there's an increased fuzziness a fogginess if you will that takes place with our roadmaps as we look out further into time this is driven by the complexity of humans the unpredictability of their behavior and the fact that our measure of success changes from we made the thing - we actually changed behavior do you like the fog that's number one I spend a lot of time at principle number one because I think it's the most important one managing two outcomes principle number two working in short cycles right we think we can predict what it's going to look like when it's done and then we run out of time we got to hurry up and finish it right when we ask when we either attempt to or ask our teams to predict the future this is what we're asking them to do asking them to simply make their best guess to try to divine what it's going to do what it's going to cost and what it will work and that is a risky way to manage our product instead our goal is to make evidence-based decisions right as we put ideas into the market what are we learning and then how do we change course and some of the biggest companies in the world are doing this right and you know we want from those fact-based decisions ultimately to overrule the hierarchy right this is where that conversation on humility comes in right I have a strong opinion about this but if the evidence disagrees with my opinion it should overrule it right that's what we're looking for and ideally we're collecting evidence as we're learning right this is a chart called the truth curve created by my friend gift constable in New York and a book called talking to humans the idea is that the more evidence you collect the more you get to invest in your idea and if you have no evidence if you just have a cool idea that you haven't even tried at all you're over here in the land of wishful thinking which means that you get to spend the least amount of effort possible and as you work in these short cycles and you learn and you start to get positive feedback you go up the truth curve which means you get to spend more and more and more justifiably invest more and more in your product in your idea and if at any point the feedback turns negative you stop that investment and you reconsider whether that's a good idea or a bad idea to be clear anything you do underneath that green line is stupid and it's stupid because it's unnecessarily risky you don't have to take that particular risk right as the maturity of your product grows over time you'll notice right you're looking for products solution fit first and if that starts to happen we start to look for scalability for product market fit and the questions that we start to to ask begin to change over time and these short cycles help us determine when we stop asking should we build it and when we start asking can we build a business around it right and the evidence tells us whether or not we continue to be very very clear there are two key questions I want you to consider as you work through that truth curve of increased investment the first question is what's the leap what is the next most important thing that you need to learn not what's the next most important thing you need to ship but what's the it's riskier facing next that's the next most important thing you need to learn once you've identified that then you ask what is the least amount of work we need to do to learn that thing right and that's your level of investment that's your experiment that's your next learning activity and these short cycles help us move forward that's principle number two principle number three this one seems obvious but this is one of the agile techniques that really makes a difference holding regular retrospectives and again I don't really care what your favorite format of retro is what you think is is working for you and whatever it is at the end of every cycle pause and reflect what worked with the product that we're building improve the product move that forward what worked or didn't work with the process that we're using improve that and move it forward again short cycles continuous improvement continuous learning these are really good qualities that come from agile that drive our agility principle number four go and see this one comes from lean right going to the gemba going to see what's happening what people are doing how it's working whether it's your customers or your team there was a kind of a different interpretation of this created by management guru Tom Peters he calls it managing by walking around managing by walking around simply means that as your team is working walk around and see what's working see what's not working right don't be this guy right find the patterns that are working for your team's the techniques the tools whatever it is the processes that they're using and then amplify those patterns regardless of whether they are lean if you can say they're from lean or from agile from design thinking it doesn't matter if it's working within your organization it's making people efficient productive they're learning and they're doing good work amplify those patterns principle number five test your high-risk hypotheses we talked I heard a lot about hypotheses today in fact Ken told us about the history of hypotheses to have had them for a long time right the idea is that we position our work as a testable statement with the measure of success being an outcome being a change in customer behavior hypotheses force us to tell ourselves stories that we believe before we actually tell our customers those stories in other words if you cannot this is my template for hypothesis use whichever one works for you but if you cannot complete this template the orange parts and brackets in a way that you believe that your team believes that's a good indication that you should not be working on that feature or that product or that solution right here's what it looks like kind of completely just to give you sense of what this looks like right so we believe that a 50% increase in retention will be achieved if parents of school-aged kids successfully know that their kids are safe with a location tracking movement alert service that feels like a compelling story you might want to push forward and try to test this right that's the first hypothesis statements are perfect for that should we even be working on this once you've got your hypotheses in place the realization is this you can't test everything right you got a ship software some time to write our budgets very few of us if any are lucky enough to have nothing but a learning budget we actually have to ship stuff too which is good we want to get stuff into users hands and so we focus on the hypotheses that we believe will deliver the most value and have the highest level of risk now risk is gonna be contextual to your hypothesis right it might be some technical risk whereas we have to integrate a modern system with a legacy system it might be a design risk we're gonna reinvent the way that people do e-commerce with augmented reality right they may not figure it out it could be market risk we've been building products for a certain market or demographic for a long time and now we're shifting to a new one right these are all the risky elements that you have to consider the hypotheses that end up in that top right hand corner high perceived value because we don't know that it's valuable and high risk those are the ones you should spend time testing that's what your experimentation your MVPs that's where that work goes okay principle number six do less more often right this is again it builds into these the short cycle thinking it doesn't mean we don't do all the things that we want to do we just take smaller cycles smaller slices of those and we do them more frequently right Prakriti told us earlier 62% of you write the product manager audience can't do proper research can't find the time to do it right and there's a good reason for that right if we still imagine that research looks like this which is what it looked like when I started my career right you sat behind the glass for two days eating candy watching 30 people come through knowing exactly what every single person after the fifth person was gonna say right it can be wasteful and so again how do we do less of this but more often we ask ourselves questions like what's the fastest way that we can learn the most important thing and then we do just that little bit move the conversation forward to the next question and we do that with tactics like product discovery right there's all kinds of techniques and examples of product discovery I've got two examples for you here this is one of my favorites came across this one recently I don't if you know what's happening here but I'll tell you what's happening here this is Ford Motor Company forward Motor Company disguised a man as a car seat to research self-driving cars and Ford Motor Company's with building cars for a hundred years right why would they need to research this they know how to build cars well there's tremendous risk in all of this why not just build a car and see what happens right well they need to learn some very important things so they dressed the guy up as a car seat and they put him behind the wheel of a car and then they put him on the road right and again the question is why would they do this a hundred years of car building experience this is just the next evolution we got this right nope we don't why because we don't know how people are gonna react to this thing right no one has ever seen a self-driving car before we don't know how to write the software to react in certain situations we don't know what kind of hardware is required to do that the least amount of work that they needed to do to learn the next most important thing was to do that to fake a self-driving car so that they could learn how people would react I recently worked on a project with a team in New York that was doing EDX software they had to reinvent how they were coaching people through specific educational tasks they managed the whole thing in Trello this is what it looks like just to give you a sense the whole project was mat and managed in Trello with humans delivering the service the customers had no idea what was happening they put this together in two weeks where would have taken them six months to build a beta version of the service they put it together with humans and Trello and to email in two weeks do less more often you learn faster you change course you be more agile you become more customer centric principle number seven work as a balanced team you heard a lot about teams today lots of conversations about cross-functional teams I love this case study this is the case ad from Westpac does--he from Australia no Westpac Westpac is the oldest company and the oldest bank in Australia one challenge that this bank faced at one point more most recently was to change an outcome it takes five days to get a credit card over the course of those five days we lose a lot of people right and we lose five days of spend as a business can we take that from five days to five minutes right the only way that they could actually build a system like this it's not like this they could hand it off to an engineering team or a design team or a marketing team they had to build a dedicated cross-functional team now in this image right now right you've got Dan who's the head of design or he was out of design at when this photo was taken right and he's leading a team of people from risk compliance engineering and marketing through the customer journey that they're imagining and everybody that's participating in this they now understand what they need to do to make this new experience come to life right we want to build these small dedicated self-sufficient teams that are empowered to make decisions based on short cycles the short cycles reduce the risk we learn faster and if we're wrong it hurts less the shared understanding that the teams build allows the efficiency to come through because these folks don't have to have wait for Dan to write a report about his customer journey they just walk up to the wall and they see where their piece fits into that puzzle and again we heard that today from John this morning as he was clarifying that scandalous interview and Fast Company right when we place a focus on the customers need which is what we're doing let's get the customer through the process that much faster and work as a team to satisfy that everyone wins together and there's a little bit of extra here which I want to share from my past as well when you build these dedicated small cross-functional teams sometimes you inspire creativity in people simply by being there this is an award that I received from my engineers almost 14 years ago at this point by simply by collaborating with them they called me the rogue developer right because design was still kind of a relatively new thing and we inspired new creativity simply by working together as a dedicated cross-functional team again amazing synergy comes from those things number eight radical transparency again you heard a lot about transparency and clarity this morning when the benefit of this transparency builds trust transparency builds alignment and vision it builds that shared understanding that we need to move forward and so the question becomes how do we get that transparency well rituals are really good I told you I love movies Karate Kid the original Karate Kid it's one of my favorites you guys remember this movie you know Daniel son comes to to the mr. Miyagi says I want to learn karate mr. Miyagi says that's great paint the fence but I want to learn karate that's great wax my car but I want to learn karate but he doesn't realize that he's going through the rituals right he's actually learning karate the kind of rituals that I want you to think about come from the agile and lean and lean startup world stand-ups for example stand-ups Drive transparency every day you have to stand up in front of your colleagues and talk about your work right what did you do yesterday well yesterday I bought a pair of shoes online yeah and what's getting in your way all this work I have to do gets in my way of me buying more shoes online right that's gonna get old very very quickly right demo days are fantastic way of driving transparency here's what we're doing not just the code that we're shipping the experiments that were running the customer conversations that we're having this is what we're learning from them right proactive emails if you heard Amanda's Q&A upstairs earlier right she was talking about teaching an organization about product by sending an email no one asked her to do that she just generated transparency for her group by sending out those proactive emails that's the kind of stuff we're looking for that drives transparency access to customers drives transparency literally just just the other day I was working with a client they're like I can't talk to my customers I find that impossible to believe get creative because your customers will tell you what aspects of your products are viable you might decide what's minimum but your customers tell you what's actually viable and they keep you from doing stupid stuff like this okay building $700 juicing machines that extract delicious juice from $8 juice packets that it turns out you can just get it out with your hand right you don't actually need the $700 juicing machines right access to customers drives the transparency and helps us understand why we're working on something right and again this was we saw Bernie's talk about this as well as she's talking to the people who are struggling here in Singapore we understand why they're struggling and we get a sense of how we might fix that for them it drives transparency into our target audience as well another and final tactic for transparencies access to data data should be a utility where you work in the same way that we give our people Internet access computers coffee Hawaiian t-shirt Friday's whatever it is that we do we give them access to the analytics this should not be an exercise in rationing which I've had to do in organizations this should not be an exercise in trying to exert my position in the company to get more access to data all right everyone should be able to get to the analytics about what's happening because again that rise transparency into how well our solutions are meeting customer needs two more number nine reviewing incentives and performance management because your ass is on the line with incentives right how what are we managing our people for right and what are we what are we measuring in order to succeed it's fascinating the the companies that I work with are all doing some kind of digital transformation or agile transformation and they've got the language down they've got the ceremonies down they've got the the team names down and the thing they forget to do is to think about how they're paying their people and what they're paying them to do and I ask them all the time right what are you incentivized to do at work versus what are you being asked to do right we're being asked to be agile to be lean to be customer centric but in most cases were incentivized to hit the fixed time and the fixed scope projects on time and on budget right and as we all know when we do that only we're the only three results to fixed time fix go projects we didn't move the deadline we reduced the scope or the worst part is we implement we call the crunch mode where I used to work everybody puts in 80 hour weeks to hit the deadline they burn out they quit and they go work somewhere else not terribly sustainable okay last one last principle and this is very very important make learning a first-class citizen of your backlog I'll take this off before anybody gets a seizure the TLDR is this one backlog manage all of your work in one spot let me reiterate this okay there can be only one backlog all of your work goes in the same backlog development stories discovery stories design stories research stories those are called spikes by the way another agile technique that works really well and we manage that work in the same way that we manage all the other work as soon as you divide work into development work discovery work opportunity work design work one of those backlogs becomes the priority and the others get ignored and ultimately they just become confessionals right I'm really sorry we didn't do that work here's a car I'm really sorry we do that work that's generally how it works I'll give you one quick technique right your experimenter MVP stories on a card right talk about your hypothesis talk about your experiment talk about in the story card who's gonna do that work if you do estimations and I don't have enough time in the world to talk about estimations tonight right put it on there right scope it out and then put it in your backlog the same backlog where the rest of the work goes okay all of it goes in one spot we manage it together and all of a sudden the design the discovery of the learning everything other than writing code gets prioritized in the same way with the same people doing the same work so to wrap this up ten principles to bring all of these frameworks together lean agile and Design Thinking customer value and business value are the same thing working in short cycles hold regular retrospectives go and see what your people are doing amplify the good patterns test only your high-risk hypotheses do less more often smaller cycles more small cycles build those balanced cross-functional teams be transparent about everything don't be secretive about it review your incentive structures make sure we're rewarding people for doing the kind of work that we would like to be doing and then ultimately make learning a first-class citizen of your backlog thank you very much [Applause] [Music] you

Channel: Mind the Product

Views: 17,469

Rating: 4.9887638 out of 5

Keywords: product management, prodmgmt

Id: MesYt7PhLFQ

Length: 41min 7sec (2467 seconds)

Published: Tue Sep 24 2019