 So, let's see if it's projecting. Come on, come on. Computers never work when you need them. That's my kind of... Let's see, yeah, maybe. Good. Let's see, this is going to work. Come on. One, two, three. Yes, no? Maybe I need to leave with this one. Oh, source, come on. Okay, then I'm going to draw. If this doesn't work... Okay, good. So, we have lift up, good. So, I mostly work with kind of agile development and there was a big thing on Twitter the other day. There's a Mind the Product conference in London and there was somebody kind of standing out there saying agile doesn't do anything about the customer and everybody was kind of uploading and they were saying how they hate agile. I think, kind of, agile has this big branding problem at the moment, especially in the product community, which kind of, it started with this whole idea that the customers are driving the whole thing and now we've ended up 15 years later with people uploading saying, you know, agile is stupid because it doesn't do anything to customers. And, of course, kind of, you know, things ended up watered down and this whole, you know, safe thing now and somebody at the conference said safe is a shitty agile for enterprises. And a lot of that actually kind of ends up being a wrong perception. And impact mapping is a really nice way to fit in some really, really good product management techniques in Twitter delivery. And that's why I'm so excited about that. And I'll talk a bit about what impact mapping is and then what I really want to talk about is how Christian Hassa from Tech Talk in Vienna and I are working on these two new facilitation techniques that now that we are, you know, five or six years of experience doing impact mapping in various situations, we've kind of come up with two good ways of solving what I feel are the biggest problems when people start adopting impact mapping. And these techniques are useful even if you never want to do impact mapping in your life. I think they're still really, really good to try to and they will help you give you better products. So the first thing that I really want to kind of talk about that bugs me quite a lot is how we define success and what became success in our industry because I think that's completely insane now. Everybody's talking about kind of scaling up and larger teams, larger companies and things like that and kind of generally you can see on the internet cesspool that is linked in lots of these people who are advertising that they've done something massively successful because they've managed a five million project on time and on budget and things like that. And I see more and more kind of these people especially kind of those are the people that are really vocal against iterative delivery because they have a budget, they have scope, they have time, they're going to fight iterative delivery as much as they can so that they can declare this a success. And when you need to deal with somebody like that I'll give you one really good metrics, metric and a really good technique that you can use for that and for that I want me to volunteer that's going to help me kind of measure this metric and then you'll see how to do this for your project. So who's going to volunteer to help me do this? I need somebody with a really good mobile phone. I don't serve it. Not one of those explosive phones. We don't want an explosive phone. Why does it explode? I'll give my phone to anyone here. Here. Okay, let's serve. Let's see if you can help me. What's your name, friend? My name is Chris. Please applause for Chris. He's risking life for me. What's the phone? iPhone 6. You have a stopwatch on iPhone 6? I do. Let's see if the stopwatch is accurate. When you need to do something with people like this all you need is a good iPhone or one of those non-exploding phones with a stopwatch and somebody who's going to measure this and you need to find this clip online and measure that against the project. So I'll give you a link where to download this clip from and let's see if I can play this now. So are you ready to start measuring time? Good. So let's see if I can play this. I have stopwatch to start. Yeah. Three, four, start. Ready to go again. 22 seconds. Okay, good. Thank you very much. This was incredibly helpful. So here's somebody who says, you know, I've managed the project for five million or 10 million or, you know, on time and budget. You measure this stuff. So I'll add a couple of seconds for the stuff that we missed. So let's say, you know, 26, 27. And what we get there is kind of something that we can now compare to a project. And I'll use this project that I really love to compare stuff against. This is a UK government project that they spent 11 billion pounds before realizing they're not going to deliver anything. And they spent about nine years trying to do that. So all you need is kind of, okay, you spend this much money on, you know, this much time. And we know that this is kind of about two per minute that we can do if we kind of flush money directly down the toilet. So, two per minute gives us something like 120 per hour. If, you know, we're not taking a coffee break or something like that. I talk kind of with a normal working day, something roughly about 960 per day. And with all the kind of holidays and they, you know, free days and things like that that people expect and see, there is, that gives us about 234,000 flushes per year. Now, kind of, I, my company's in the UK and kind of I, you know, all my contracts are in UK pounds so we're going to use pounds for this stuff. And with pounds, I've never really tested this in person, but you can try if you really want a good measurement. I assume kind of Singapore dollars are going to be something similar. You know, 50 pounds is the biggest note we have. And I reckon about 20 of them you can put down the toilet and flush without clogging it. And that's an optimal flow, because if you put too much and then kind of the water starts coming out, then you need to stop and clean. And we know that from lean we need to optimize our flow. So, let's say that kind of we can do 20, that's about a thousand, which means that about 234 million pounds is what you can flush down the toilet per year, realistically. And kind of now if you go back to the budget for that project and you can see, well, you know, there's 11 billion of this and this gives us 47 years to just kind of flush the money down the toilet to achieve the same loss. And because the UK government's been able to do this in only nine years then you can have kind of this flush factor of 522. So, calculating something like that for a project where people say, you know, we've delivered this for 5 million or 10 million or something like that in time and budget and calculate the flush factor and kind of figure out what people are actually done. And this is where it becomes really interesting to think about what is success. Is success that, you know, we spend five years spending 10 million Singapore dollars or 5 million pounds or 11 billion pounds or is success that we actually achieved something and why does nobody actually measure up if we achieved something or not. And this is kind of, you know, it's been bugging me for a long time and there are some really interesting papers online for example, there's a paper by a guy called Ron Kohari from Microsoft who went and found the PowerPoints that launched some grand initiatives and actually kind of compared whether the stuff from the PowerPoint came through after the software was delivered and his conclusion was that about one-third of initiatives achieved a positive movement for the numbers that were supposed to improve. About one-third created no statistically relevant change for the numbers that were supposed to improve and about one-third actually damaged those numbers. So you can find this paper online if you Google for online experimentation at Microsoft and he talks about Amazon that is considered kind of the best in class there and says that if Amazon the success rate is slightly less than 50%. Which kind of, we can look at it from two perspectives, we can say well, you know, half the time they do stupid stuff but at the same time you can say, you know, half of their ideas actually turn out to be good which is amazing compared to most companies out there. So from this perspective of, you know, we spend this much money that just doesn't make a lot of sense to use that as a success factor and I, as a consultant I tend to work with lots of large banks and we spend a lot of time helping people adopt agile or whatever that means. I remember this completely bizarre meeting I had with the managing director of a big bank in London where they invited us to kind of propose how we're going to help them and invited some other consultants as well and, you know, during the meeting I asked this guy, what do you want to achieve with, you know, forget about agile and things like what do you want to achieve with this and he said, well, last year we did 35 million pounds of change Next year we want to achieve 70 million pounds of change and that's why we want to go ahead and drop it. So, you know, that's a nice measurement, there's some money there so we can work with that but what do you mean by change? And that's probably the stupidest question I've ever asked in my consulting career because I put the managing director of a bank in a really bad position where he couldn't answer. And 30 minutes later after kind of, you know, discussing with other people and trying to figure out what it is we agreed that that's salaries and operational costs. That's how much the rest of the bank is paying his department to deliver software. And I said, I have a solution for you. You pay me 35 million I walk away now you increase your costs by 35 my wife is going to be ecstatic I'm going to be a doctor then everything works and unfortunately he didn't take that but, you know, I think these kind of large, large waste of money have been a big problem even before ancient but we're now starting to see this whole pushback against something that should have been small and iterative and kind of focused on customer value there's a really nice article that was published by the register couple of months ago where they've done an agile project at the British Broadcasting Corporation and they've spent 75 million pounds before nailing down what they want to deliver. That's kind of agile at scale. That's how scale agile is spent. It's almost, you know, 75 million pounds and then you kind of say well, you know, this is doesn't really have a business goal because it was agile, it was flying out of the radar because, hey, you know you can reprioritize, you can change stuff whenever you want and they were talking about how at first they declared that success is going to be something like 12 million active users and then they changed it to 8 million registered users and then they changed it to 7 million active users and they were rephrasing this all the time to basically fit in whatever success means and that's horrible, horrible, horrible in so many horrible ways but that's why now we have this pushback where people say agile doesn't talk about the customer and it's not that agile doesn't talk about the customer, it's kind of large organizations wasting money don't know what to do and that's kind of the big problem and there are several aspects to kind of projects like this that often come up or at least the stuff that I was involved in and the first thing that is really a big problem is that agile is understood as this thing where anybody can change anything at any time and that leads people to do kind of squirrel driven product management where anything that's interesting is priority one and now we are chasing these three features and now we are chasing those three features and it's kind of always a run around and we have this whole kind of stream of consciousness things where people on one side the development team claims that they delivered 7 million story points and on the other side the customers never got anything useful and kind of for some insane reason teams are now using story points as success and everybody is measuring kind of progress as you know burn down charts, burn down charts, story points and everything is brilliant and that's just horrible and I think the other thing that then tends to happen with when there's no big picture people just chasing any idea that anybody can come up with is the way how we report progress and the way how we report progress is typically based on activity in a sense story points and burn up charts burn down charts that only measure how much effort we've spent in effect the story, you know a number of story points completed per week or by two weeks shows you know hey the average story point per person times number of people times how many days in this week have you worked those are pretty much fixed you don't change employees every week the number of days in a week has been pretty stable for I think about two or three thousand years now and kind of the only thing that changes is relative measures so what story points basically tell us is was there a holiday last week was there somebody sick and things like that so kind of there are much cheaper ways of measuring that and because we don't have any better way of measuring that we end up doing the silly silly silly reporting thing that is kind of underpants gnomes progressive reporting so Jeff Patton was the first person I know to use this metaphor and it comes from a south park episode where there are some gnomes just kind of stealing everybody's dirty underwear and the children find them in a cave and these guys are kind of you know full of dirty underwear and kind of pushing it in carts and the children ask them why are they planning gnomes that collect all the underwear see but why and they go talk to people and they talk to people and they find kind of you know a bunch of these collecting dirty underwear somewhere and at the end they realize after five different approaches find the planning gnome finally and the planning gnome is standing in front of this board that says you know phase one collect all the underpants phase three profit and phase two is nobody knows and a lot of software projects are managed like that this whole squirrel driven product management is collect all the underpants so what I would like you to think about is if your progress reporting involves story points what you're effectively doing is you're collecting other people's dirty underpants so think about that next time and the big problem with this is that first of all Doug Hubbard who's kind of a probably the biggest authority on business measurements nothing to do with software business measurements in his book on how to measure anything talks about that most companies tend to measure whatever is easy to measure instead of what's important story points are easy to measure effort is easy to measure we can measure time we can measure how many employees we have hours that's easy to measure value is very difficult to measure that's why people kind of don't even try that and the big problem between these two things is the whole profit thing we can only kind of observe on a very slow cycle profit comes next year profit comes at least six months from now where kind of this whole collect all the underpants the only thing we can measure is activity and there's nothing really to tell us whether we're doing the right thing and we need to answer this underpants long question we need to find something that is easier to measure in a shorter time cycle that would tell us whether we're going in the right direction or not so we don't end up spending 75 million and then saying well there's no profit here so that's what impact mapping is trying to us in one sentence impact mapping is trying to provide the answer to the question between so that people do not get lost and I think it's such an important technique so kind of the big problem with lots of other things we have kind of one side that has lots of these blah blah in order to blah blah lots of these very small defined stories that can finish inside an iteration that we can deliver those are all the dirty underpants then we have this power point that's kind of hiding on somebody's hard drive somewhere that nobody knows about that's kind of the profit part that is absolutely nothing in between there's magic in between and people kind of then declare these as product roadmaps I actually stole this thing from the Adobe called Fusion Roadmap and I love using it because it's so illustrative of everything people do wrong when they manage roadmaps so when I started kind of developing for money in 1998-99 Fusion was the platform of the day that was the main web development platform PHP didn't become popular yet everybody who was doing serious stuff was doing stuff on called Fusion so number one product in the market called Fusion today I don't know anybody who's using it and I like to think that it's because they manage their roadmaps like this because this is completely buzzword compliant you see this mobile it's enterprise ready it's kind of social and it's cloud and it's everything you know all the buzzwords are there it's amazing and it's all kind of based on a ton of features that we can measure whether we're kind of delivered or not but the only thing we can measure with this is activity another kind of fantastic piece of literature to look up online is a paper called Why FBI Cannot Build a Case Management System it talks about this FBI Sentinel project where they spent $450 million before shutting it down and understanding that it's not going to work and they actually tried to deliver it through waterfall they realized it's not going to work like that and they tried interactive and they realized it's not going to work like that and at the end they shut it down they restarted completely differently ended up delivering it and the big lesson that they've learned from kind of wasting $450 million is that their reporting was always based on activity everything they were measuring through years and years of delivery was oh we promised to work on these features and we've done these features yet next month have we done these features yet that's good and then kind of after about 30 years of work they realized that it's just not coming together and there's nothing to deliver because they've only measured activity so the big lesson that they've learned there is kind of measuring activity is dangerous if that's the only measurement you have and most kind of agile teams out there the only thing they actually do measure is activity so that's kind of where this is going to say now another thing that's kind of a big problem with this and this is that there are a sequence of things that's going to happen there are a list of things most people that kind of end up wasting a lot of money have very linear backlogs the whole idea of being flexible there is that people can reprioritize things that they've already analyzed and already chosen and that's how most people understand iterative and flexible planning is all you know the product owners reprioritize things and they can add more stuff there but generally everything has been delivered and then that's kind of made a success so there's a really fascinating book I've read called Adopt by Tim Hartford Tim Hartford is a British economist and he wrote a book on why linear plans always fail on longer times where as long as there's a sequence of things that you expect is going to be delivered linearly that's going to fail and he lists examples from economy, from civil engineering from the military and kind of lots of other things nothing to do with software but he kind of comes up with this set of things that are impossible to plan for and he calls them fulcinski principles based on a Russian engineer who invented lean start about 150 years ago and kind of it's a really fascinating piece of work to read and he says that kind of plans that work out over a longer period of time need to have variation where we will plan that try out lots of different things and figure out what works or doesn't work we can't plan to deliver everything because things will change that are unexpected. He quotes fulcinski has identified three important dimensions that we just cannot plan for he says that kind of first dimension is local where something works really well in one locality but doesn't really translate to others and before trying to deliver it for another locality we cannot know what's going to happen there in software this can translate to platforms like something might work incredibly well for the desktop but the user interaction might not translate it all to mobile and without having seen it we cannot know what's going to go wrong and it might also translate to localities and things like that so we have a client from Sweden where they've done some software that works incredibly well for the Swedish market they released it to Norway they made a lot of money they released it in Finland they made a lot of money and then they started expanding like mad they expanded to Russia and they lost a ton of money because people behave differently there and there was a lot of fraud the kind of in a perfect world where somebody had perfect information they would be able to predict that but you know that's impossible not actually trying to deliver the other dimension that he talks about is time where as we start working business opportunities open up or close and something might sound really really good when you think about it now but how for a year later because of the weather because of competitors because of other players in the market you know those things just might not apply anymore and that's why we need to plan for variation we need to plan for lots of different things and some of them might work some of them might not work for example I'm working on a collaboration tool with some colleagues now and our original plan was to offer a single user version for free and to charge for multi-user collaboration and we released a single user version it went live it became popular and then we decided to build a multi-user collaboration thing and halfway through building that Google released their real-time API for Google Drive which meant that pretty much anyone in the world can integrate with that and offer real-time collaboration to their users for free. Google is going to pay for that which can have invalidated our business plan completely. Now if we are working on a linear kind of set of things that we need to do we end up working for three more months that can fail but kind of because we were smarter how we plan and what we track and what we measure we were able to say okay you know something unexpected happened here because of a different doctor in the market and this plan no longer makes sense but we can be the first ones to offer real-time collaboration for free for this type of brother and because we were kind of just threw away whatever we were working on an integrated Google Drive we got reviewed by Lifehacker that's kind of number five site on the internet and they were praising us how we're offering collaboration for free everybody else is charging for that we got to turn on users as a result of that okay we had to kind of reply what we charged for but got an unexpected business benefit from being flexible rather than expecting that things are going to go always this way and that's why variation is so important the third thing that Harvard is talking about in his book as a big problem is that humans are essentially unpredictable we can make all sorts of decisions based on focus groups, user research and a ton of other things but without having serious statistically relevant data humans are going to be unpredictable and most focus groups in user research are seeing companies with 5 to 10 people and you know 20 people that's statistically completely relevant you might have chosen 5 people who really like one feature and then spend months and months building it and nothing really happens and this is where there's another book I strongly recommend everybody read and that's Anton Joolwig's book what customers want Anton was in charge of the second worst product launching history he directly lost about half a billion dollars and indirectly lost about I think 1.2 or something like that where he was in charge of the PC Junior project Italian and the interesting thing about the case starting from what customers want is that it was completely driven by customer research it was driven by user needs and trying to understand what users want and things like that and then they went into this huge investment only to realize that people don't actually want to buy the machine and you know they've invested half a billion into building it and producing those machines before realizing nobody wants to buy it so those things are dangerous whatever is going to happen in the market we need variation lots of different things that might or might not work and never plan to implement everything upfront and now of course variations easy to achieve the second principle that how for that identifies with Patrinsky's kind of survivability we shouldn't do the IBM thing we should kind of do these variations on a scale that is survivable that doesn't kill the company or doesn't kill the product and that's why the promise of agile the promise of kind of iterative delivery was supposed to be this and people end up spending 75 million before realizing that it's not going okay that's not survivable now the third principle that Hartford talks about is selection and that's kind of figuring out mistakes and figuring out what went wrong and kind of killing those things and that's kind of going back to the previous paper even with the best intentions even with the best perfect knowledge that you can have in this particular moment because unexpected things will happen competitors will do other stuff Google will do stuff you don't expect the weather is going to be bad there's going to be a typhoon when you expect to make money and things like that unexpected things will happen and things that you thought somebody thought were good ideas at that point and actually kind of what cohabitation is two thirds of things will be better ideas so we need to be able to select the stuff that works and throw in the stuff that doesn't and my big question for anybody who claims they are agile is how often do you kind of measure whether a story succeeded from a business perspective and delete the code if it failed very, very, very rarely meet people to do now, kind of think about it from this perspective if two thirds of user stories are bad or you know product features or whatever you put into the pipeline are bad ideas not because you implemented it badly but because something unexpected happened in the market why on earth would you pay three times more than you need to maintain your software in the future why on earth would you pay for three times as many developers to kind of push this stuff out and instead of thinking about scaling with kind of hiring more developers and wasting more money how about if we were able to kind of decide which two thirds of ideas were not that good and kind of remove them and that's I think the one that we are really, really bad at with software variation we can come up with is if people get drunk they come up with 20 different ways of delivering software and kind of ideas we can come up with similar ability we are not that bad over the last 15 years we have learned how to slice these things so that they are small but because people are tracking activity they are not tracking kind of success in any meaningful way we end up not being able to do selection so what's really interesting about Hartford's writing and kind of what we need to do with road maps in particular is kind of that these things end up being really, really bad road maps if your road maps are in PowerPoint think about it from this perspective is there a variation here probably not we need to deliver everything because that was approved is there a survivability well this is kind of 9 months of work we are going to waste you know 20 employees time or 500 employees time for 9 months before this PowerPoint kind of ends up being measurable and is there a selection criteria probably not because these things will end up in the software anyway so kind of whether they succeed or fail and then for the next 20 years will take for this thing to be maintained and what Hartford is saying is these things are not road maps these things are road maps the kind of trick is in the name it's a map of roads there's multiple roads if you want to go from here to here there's lots of options all these options are relatively survivable if one road is blocked you can take another one the taxi driver who was driving the main roads are blocked I'll go through kind of small roads it's going to take slightly longer by the time of the day so that's perfectly fine we have lots of options we have survivability to adapt to a particular time condition of 5 p.m. Singapore time and the third thing that these things kind of tend to bring is they tend to bring selection because if a road is blocked you can go and kind of look at another road so these are good road maps these are not road maps this is a road and it's a road going through a tunnel where you go in on one end and you go out on the other end and then figure out what happened and that's kind of the underpants norm thing so road maps like this are really interesting from a perspective of how they changed how our usage of those road maps changed over the last 15 years 15 years ago at least I used to use road maps like this completely differently even now I never learned how to drive I'm too stupid for that and I get angry very very quickly so I've realized kind of driving is not really for me my wife drives and I kind of typically am the navigator there so 15 years ago I would end up with a small book with kind of maps and then as she kind of starts driving we would have to plot exactly where we want to go in painful detail so that then I can flip as she's driving and say well turn here you know next turn right and things like that and because kind of it's difficult to flip through those books there's too much stuff there there's too much variation it's difficult to kind of monitor it what would inevitably happen every half an hour is we'd start playing the moron game who's a moron from you know losing a truck in a book who's a moron from not turning kind of because it left and you know she missed it and then we end up kind of concluding that we're completely lost we have to stop we have to go out and find a coffee shop we have to drink coffee to calm down and then ask the nice lady at the coffee shop where we are and then kind of re-plan the whole thing and half an hour later we're in another coffee shop so re-planning was difficult re-planning was expensive and we had to find somebody else to tell us where we are ten years ago we bought a marriage saving device that's kind of this I strongly suggest doing that because then you know what they have to argue who's a moron you know for not knowing how to read and who's a moron for not knowing how to drive and what these things did for us is they made re-planning pretty very cheap if a road is blocked this is going to re-plan it for me if the map is wrong I can say well you know you're not wrong they had to re-plan if all of a sudden these things are you know internet connected so if something unexpected happens like normally 5pm in Singapore the main roads are all blocked but hey maybe something happened and you know all of a sudden the main road is open this is going to know and it's going to take me to the main road so it can adjust to local conditions it can adjust to time-based conditions it can adjust to human conditions where somebody's going to make a mistake on the map and tell me where to go that's brilliant because I no longer even need to kind of flip the map and the key thing that changed for us is we do not have to have a detailed plan up front we can start with the rough plan where we want to go and this is going to kind of plan as we go now in order to avoid the underpants knows problem we need to create GPS for our software plans and if we are able to reduce the cost of re-planning the way GPS reduced it for real road maps then we can use variation and selection survivability very easy without that we can't that's why people still push kind of for big plans up front and the key thing that this brought to the game is this part here it's turn by turn navigation that's kind of better than re-planning all the details up front but it's more detailed than hey you know you're 10 kilometers away from the destination and by the way for people that are measuring activity story points features delivered and things like that all you have is this this is the only thing you're looking at and the next time you're kind of measuring story points think to yourself whether you would be able to drive a car if you only were able to look at how many kilometers per hour you're going and you're not allowed to do anything else you would probably drive very very slowly not to crash and it's unlikely that you'd kind of reach any sensible destination that's kind of more than 5 meters far so that's what we do with our software projects and that's insane now we need to kind of find this for our software projects and we need to do something that re-plies quickly and that's where kind of impact maps come in impact maps create turn by turn navigation that is easily measurable so that we can see if we're going in the right direction and impact maps are a very hierarchical visualization of software roadmap that tend to look like this in the middle there's a kind of objective we're trying to achieve the why we're doing this stuff and that's the goal we're trying to achieve now then kind of that breaks down into hierarchy of actors that can help or hinder this role I like to use the term actor rather than talking about users or customers or business because kind of very often people tend to confuse users and customers and kind of business value and then we get this generic goal you know we want to deliver value to our users and for lots of businesses users and customers are not nearly the same people for example in advertising the users are effectively people who click on ads and the customers goals are completely at odds with the user's goals because they want to collect all sorts of data they want to collect data the people who are paying for the software in effect kind of want to scan the users to buy and they don't want to buy and they want to take away the privacy so they're completely at odds with each other and then there's the business value to a company that's running an ad network that's kind of trying to find the balance between the two also very very often when people are just focused on small iterative deliveries they lose the context of anybody who's not directly involved in features and there's this famous case study of a kind of big gambling company in the UK where you know one of the leading edge of consultancies worked with them for two years to build this project and the week before it was supposed to go live they showed it to the board of directors and the CFO was offended for not being involved because they were changing some accounting reports then kind of he was really offended that nobody talked to him because they're in danger in his kingdom and he sabotaged the whole thing so after two years of delivery they ended up postponing this and it never went live and these are kind of problems that we still are expected in large organizations and people don't really kind of manage that well so that's why I like to use the term actor that's from Alistair Kobun's book on UML and he talks about three types of actors primary actors that are getting value delivered through software those are people who use the system for example that will be people who sell advertising or people who click on the links then kind of there are offstage there are kind of secondary actors those are not people who get the value out of software but those are people who contribute in delivering the value to their support staff anybody can of course involve partners and then there are offstage actors who don't really care about any value realized there they don't get any value or they don't provide value but they have an interest in this like regulators like you know board of directors like other stakeholders in the company and that's why I kind of mapping out all of those and figuring out well what do these people need what do they want well how can they influence this kind of objective and then kind of crucially the next level on an impact map is how can these people contribute to the goal what do we need to do how do we need to kind of deliver value to these people or change their behavior what is the impact on their work nothing to do with software but impact on their work that kind of we need to do to achieve this now this goes back to Anthony Rubik and what customers want and Anthony said that valuable initiatives tend to create a change in somebody's way of working and that changes the outcome that we can observe on a shorter time scale that's a really interesting perspective at answering the underpants known question because a change in somebody's way of working is somewhere something we shouldn't be noticing quickly after release a new feature and those changes might not be huge those changes might be small but we should be able to measure whether somebody is you know coming back more frequently or not and then we can know whether we are delivering value or whether we are not delivering value and Anthony's kind of way of answering the underpants known question was a change in the behavior and then we can start positioning that as a success factor rather than saying oh we're going to expect profit six months from now we can say well we deliver these features and we will use are they coming back more frequently as a selection criteria to decide whether these user stories are delivered or not and if not then our work is not done we need to kind of redevelop this we need to kind of re-plan this something unexpected happened that we didn't kind of really know about now impact maps then put deliverables software features delivery ideas and things like that in the context of this stuff and they create a nice hierarchy that we can start measuring success over time and generally kind of the key thing about impact maps is they are kind of a visual way of structuring this hierarchy because they're visual we can do it collaboratively which means they can be incredibly fast one of the comments that I've had from a large investment bank is that in two days of impact mapping they've achieved better alignment of what they want to do than what they would normally do in several weeks preparing for a milestone this is kind of the GPS thing say oh I just want to go there and I'm not really sure how I'm going to get there but these are some ideas I have and if something unexpected happens I will have operational awareness turn by turn navigation to tell me whether I'm taking this turn or not so we can then kind of go through other parts of the map and the key thing here is we start creating lots of variation because we can start seeing oh all these ideas about people coming back more frequently and the big question is how much more frequently and then we can say if this thing delivered that then we don't have to do anything else here we've achieved it or if the first three things didn't deliver maybe this phone is blocked and we need to figure out something else so impact maps give us a way to visualize hypotheses and give us a way to provide operational awareness as we deliver they give us a way to report on achievements rather than reporting on just kind of how much effort we spent so kind of there's a couple really interesting things here first of all kind of because they put behavior change between profit and dirty underpants they give us something that we can measure and monitor on a shorter time scale which allows us to then get this operational awareness they allow us to negotiate better they allow us to prioritize better from my experience it's much much easier to get people to choose what they feel is the next biggest impact we need to achieve then to agree which features are going to get us there plus as we are kind of going from the bottom to the top or towards the center the order of magnitude of items reduces every time so for you know 5,000 features will get 50, 60 impacts we want to achieve we no longer have to think about prioritizing all these kind of small miniscule items we can think about prioritizing impacts and outcomes and then figuring out how much we deliver do we need to continue do we not need to continue when I work with impact maps what we typically end up reporting is all we deliver these 5 stories as a result people are coming 5% more frequently would you like to continue working on people coming back more frequently or is that enough to move on to something else in which case we throw away that part of the map and as with the real roadmap the goal with an impact map is never ever ever to go through all the roads because that's insane you wouldn't do that with a car the goal is to kind of find the shortest, fastest, most beautiful path through this thing so that we hit our destination the other thing that kind of impact maps allow us to do is they allow us to still keep this iterative way of delivering small things so that we can reduce technical risk we can reduce integration risk we can do all these other things but put that into the perspective of larger things and rather than having to work with a ton of things on a very small miniscule level they allow us to kind of keep an operational awareness of that kind of big goals and then for example break down the first important goal into the impact we want to achieve then break down the first important impact into kind of epics and some deliver ideas so generally when I work with impact maps I tend to work with up and you know 20 stories we no longer have this thing that kind of gym shore called user story cart hell where you have 300 stories and you need to re-prioritize them all the time because we do not break things down into low level detail unless we have scope on the problem level, not on the solution level and this is something that I think a lot of teams with an iterative never completely lost over the last 15 years Michael Jackson the software architect not the kind of stupid singer wrote a long time ago how in order to deliver software successfully we need to have the problem machine and the solution machine and you need to kind of figure out the problem machine first before figuring out the solution machine this is you know now we are discovering this is a product community but people published books about that 40 years ago and now people come to conference and talk about this everybody applause like it's something new all we need to figure out the problem and that's really insane but we've lost this going to kind of small iterative livers because we stopped looking at the stuff about we started being too much obsessed with the solution people are too obsessed with solutions these days they forget to think about the problem first that's how we spend 75 million quid and then say well we don't know what we're trying to achieve brilliant, yeah that is clear quite a nice way of figuring out business goals so kind of impact must tend to kind of allow us to get the benefits of iterative but also have kind of this big picture thing that we want to look at and the next thing they allow us today is they allow us to use proper business analysis Tim Brown in his book Chained by Design talks about business analysis not from a software perspective from a business perspective and he says that most businesses do business analysis wrong what they use for business analysis stakeholders decide a solution and then business analysts analyze that solution converted into details it's completely wrong because if you've chosen the wrong solution you've already lost and he says that kind of the true value of business analysis first kind of come up with lots and lots of options and then business analysis happens to choose the right options to deliver and then kind of you know you figure out how you deliver it and you know now again we already discovered and there's 20 years after the book was written there's lots of product management strategies they talk about you know discovery value, customer mapping and kind of so what kind of he's basically talking about is grow them up first there's lots of variation then kind of going to stuff so you know build measure work that's why I said Palkchinsky invented lean startup 150 years ago and people kind of forgot that and an impact map allows us to facilitate is because we can start growing these options in a map without committing that we're going to deliver that it's not in the backlog it's on the map it's kind of maybe there maybe not we can explore it and like with the real map you know some of the stuff is visible but then you come closer to it and kind of you see more details you can zoom in you can zoom out and it allows us to manage these kind of two different types of delivery for different purposes and kind of the third thing the last thing that they allow us to do is really keep the goal in mind all the time and they allow people to kind of figure out which shortcuts to take and how to deliver value the fastest and that's because kind of we have this constant operational awareness we constantly have this kind of goal in the middle like we have in the GPS with Google maps and things that you can see whether you're kind of going the right direction or not and then you can apply your solutions to be the simplest possible thing that you need to do rather than kind of trying to spend too much money now kind of with all this in mind there's a couple of problems that I see over and over again and if you decide to bring impact maps to your organization you're very likely to start hitting those problems so the two facilitation techniques that kind of we're working on they're still working problems and you can find all the materials on GitHub I'll give you the link later we've tried it in a couple of situations we've done a couple of kind of improvements we're doing the next test run in about 20 days in Munich and we're improving these things all the time so it would be absolutely fantastic if you can try out these things as well and then provide feedback like oh we tried it in this context and it just doesn't work so you know people got confused about this or about that and kind of the problems that we're trying to address are kind of first of all people get too obsessed with deliverables what I tend to see is because it's so easy to think about things that are inside our zone of control that's where kind of the deliverables are people end up creating these maps where there's one or two things here and 50 things here which is completely the opposite of what we want to do but we want to have overall awareness here and then break one or two of these things to kind of individual items and this is where kind of a lot of the stuff that people can't really think about is in this area here because they used to think about this area here so the facilitation techniques that we started developing helped people kind of evolve this part of the map and as I said even if you don't do impact mapping trying to kind of understand who the stakeholders are who the kind of offstage actors are is really good trying to understand what kind of impacts you want to deliver to these people is really really good and that's what these two facilitation techniques are kind of supposed to deliver so the first problem I said is there's a lot of control over it where there's one stakeholder or two stakeholders that are relatively kind of easy to come up with and then there's 5 million things we want to do for these people and in effect what people end up creating is rephrasing the backlog as a hierarchy and then everything is a commitment we need to deliver everything and that's kind of just a waste of time the other problem that tends to happen there is kind of the actors are overly generic because the backlog kind of people start with too many features they want to deliver they just kind of find excuses to put it in the map then everything on the map ends up a whole user or customer and that's where we get to kind of fascinating things like as a user in order to use the system I want to log in completely pointless and kind of in terms of measuring impacts, measuring behavior changes in order to be able to properly work with that we need to be able to find good segments of users good customer segmentation is an absolutely critical thing for product management and impact maps are supposed to facilitate that but people come up with kind of generic actors and the third big problem that I'm seeing more and more is kind of people get stuck on behaviors it's very difficult to think about behavior changes because we're used to thinking about work items and kind of jobs that people want to do and then we say okay you know in order to sell this more or another for people to kind of buy this stuff and very often I see people putting behaviors rather than behavior changes in the map the problem with that is you will never be able to measure and use that as a selection criteria because when you say okay in order for people to buy well they're buying it now they will be buying it later the critical thing that we are going to create there is a change that's what Antonio talks about how differently will they be buying it but there's nothing that you kind of want to prevent people from putting a behavior there and so you think about behaviors and that's kind of one of the biggest problems there and that's again preventing us from doing selection so effectively what these maps end up doing is kind of just a bit of variation and that's why we want to fix this stuff so we came up with two facilitation techniques we used the innovation games framework from Luke Holman to come up with collaborative facilitation techniques and the first game is a revenue stream map that's how we called it it's a metaphorical game metaphorical games get people to kind of apply a metaphor of something that is you know can lead to a good conversation and get people to think about something they know to then brainstorm something you want them to think about in this case we're using revenue as something that most people are going to figure out where the revenue comes from and we're using a metaphor of kind of streams of water supplying a city with water to get them to think about different types of actors different types of stakeholders different types of users and coming up with a fine breakdown of user segmentation so a revenue stream map realistically when I do it looks like this because I draw like a child that I don't know how to write because I type now and kind of we use a metaphor of a city in the middle that is means fresh water to survive and there are rivers bringing fresh water into the city and these rivers are revenue streams they are kind of how the money comes in and the rivers break down into tripletaries they break down into springs they break down into kind of you know standard creates water and those are all the customers they call the segments because this is hierarchical it pushes people to break things down more and more and more and there are also kind of factories on the map and there's two types of factories some factories are pumping dirty water directly into the revenue streams those are competitors those are offstage actors that can disrupt those kind of people who are directly competing with you or that can lock you and the other type of kind of disruptor is an indirect one those are factories that are pumping dirty air and those are things that are not polluting the city now but if the wind changes direction they can start polluting the city so really nice that draws this thing it looks like this and you can see kind of this factory is pumping oil into the water this factory is pumping air and things like that so by having streams we can very easily get people to start thinking about how the money comes in that's what they know about and then they start breaking it down where does this money actually come from and the kind of starting points of the rivers are typically customer segments, user segments the factories are the offstage actors that can disrupt us and we have two different types of kind of these things that people end up placing in terms of the organization of this is a facilitation technique I like to get people into groups of four to five give them a large sheet of paper to start drawing on it and we split it into several 10 to 15 minute blocks where in the first one we just tell people to focus on what you know where's the revenue coming from and kind of break that down and it's perfectly okay to add factories or add kind of sources but don't worry about kind of detail break them just kind of think about the stuff you know come up with lots of options and they start breaking that down into hierarchy and then in the second block we tell them okay now focus on kind of these things and we have two types of cards we have cards that are kind of cut out for the sources of rivers factories so people can't forget to put them on and the whole idea with this game is to get people to start thinking about the hierarchical breakdown of where the value comes from and then think about different sources of these things and write those different types down so generally kind of after two blocks of 10 to 15 minutes we tend to kind of compare those things and collect the cards that's why I also like kind of having these things as cards because you can very easily collect them at the end and that's the stuff that we really want. So as a mathematical game this is helping people think about kind of the actors or the stakeholders they want to influence starting from kind of something they know and at the end you just collect the cards and you have a group of stakeholders you want to kind of deal with so that leads into the second game that's called impact cards and impact cards game is designed to help people think about behavior changes now we have a set of actors to kind of potentially start influencing what are all the possible ways for people to help all the instructors and from my experience if you know one group of users or customers or actors can help you do achieve a business objective by buying something more or doing something more frequently or doing something easier then there are probably other behavior changes you can achieve with the same state called the group to kind of drive the direction or a great variation there and one of the really kind of interesting things about this is kind of we give people a competitive game now to come up with more and more and more ideas and this is a card trumping game where people get a bunch of cards and the objective is to win points and you win points by being the last person to place a card in the deck the game starts with people creating a bunch of card templates and it's kind of ok who can help who can obstruct and how can they help or obstruct and we give them 10-15 minutes to start kind of noting down their ideas typically this is done for one larger group of stakeholders we say ok now we are looking at for example completely new users and then we can come up with some segments there as well to focus on completely new users people get 10-15 minutes to come up with kind of lots of these cards that fit in the templates and then one person starts puts a card on the table then the next person kind of clockwise or counterclockwise can cover that if it's kind of the same actor but a different behavior change and that goes kind of round and round and round until nobody has any more ideas and the last person that places a card on the top of the deck wins the whole deck and they win as many points as there are cards in the deck so what tends to happen is people very quickly go through the typical stuff like cheaper, faster, easier, better and then when there are a lot of ideas because there's lots of cards in the deck they really start thinking hard about the weird stuff to place just one more card on the deck and win the whole deck and the more the deck grows the more valuable it is so people keep thinking about all those weird ideas of course you're not going to keep all the ideas later but that kind of is a very very quick way there are lots of ideas for impacts you want to create now the other side of things I mentioned is people get stuck on behaviorism and behavior changes and in order to prevent that we've introduced a voting mechanism where when you place a card on the table the rest of the group on your table very quickly votes yes or no and the only thing they vote for is is this a behavior change are we accepted as a behavior change or if this is a behavior if this is a feature, if this is anything else after a behavior change the card does not go on the table and people keep playing this for 10-15 minutes they come up with lots and lots of weird and wonderful ideas for example where row settlement team can help by processing transactions faster you don't have to have 5% faster 10% faster measurements can come in later but the critical thing is get people to come up with lots of alternative ideas for this and then vote on whether this is a behavior change or not and then again we can correct the cards and what we typically do at this point is we kind of organize them in a quadrant where there's kind of can we actually cause this impact can we influence this thing and how difficult would it be to influence it and the other one is do we have ideas that are relatively easy how we can do this or do people get ahead just thinking about how we're going to deliver this we don't think about features we just kind of try and figure out is this going to be 10 months or is it something you can influence quickly and then we align it to those things and that kind of gives us the first set of priorities we can start looking at both these games tend to address the kind of start of the map they tend to address coming up with lots of stakeholders lots of actors and they tend to just coming up with ideas for behavior changes or impacts so my expectation is that these facilitation techniques will be useful regardless of where the people are because it's useful to understand a state called the landscape it's useful to understand different types of user categories and segments you might want to attack and for these different types of segments it's useful to have lots of ideas around variations how can we change these people's behavior how can we influence them how can we kind of get them to what are the impacts of those with these groups and then you can use any other product management technique after that so I think these things are really useful to create variation in that space so you can get all the materials that are printouts, templates black maps facilitation guides and everything from kind of github slash impact mapping and it's absolutely fantastic you can try it out if you're a complete fool this never worked for us because people got completely confused about this because then we can improve it for the next iteration we are doing a couple of test rounds over the next few months and we will be improving materials anyway so if you come in two months and the pictures are completely different don't be surprised but please, please, please contribute as well so thank you very much I hope I've given you and I don't know if I overrun if I underrun do we have time for discussions we have plenty of time for discussions so does this make sense at all does this sound like something that would help you kind of in your job okay so what would prevent you from doing this stuff a lack of knowledge I'm going to read a lot of it a lot of these things so get in yes there's a ton of materials there you can kind of just try and use it and even if you don't end up creating an impact map as a result of this I think this is still a valuable thing to do as in you know two times twenty minutes you can get some information you know get people to be a bit more creative than they were before okay so we'll open up questions alright thank you for your presentation Richard, obviously I have this question you mentioned that there must be a behavior change to measure the impact of a certain impact mapping so I was thinking what if a certain behavior is highly optimized and any other change might cause it even worse off than absolutely do not do any software for that part optimize something else optimize that already solve some other problems how would you know if it's optimized well an interesting question is what does it mean for it to be optimized I mean that's why we can look at defining the problem machine first as Michael Jackson said so if we look at something like customers then the big question is how frequently are they coming now and you can look at what is the current state of things there and most of the time when I start asking questions like that people become really uncomfortable because they don't know because they're not tracking those things although that's what Doug Hubbard again says that there's an inversely proportional thing where people tend to measure stuff it's easy to measure not what's important and then when you understand oh it's really important to know how frequently are people coming back now who you know across different categories how are they coming back maybe you said the behavior is optimized but maybe not in all the categories of people you want to approach that's why it's useful to have this kind of more hierarchical breakdown maybe you know your existing users are coming back okay but new users are dropping off really quickly and kind of doing a segmentation allows you to kind of optimize a sub segment of that market so I would kind of start once you know what impacts what you need to kind of figure out what's the current state and you know how do you want to change it and if you realize that you can't change it well you know then do something else if something is already well enough optimized please do not deliver any software they will just break it that's one of those two thirds of really bad ideas thank you if you have a really interesting tool or software is it possible to use an impact mapping to execute diagnosis whether or not this current software is delivering the impact that you want to perform and then actually use that to use the results I've worked with several teams where they had an existing backlog working kind of some you know existing software and we've taken the backlog and reversed the journey of an impact map just to figure out what do we want to measure in success and then we use that as a reporting thing to stop changing people's thinking about do we really need 500 stories anymore so it's absolutely useful for you know it's very very useful for things like because it gives you the big picture it allows you to ask the questions to kind of start measuring success of course anything is everything is easier to do on a complete green field thing but impact mapping is a really useful tool to get kind of alignment to what people actually want to achieve there's no impact mapping is just a visualization technique there's no magic to it just kind of you know forcing because it has four levels it's forcing people to ask these inconvenient questions that you know any good product management book written in the last 50 years says you need to understand the business objective and you need to understand the needs of your customers it's just forcing people to ask that because there's kind of four levels of the map you need to fill in so you can't skip from one to another you can't do the underpants norm thing you talked about the perils of story points what are your thoughts on value estimation at the story level the problem with value estimation at the story level is that most stories are very small and they can't earn your profits or they can't protect market share on their own and that's why we get into this underpants norm thing so if your stories are talking about the behavior change then you can measure whether the behaviors are changing or not on that level so what I love to do is I love to get people to tell me how they will be able to do something differently after the story is complete and I measure whether it's going in the direction of so for me that's a good way of estimating value for a story rather than saying oh you know you're going to earn 7 million you know you got the dollars from this because it's completely irrelevant we can measure it only in a very long cycle that's why the behavior changes over behavior is a really important thing to do whenever you get the story that says there's a user in order to view exceptions in trading I want blah blah blah how differently will you be able to view exceptions in trading and that becomes the kind of impact that the magic of an impact map is in the impact it's on the kind of third level with behavior changes you can do the same stuff with user stories just kind of don't let people describe business value as a behavior ask how differently and then estimate well you know how many percent how much more frequently and then you get into some really interesting conversations like we have this reporting thing where the official excuse for this feature was that people will be able to monitor trading exceptions and then we said okay you know you can monitor trading exceptions now you will be able to monitor trading exceptions in the future how do I decide whether this particular report did anything useful for you you know how differently and say well we're going to do it cheaper and what you will see constantly especially because people are not used to think about behavior changes is they come up with anything that plausibly sounds okay and then you can challenge it you can say well what do you mean by cheaper like we have five people in the settlement department now after we deliver the story how many of those five people will you fire it's not nobody so it's not going to be cheaper and then okay then they can say well more accurately okay are the current reports not accurate enough because that's a completely different solution to cheaper then we can look at optimizing the current reports we have to rewrite them and then they say well no no they're accurate already they say okay so it's not going to be more accurate than what and then you know after a while these guys came up with faster okay well how much faster how longer you're spending now averagely to get an exception identified you know with this moody port how much is this time going to come down and then you can start measuring that relatively easily you can say well maybe we're not going to get there 100% with this story but this story is going to give us halfway through or something like that so that's why asking for behavior changes is incredibly incredibly useful and I think kind of estimating value as a behavior change after a story is a perfectly valid thing to do estimating value as this is going to make us 7 trillion something is kind of yes no you know you will never be able to use that for anything to use so if you remember one thing from today behavior change is a good measurement of behavior change is the answer to the underpats no question without behavior change we're collecting the underpats let's get to you I have a question so how would you find an impact a division level the brand level the country level but they all have an impact on one another so if I do one thing here it might change another impact absolutely and that tells you that you know if you have departments that are so interdependent maybe you need to manage them together to achieve a particular goal or if you cannot have stuff that is more spread then you can think about how do I organize things so that we can run multiple things in parallel so I generally cannot depending on the size of the organization you might want to kind of you know look at larger or smaller things I know of a couple of really big organizations that have two different levels of impact maps for kind of this department as a whole and then it's kind of talking about the goals of the department and the impacts are kind of more around how do we need to change our stakeholders and then different teams get one of those kind of things they need to deliver and then that's the middle of their impact map and then they translate that into kind of software so and then kind of the lower level stuff allows you to manage the work of a team the higher level stuff allows you to coordinate the whole thing and see whether it's going towards the center or not that's an option for a very large organization my assumption is that if you figure out you have so many interdependent things that's telling you that your organization is aligned badly and but you know that's bad news but at least that's bad news before you start developing so you can figure out how to align differently or who you need to kind of coordinate and manage differently to achieve the same effect alright so we will take this question and if anyone has one last question after that then you guys can have one on one I appreciate your narration but I think that's a question that you put it quite clearly in terms of the moving dimension is in a way are we on innovation are we on renovation are we on specific dimensions and the question is that in mind the system design comes first or design thinking comes first and the question is that we're just not calling the question of the competition so are you aiming for breakthrough are you aiming for evolution are you aiming for revolution so the question of that price packaging branding everything all in a package and the bundle must be in that order now the question is that territorial difference is in other dimensions to overcome the internal sector does the company is willing and able to afford whatever cardinal sectors that need to be undertaken the question is that not every company not every boss understand what fundamental is all about so the question is that kind of innovation and talking about application innovation or talking about you know totally innovative innovation but the question is that you've got to understand the regime that you are going to tackle upon so through often you don't understand the mechanics of what is to be done the question is this question is chicken and egg dimension so if you need to understood the fundamental how are you going to get because the mapping is just every thing the algorithm of thing is all there but the question of the dynamic it's not like that it has to be formulation driven so how does the formulation driven is expected that is important how are you going to do it so I guess that's a comment it's not really a question you've asked kind of rhetorical questions there don't really have a comment on that you've told us a nice story thank you alright so we will win on to Lauren just let's keep our questions short I'm thinking about how to implement this framework as a product manager one thing you're always thinking about is how much to bring in the engineering team so what's your thought of what have you seen so far in terms of bringing engineers I like to get senior technical people involved in this because senior technical people are really good with coming up with ideas to put in the last part of the map and they need to have a really good understanding of the other parts of the map they need to understand why we're doing this and things like that depending on kind of the organization if you're working with a small team you can involve everybody if you're working with 500 people you're not going to involve everybody but at least senior technical people need to be involved in working on the map with you and the beautiful part the beautiful thing about the map is because it's just visualization kind of you can very quickly go through drawing this up and down if you're not deciding on a backlog you're deciding on the variation of things you might want to explore so you're not committed to anything it's a conversation technique more than anything else what do you think so far have they been receptive to yeah I kind of very often when I start working with people they really appreciate that they finally understand why they need to do stuff that they're just being given a lot of solutions they need to do in my experience I would often come up with cheaper, faster, better, easier solution once they understand what the problem is rather than going and implementing kind of something that somebody else has decided for them so the at least we're giving people a framework to think about well how will we measure that this thing was good about so we can come up with you know this is too expensive or we can maybe not deliver 100% of what you want but if I give you an excellent spreadsheet then 10% of it and you can go like tomorrow with an excellent spreadsheet then we optimize it we do these things later so it's an impact pop it's just a visualization technique it's a way to have a structured conversation around why and who and how before we decide what and as a product manager I would encourage you to kind of put some stakeholders in the room and some senior technical people and kind of start drawing this up on the board and you see that people very quickly pick up what the levels are even if you don't explain it it's just a visualization technique and then you can slowly correct them to kind of start describing behavior changes, asking oh how would you know that we've actually achieved this stuff and that's pretty much it kind of this gives us a good operational awareness it gives you kind of options for turn by turn navigation does that make sense? okay so we're out of time for questions now if you guys want to ask or anything you can ask them one on one later but before we wrap up completely coming back to the first question I asked everyone in the room when we started so who now knows what impact mapping is alright it was thank you Michael very much