Jeff Gothelf On What Lean UX Is And How To Introduce It In Your Organization

Recorded at:

1. Hi, everyone, my name is Todd Charron, I’m an Agile editor here at InfoQ and I am at the Lean UX conference 2014 and I am joined today by Jeff Gothelf. Did I say your last name correctly?

Yes.

Todd: I realized I didn’t actually ask you that, I've only read it, so I never actually realized how it’s said. You are one of the speakers here and you are also one of the authors of the Lean UX book, so tell us a bit about this conference and what brings you here.

This is a really amazing gathering of practitioners from all over the world who are interested in figuring out how to integrate design and user experience into an Agile process, I hear that a lot, as well as applying Lean thinking to the design process itself and into the product development process as a whole. I think what you are seeing here is a gathering of practitioners who have great case studies to share, a lot of folks who are eager to learn and take these back to their organizations and I think, mostly larger organizations, try to affect change inside of those organizations.

2. What brought onto the idea of Lean UX, where did that come from?

I spent the first ten years of my career writing design specifications as a UX designer and watching as 25- 50%, on a good day, of those specifications got implemented. That felt wasteful, personally, at first, why am I wasting my time doing all this work, none of it ever sees the light of day. That was one motivation. And the next was the process felt broken to me, felt like having negotiations instead of conversations and the only times we were even having those negotiation is when there was a document to review, there was no cross-functional conversation and that felt broken to me. At that same time I was tasked with building a user experience team at a company that was undergoing an Agile transformation, grassroots, engineering driven Agile transformation and I was tasked with not only building a design organization, but one that actually worked well in that context.

So, all these things came together at the same time and in a series of lengthy trial and error and research approaches we came upon this philosophy, it’s not really a methodology, it’s a philosophical approach to design, a cross-functional approach to design, a lighter approach to the design process that bases a lot of its decision-making on evidence, evidence from the marketplace and it’s highly inclusive of non-designers, traditionally non-designers, engineers and product managers and BAs and QAs. So, all of that drove this thinking that there had to be a better way, a different way and we found a cadence that worked well for a series of teams and philosophies that, appended, felt universal, so we put in a book.

3. We’ve seen in Agile approaches to design and UX, we’ve seen the sprint zero or sprint ahead approach, how does this differ from those previous approaches?

I’m not a fan of the sprint ahead or the sprint zero approach because I think it segregates the teams into these silos and it keeps the teams from working on the same thing at the same time. The goal of the philosophy behind a leaner approach to design, Lean UX, Lean Startup and the enterprise and so forth, is to collapse the process so that everybody is working on the same thing on the same time, everybody has got a combination of delivering and learning happening at the same time and building a shared understanding of the project as we move forward and because of that decision-making is more transparent, it’s more obvious, there is less negotiation, there is more conversation. The efficiency that I have seen in teams that work this way is significantly improved, the quality of the product is improved too.

4. [...] How do you actually do that in an organization so that they’re comfortable with that type of approach?

Todd's fuull question: You are also running a workshop here on Lean UX as well and one of the things that came up in the workshop was there is a lot more hypothesis testing and a lot more risk for failure, that’s one aspect of it and maybe talk a little bit about that and also if you’re creating an environment where failure is key to success, how do you actually do that in an organization so that they’re comfortable with that type of approach?

The first thing to consider is the scope of the failure, for example if you’ve worked on something for six months with 25 people and it fails, that’s a significant failure; if you worked on something for two hours with a couple of folks and second guess and figuring out what was right and wrong, that’s a significantly smaller failure, the benefit there is the learning, so the next time you try an iteration on that you have more data to be more right the next time around. So, it’s understanding the scope of the failure, really understanding that failure is the key to learning, if people get hung up on that language of failure, it needs to be switched to learning, how do we learn faster, learn by trying and then see what worked, what didn’t work and then trying again, so how do you do that as many times as possible.

