I'm here with Laura Klein, author of UX for Lean Startups. Laura, can we talk a little bit about how these techniques work in a large organization, even, let's say, an internal IT project? I'm always astounded at the stats on how many IT projects fail for instance, how can we use the technique of Lean UX to improve on that? >> I am also astounded by how many of them fail. >> [LAUGH] >> Because, as far as I'm concerned, there is no excuse for that. You have every single one of your users in the building. Steve likes get out of the building thing doesn't even apply here, right? >> [LAUGH] >> They're in the building, I mean okay, they might be next door, in the next door building, but these are your co-workers, right. There is no excuse not to go and understand what their needs are? Just practicing good user centered design tactics with this, going, interviewing them, sitting next to them, doing their work with them, understanding what's important, understanding what gets them promoted, what gets them fired, right. Understanding what the context of use is, all of these things wildly important. You need to be doing these things. And then, the great thing, so I think one of the reasons that we do see these things fail is that they get a little bit, let's fix everything all at once, right. And it'll be well, we're going to fix the call center software. Well, the problem is that if we fix the call center software, then we also have to fix the backend servers, we have to upgrade those. If we're going to do that, then we have to change all of these machines to this other OS. And it can get a little, it can be yak shaving, that's my, don't look that up. But you can just start accenting, you can end up all of a sudden it's we actually have to rebuild the entire building and lay fiber. So that's going to have to happen first, and suddenly you're six years into a project that was supposed to be three months. So the most important thing with these projects is you have to find a way to scope them down to what is a particular problem that I can solve right now. Right, what is a problem, how can I make this better, how can I rebuild this in place and be constantly delivering useful things to my customers? And like I said, it's great, because your customers are right there. And believe me, if you've ever talked to an IT person, they will tell you what they need. They will tell you what their problems are. They know exactly what they are. They're not going to be shy about sharing this information with you. So if you're not constantly getting feedback from your IT people, you're not trying. >> A friend of mine, he's a development manager, once told me look, you can't take a nine month idea, slice it into two week iterations, and get lean, agile outcomes. >> Right, yeah absolutely, you can't say here's this giant project that addresses all of these different areas. Just going to kind of go and build one at a time. You really need to break it down into problems that you're solving. So that can be very hard, because suddenly you're not thinking of it's an entire redesign. It's what's a problem in this area that I can solve with this person, and what's it going to do for them? I do think that one of the reasons that they turn into these five year long death marches is that there's sort of this feeling that well, we're in there anyway Llt's just do this while we're at it. >> Right. >> Not necessarily that this was critical, this was not mission critical. It's just, well, eh, you know, we're updating this one, and updating this at the same time. Well, I'll tell you what, because why don't we just, is probably the most dangerous phrase that you can have in any kind of development process. [LAUGH] >> Yeah, uh-huh. >> [LAUGH] >> The reason we don't just, is because it's way harder than you think. >> Yeah. >> There are so many more pieces to it that you're not considering right now. You have to support it, you have to build the interface for it, you have to build the admin tools for it. It brings in all of these other dependencies. So get away from well, we're there, why don't we just. >> I literally can't think of a single thing I've worked on that I haven't found where if I wanted to punt on this, I could get it done quickly, but if I want to do a good thoughtful job, this is going to take me twice as long as I thought. >> And there is a big difference between putting out a crappy product and putting out a small product. >> Yeah. >> There are lots of great small product. There are lots of small products that do one thing extremely well. There are also a lot of crappy products that do a lot of things really poorly. >> Yeah. >> Think about the original Google search, right. You had one job. You did one thing and you did it great. And there was a box, and it was powerful enough and good enough that it changed people's behavior a while. So think about that, don't think about the, we need to move absolutely everything over all at once and redesign everything. And why don't we, while we're at it, rebuild the building and put in fiber. >> That is some great advice on making Lean UX work in the Enterprise. Thanks so much.