Now how you change that in organization, how do you build a culture that supports that is challenging, but I think the first step is to start having conversations with stakeholders, and leaders that ask the question why, why are we doing this, why are we building this, why are we focused on this particular market demographic and when you ask that question, hopefully you end up at a point where you're discussing business outcomes, what are the success factors that we hope to improve in our business and when you get to that point what you’ve established is objective success criteria and then you can have a conversation around what ideas could potentially meet that success criteria instead of blindly accepting somebody’s world view about how to achieve that. I think it’s the first step into building an experimental culture of hypothesis-based decision-making. Once you can build credibility for that way of working, and then turn your attention to things like tools, team structure, reporting structure, funding and all these elements that make up how a company functions, but initially you have to change the mind, the culture of the organization from one of “hey, we just got to push features out” to “hey, we have to learn as much as we can as soon as possible”

5. A lot of organizations work right now in the highest paid person’s opinion as opposed to what’s right for the customer, so how does, say somebody like yourself or somebody that’s working in an organization, deal with an upper management that believes they really are right?

Again, the conversation hopefully can be shifted towards “ok, you like this particular feature of the product, terrific, what do we hope to achieve by launching it?” Hopefully, we can have a reasonable conversation about what the business reason is for doing this, how are we going to measure this, do we have the ability to even measure it today, will we know in 12 weeks when we launch this thing whether we hit the mark or not, if not let’s talk about that, let’s talk about how we measure certain things, how we achieve success, hopefully we can have that conversation. At the very least you can say “listen, I know you told us to build this thing, we’ve done the research and feedback is overwhelmingly opposed to pursuing this approach blindly, we should really consider some modifications”. At that point the conversation that you are having will reveal whether or not you stand a chance of affecting any kind of cross-functional organizational change in this organization. In some organizations you have receptive leaders that say “hey, this makes a lot of sense, and I am noticing you may delve into this a bit further before we dump a million dollars, ten million dollars into dev”. In other situations you might end up with a leader that says “it’s my point of view, you have to do it” and then you are faced with a choice, you can execute or you can choose to work somewhere else or figure out a way around it. The key is to try to shift the conversation to one of objectives and outcomes.

6. Let’s say you’re in an organization that’s somewhat receptive to this sort of change, how does one approach this type of organizational change?

If you already have some positive feedback from this way of working, first thing is to start to break down the silos between departments, build cross-functional collaborative teams, small teams that are self-sufficient and empowered to solve business problems, and then let them go, give them the autonomy to self-organize, the ability to run experiments without risk of retribution, of course the onus is on them to be as transparent as possible and to report back to the organization what they are doing, what they are learning and how they are proceeding, give them the ability to own the solution, to self-organize how to get there and I think you will find tremendous benefits in that team structure.

7. How does that differ from the normal Agile approach to teams, which is very similar, but you might have your user stories or features, where you used the word experiments. How does that change how a team operates?

My feeling on Agile is that it’s extremely focused on delivery, not necessarily on learning, at least in the way most companies practice Agile today it’s optimized for delivery, it’s not really about thinking about what problem are we solving, who are we solving it for, what’s the best solution, how do we know, it’s more about how do we deliver features to customers more efficiently. So, this is essentially, as my friend Bill Scott at PayPal likes to say it’s putting a brain on the Agile process, let’s not blindly march forward efficiently, let’s make good, market-based, evidence-based decisions as a team and continually learn as we’re delivering, not just whether or not our software processes are good or not but whether or not the things we choose to work on are making a difference both for our customers and for our business.

8. From the Agile manifesto, we talk about working software overr comprehensive documentation, how might that change, instead of working software, what might we look at?

I tend to interpret working software fairly liberally, anyone gets the benefit of interpretation I guess, but for me working software means experiencing the product, experiencing the service that we are building and so delivering some kind of experience, the customers couldn’t be more concerned, it could be a prototype, it could be any variety of things between those two things that gives us a sense of whether or not we are headed in the right direction. The more frequently we can get the customers in a conversation, get them to experience the things that we are building, the more frequently we can course-correct based on that feedback and build something that can make them better or more successful at whatever it is that we are trying to help them with.

9. [...] However if you’re doing all these failures, how do you show you are actually making progress or that you are actually increasing your learning, how do you reflect that back into the organization?

Todd's full question: One of the things you talked about, you had a diagram showing the investment going up and to the right and you showed more experiments where there might be a little bit of investment and it might crash, it might not turn out well. However if you’re doing all these failures, how do you show you are actually making progress or that you are actually increasing your learning, how do you reflect that back into the organization?

You need to have success criteria, you’re not always failing first of all, I think you’re learning and you are moving forward and you’re getting smarter as evidenced by some kind of objective measure of your progress towards business or you're trying to increase retention by 40% and week over week you are reporting into your organization about your progress increased by 8%, by 9%, even 7%, whatever it is, so the more transparent you can be about your progress, the more the organization manifests from daily printouts or statistics that are taped to a wall around the office to monitors, to information radiators that are letting everybody know how things are trending on certain things, you really need to hold yourself accountable objectively is key to the success of this project.

10. [...] How do you show people “yes, this didn’t go the way we wanted to, but look what we learned”?

Todd's full question: Going back to what you said earlier from my previous comment, as an experiment you talked about those might be failures as you didn’t hit exactly what you wanted to hit, you mentioned earlier about changing failure with learning, how do you look at it instead not as a failure, but instead as a learning? How do you show people “yes, this didn’t go the way we wanted to, but look what we learned”?

I think that’s exactly what you say, those are the words I would use, this didn’t go the way that we wanted, here is what we learned and here is how we are going to use that information the next time around, the good news is that we only spent a very small amount of time learning that, instead of building for six months and spending ten million dollars, we built for a couple of hours and we ran the experiment for two days and we learned a ton, so next time around we will have a shorter experiment, perhaps a more robust one, but at least we will have some accurate data that says this is far more likely to succeed than something else.

Todd: You told me you are actually changing your talk for tomorrow, you are actually going to talk about purity versus pragmatism. Say a little more about that.

It’s really a... and the irony is not lost on me that I wrote a book that offers tactical recipes to people looking to work in this way, but I think there is a strong desire in many companies, especially in large companies for a silver bullet recipe book that says tell me how to do this and I will follow the steps and then I will be Agile or Lean or whatever it is, I think there is a land grab for that and inevitably the context of your organization, not just the organization, but the context in which you are operating will determine which recipes make sense and which recipes don’t. So, the context of your domain, of your budget, your stakeholders and your clients and your company culture and so forth, don’t be so quick to subscribe to something just because there is a book on it and there are coaches that are selling it or a piece of software that everybody is using, make sure it makes sense and pragmatically pick the pieces of the process that will help you move forward incrementally again and not try to wrap yourself up in this dogma and process that will likely not work for your organization wholesale, you have to pick and choose the pieces that’s what I'll be talking about.

11. [...] Any advice for people who are looking to do something like that on what they should be looking for in each of these practices to tie back into their organizations?

Todd's full question: Sometimes that can present a chicken-and-the-egg problem in that if you start out you may not know which pieces are appropriate or the ones you think are appropriate may not be. Any advice for people who are looking to do something like that on what they should be looking for in each of these practices to tie back into their organizations?

Like any good iterative development practice you are iteratively improving your process as well. So try something, if you can’t figure out what to try you try something. You are going to try it for a short period of time, one week or two weeks, then reflect back and see how well it worked, how well it didn’t work; a client- you know this is an Agile coach- take the team’s temperature, at the beginning, at the end, maybe for other iterations see how this goes, see if it’s making, if it’s improving things, if the morale is improving, if the general team mood is improving and if the productivity is improving. If it’s not, reflect on why and try something new next time. Again, it’s building this mentality of learning, into your product, into your process as well.

12. You have the book out, obviously you’re doing training courses, you’re doing conferences, what’s next for you, what does the future hold?

I've started writing another book, which I am really happy about, with Josh Seiden again, my coauthor from the Lean UX book, and this one really seeks to up level the conversation outside of design, outside of a specific discipline to really help leaders of companies and managers of teams understand how to build the infrastructure that supports this way of working. So, it’s not just tactical level, it’s not discipline level, it’s how do I structure my organization or my department to support this way of working and that’s the across the different roles and disciplines and also from a technological stand point as well as a funding standpoint and kind of a whole enterprise look at facilitating this way of working.

Todd: It’s a bit of a bigger challenge.

It is, it’s significantly bigger and we’re excited to take it on and the goal is to get it out early 2015.

Todd: Excellent. Well, thank you very much for doing this for us.

My pleasure. Thanks for having me.