Jeff Gothelf is a designer, an Agile practitioner with a specific expertise in User Experience culminating in his book Lean UX: Applying Lean 
Principles to Improve User Experience.
Download PDF Transcript of Podcast
Note: This is a transcription of a podcast. It has not gone through a professional editing process and may contain grammatical errors or incorrect formatting.
Related Podcast: Applying Lean Principles to Improve User Experience
Transcription of the Podcast
Joe: Welcome everyone. This is Joe Dager, the host of the Business901 Podcast. With me today is Jeff Gothelf. He is a designer and Agile practitioner with a specific expertise in User Experience, which helped create his book, Lean UX. His daytime job is currently as Managing Director of Neo’s New York City office. And previously Jeff has led teams at The Ladders, Web Trends, Fidelity, and AOL. Jeff, I’d like to welcome you. It’s been awhile since O’Reilly published the book, when was it published by the way?
Jeff: Yes Joe, it’s great to be here. The book was published in March of 2013, so we’re just over two years since the publication of Lean UX.
Joe: Did it have as broad appeal as you had hoped for, or maybe much broader? How did that workout?
Jeff: I have to admit Joe; I’m blown away by the breadth of the appeal that the book has had. Josh and I wrote that book as designers speaking to designers; that was the focal point. The idea was we really have to rethink the way that we design software products in this new Agile world that’s trending toward a more continuous reality. And the adoption of those ideas has certainly are a tremendous conversation and in some cases revolution in the way that design is being done, but it’s gone much farther than that. It’s gone into the development circles, of the product management circles, inter-management circles, and so it’s blown away really by the adoption of the ideas and the distance that the book has traveled in two and a half years.
Joe: I see it in a lot of different spaces which tells me that there are a lot of people reading it. What can non-designers let’s say take away from the book?
Jeff: One of the biggest things you can learn is how to actually work with designers if you’re not a designer. In an Agile context which is whether you’re actually doing Agile or you’re just saying the words, the reality is that almost every organization is at the very least pretending to be doing Agile now and on the better end of that scale, actually doing good Agile software development, the interesting thing is that the products and the services that succeed today are the products of excellent software engineering and excellent design. And so at the very least, the smallest takeaway which is still a huge takeaway is for non-designers to learn how to work with designers in an Agile reality, whatever the Scrum or whatever reality you’re in. But in that world, how to build design into the cadences that you’re working in – so that’s the biggest takeaway.
I think more importantly than that, I think there’s an opportunity for non-designers to understand the tools that designers use to do the work that we do and really hopefully to some extent drive a bigger sense of value into what design is. It’s still frankly mildly depressing at times to come across organizations that have sophisticated software engineering programs and departments and yet when it comes to design, they’re like, “Oh right, that’s when we make it pretty.” And that still happens a surprising amount of times despite the Apples of the world and the Netflix’s of the world and the nests and all of these beautifully designed products and systems, it seems like design in some places still held as just make it pretty. So hopefully the book helps to kind of break down those barriers as well. I think those are really three big takeaways that non-designers can get from the book.
Joe: You talk about Design Thinking as complimenting Lean UX, but then when you think of that Design Thinking, does that gear people towards what you just said there?
Jeff: I think there’s a misunderstanding of Design Thinking than perhaps — but Design Thinking, it’s not a methodology for making things pretty. In fact, what it is is a way to leverage the tools that designers have used for decades to solve business problems. So they’re new tools — well, they’re old tools that are being re-purposed in a broader context to solve bigger problems. And so Design Thinking really is about understanding the customer; so it’s about getting empathy for the person that you’re building, your service for the context in which they are engaging with the service and the problems that they’re trying to solve. That’s the first pillar of Design Thinking, and there’s nothing in there about making anything necessarily. It’s really just about understanding as a team what the problems are.
The next step is creativity, and again creativity not limited to an individual or a job title, but creativity for the team in collaboratively generating solutions for the problems that you’ve identified by understanding the customer. And then lastly, the last pillar of Design Thinking is then rational, which essentially means honest with yourself and with your colleagues about which one of your many brilliant ideas actually does solve the problem. And then, it’s about refining the experience and making it more user-friendly, making it more aesthetically pleasing, making it more smooth and so forth And so I think that if people ascribe Design Thinking as a visual design activity, then there’s a misunderstanding there and again, I think that happens and I think that that’s why there is still this design is still ‘making it pretty’ aspect. Design Thinking is much broader than that, and it’s a core component of the way that Lean UX works.
Joe: I want to steal something from Highsmith where he talks about most people thinking about things in a plan-do type thing, a plan-do type arrangement where I think Design Thinking and maybe Lean UX speaks a little bit more of envision speculating, and experimenting let’s say into one out there, and is that that mindset that is difficult when let’s say other parts of an organization starts dealing with the software guys because they’re not necessarily in that plan-do type thinking?
Jeff: The biggest thing that I teach when I teach workshops and when I work with teams in-house and I teach classes or give talks, I take this Lean principle of humility and I drive that home as much as possible. I do this with designers as well because designers, especially designers that come from agencies, from the agency world more so than in-house designers, they come from this position of — I don’t want to say arrogance, but I’ll say extreme confidence and what I mean by that is — and I see this in designers, and developers, and product managers, and leaders that say, “I know what the answer is, and I know what it should do, and I know how it should do it, and I know what it should look like and what the workflow is…” It’s okay to have that conviction and to have that strong point of view, but you got to have this position of humility that says I’m going to make sure that I’m right. There’s always this nagging sense of skepticism that says, I have a strong opinion, but I’m willing to have my mind changed if the feedback comes back and says that I was wrong.
How do we minimize the risk of going too far down one design direction, product direction, business direction and that’s where I think that’s what I work with my team is to understand is that you really can’t predict the end state. You can have a strong opinion about what you think it might be but by accepting this position of humility, we then have to then mitigate the risk of going too far down the wrong path. And we do that through experimentation, through learning, through hypothesis, prototyping, through customer developments, through collaborative design exercises with our colleagues or without customers, and the key is to build enough evidence based on real world feedback about whether or not our ideas actually are — our strong opinions are actually worth continuing to hold. And if they’re not, then we have to actually be comfortable changing direction, and that’s by far the hardest part of all this is actually changing direction.
Joe: How much has Lean startup principles change your thinking about the basic Agile principles or are they one and the same?
Jeff: Usually we’re treading into a conversation where I haven’t seen enough public discourse on it yet. The conversation is why are people hiring Agile today, versus why people hired Agile 10 years ago. Why are people implementing Agile, and I’m starting to see some conversation about it. And I think when we wrote the book, our thinking wasn’t as nuanced as it is now about that debate. We were essentially taking present day reasons for Agile implementation as the basis for our work and what I believe present day reasons are for Agile implementation is faster shipping of features. So while I think that was not the intent of the authors of the manifesto and while it’s not the intent of companies and teams that adopted Agile 10 and 15 years ago, I believe that companies that are adopting Agile today, that are doing this wholesale transformation are doing so for the faster delivery of features, and what’s missing from that is a decision framework. A decision-making framework of deciding what we should actually work on, until what extent should we work on it, and how much design should go into it, and what is really the definition of done. It’s moving away from the definition done being we shipped it to the definition of done being we shipped it, people like it, people use it, it’s changed their behavior which means they’re more loyal to us, they’re more successful using our product, which means that we’re more successful as a business and the outcomes change, and that’s really the definition of done.
And so when we wrote the book as a — here’s an opportunity to put a decision-making framework on modern implementations of Agile which based on our experience were largely based on incentivizing teams to efficiently deliver high-quality code.
Joe: That ties in with one of the things that I took from the book and one of the great lines in the book is that ‘Every design is a proposed business solution.’ And that really gets away from that featured-type thinking.
Jeff: Absolutely, and it moves you away from, ‘Well, I designed it…’ And listen, I’m a designer by trade and designers are hopelessly optimistic people. We could have worked n something for five months or five minutes, and we still think it’s the greatest thing ever. And I really want to drive home the idea that — and in the book certainly and then kind of more broadly is that these are proposals, they are hypotheses, they’re guesses, and we need to validate that this is the right way to do something, to build something. Not just ship it because we came up with it. And that’s the key here is how do we build that decision making framework into this process that says we should work on this, but not work on that; and not make it a subjective process, subjected to executive whim, or the loudest voice in the room, or whatever it is and make it a more objective process based on a new definition of done which is the shifting of customer behavior.
Joe: What have you learned the most from the book? We talked about the appeal a little bit but I mean after you published the book, and you’ve had two years now, it had great success, what have you really taken away? I mean did you miss putting something in it that you wish you would have now?
Jeff: That’s a great question. Look, absolutely. A book is a snapshot in time. It’s a photograph of our thinking at that moment and look, we turned in the final manuscript in December of 2012, three months later, the book is published. So this is a snapshot in time for two and a half years ago. Since then, if we were to do a Version 2 or an updated version of the book, I would have a much more significant section on experiment design, on how the role of designers is broadening, how this process integrates in an enterprise setting – that’s really been the biggest takeaway. We touched on it with some of the principles, but we were very, very loose in kind of the last section of the book about the various things that had to change. It was two or three sentences on ‘This needs to change, and this needs to change…’ And, in fact, actually what’s interesting is – and thanks for the segue, I appreciate it actually, is that we are writing a new book and we are at the early stages of it, but the new book is really in many ways it’s Lean UX Version 2. The book is going to be out next year, in about a year and there is a URL to sign up for, http://sensingbook.com/ because we don’t have a final title yet, but the point of the book is to say – every time we’ve handed the book to UX designers or anybody who has read it, the majority of the feedback we get is, “This is great, I love it…” “Great idea, I’m going to try this, but I’m skeptical that it’s going to work in our company…” “It’s going to be too hard to implement this. My boss won’t buy it. The company doesn’t work this way…”
And so we’ve been collecting that feedback and the insights about why that is for the last two and a half years, and the new book is a business book. It’s not going to be a book targeted at designers, it’s going to be a business book targeted at leaders, and executives and emerging leaders to help them set-up the environment so that their teams can work this way. And I think that that’s the key component that’s missing from the Lean UX book now. It’s like okay, here are the tactics, but you need the infrastructure and the support, and the environment to actually work this way and so here’s what has to change organizationally, and that’s the focus of our next book.
Joe: I took a few things from the book; you have to back up from it because there’s a lot that you can implement and do. I mean the book is just full of different things you can do. It’s just about too much and I really enjoyed reading it for this interview even though I read it a year and a half ago. When I referred back to it and everything, there was so much more that clicked now than it did a couple of years ago.
Jeff: For organizations that are just setting out on this path, I was asked, “Well, how do we do this?” Because it seems overwhelming, and I think that the goal is to take it one step a time. So say, okay, I’m going to try this one tactic. Let’s get this one tactic right and see if it adds value to the way that we make our products or our service. And if that works great, let’s add a second tactic and a third tactic. And I think that that’s the key is you can keep coming back to it. The book is very practical; it’s very tactical and so, can you take this idea and make it work and modify it? Yes, great. Let’s take the next one and make it work and move the ideas forward.
The thing that I always stress with the teams that I work with is that any of these ideas and perhaps to some people, it might sound like sacrilege, I hope it doesn’t, but all of these ideas, Lean UX, Lean Startup, Agile, Scrum, XP, Kanban – all the various flavors, and the permutations, and the methodologies, I see them as frameworks, as starting points. And that when you wrap the realities of your business around those frameworks, and those realities are your domain, your corporate politics, your user base, the competition, regulatory environments, all of these things – when you wrap the realities of your business around this framework, they invariably have to change. They have to shift. They have to adjust. So just because the book said, do A, and then do B, and then do C; if you have to skip B because C makes more sense for you as an organization, that’s fine. And I think that as long as people are taking these ideas to heart, they are ultimately going to change their philosophical approach to work and the process will adjust accordingly. I think that’s a big deal.
Joe: In your book. I have to ask you this, I saw that you used Scrum in a lot of different discussions. Do you use other methods like Kanban or other Agile methods?
Jeff: The short answer is yes and the longer answer is that again, I think reminiscent of the things that I just gave is that we will pick and choose the bits and pieces that make the most sense to make this team in this context successful. We will use Scrum, or Kanban, or some variations of the ideas that we have in the book as starting points and then we’ll adjust them as necessary. What I like about Scrum specifically when it comes to building in some of these Lean UX practices is that Scrum has these predefined milestones in the way that you work. You’ve got iteration planning, you’ve got stand-ups, you’ve got retrospectives. You can build in these mileposts in the process around which the Lean UX techniques and tactics fall neatly; they neatly fall into those milestones, and that makes it easier for a team to pick up.
But if a team is using Kanban and they have less of that structure, then they’re just going to have to be more disciplined about when they do certain things. They’re going to have to be a bit more proactive, a bit more mindful about when they do customer development, when they do a team collaboration activity, when they do kind of a broader workshop type of activity. And so to me, those are subtle differences and maybe they indicate different levels of maturity ultimately. I mean in my experience, and again my experience is just what it is, I think teams ultimately migrate from Scrum to Kanban as their maturity with the process improves. And so, in that case, they’re more mindful of the work that they’re doing, their milestones, their decisions points and so they can still make these techniques look really well.
Joe: It seems that User Experience has gotten a broader concept. We got interaction design; we have all these other disciplines starting up – it seems to me from the outside looking in a little bit that start to fall under User Experience. Is that a good thing or do you think we stay in the risk of just fracturing and just having so many disciplines out there that we don’t know what to do?
Jeff: The challenge with any of this is it’s driven by kind of hiring markets and job descriptions. I’m of the camp and as a growing camper, that User Experience is everyone’s responsibility and that by exclusively having a User Experience department or a VP of User Experience, then the rest of the organization has the option to advocate responsibility for the user’s experience. Now let’s be honest, I mean a user’s experience is design as much as it is fast performing code, and great search results, and a system that actually delivers on its promises, and its great content and copy, and logical workflows. And so I think that when you give a team the title of UX, there’s an avocation of responsibility, there’s a risk of avocation of responsibility by the rest of the organization.
By that being said, to your point I agree with you Joe, there are lots and lots of disciplines that fall under a User Experience umbrella. Interaction Design, for example, is a discipline and requires people to do Interaction Design. Visual design requires a frontend development or customer development, research; obviously software engineering – all of those are specific disciplines that affect the User Experience. And so I do think we need those different disciplines, and there’s a difference between what an interaction designer does and what a visual designer does.
Now look, the reality is that in a lot of companies today and certainly a lot of the more successful startup situations and companies that have come from and that started to boom over the last 10 or 15 years, you’re seeing designers and I’ll just use that term broadly with broad skill sets. So whereas maybe 10 or 15 years ago, someone was an interactive designer or a visual designer but today, you’re seeing folks who can do User Experience and front-end development, or Visual Design and Interaction Design, or all three, or some combination of those because I think because we need to move faster, we need to be able to build our work, we need to be able to test and validate our work, and I think that that shows a level of engagement with the software engineering side of the house that wasn’t present 10 years ago as well. So the short answer is it’s complicated, but I think there are a lot of opportunities to really involve the whole organization in building great products.
Joe: Well you mentioned a new book will come out, what else is in the future for Jeff?
Jeff: The book is a big action. Writing a book is no small feat, so we are about a third of the way through that, working through it the rest of this year. I do a lot of public speaking and workshops, both in-house and public workshops in helping promote not only these ideas, but the way that we do work in Neo. And Neo is based in New York and San Francisco, and our goal is to really build an organization that drives startups like innovation inside the enterprise. And so we work with large companies to kind of reignite and drive new innovation efforts inside of them. We teach them how to work this way.
I spend a lot of my time on airplanes which is both good and bad. I get to the fun and interesting places, but I’m away from my family a lot, which is unfortunate. But I do plan on spending June and July in New York, so I’ll be around. I live in the Metro New York City area which will be nice to stay home and work from home and then I want to take a little vacation. I want to go to Spain for a little bit before hitting the road again in September. And so as I continue to write this book, give talks, teach workshops, and really help people build better products.
Joe: What’s the best way for someone to contact you?
Jeff: Three easiest ways to get a hold of me – email is Jeff@Neo.com. That’s the only email address I’ve ever had. I spend a ridiculous amount of time on Twitter, and my handle there is @Jboogie. And then lastly my Website is always a good place to go for ideas and concepts which are JeffGothelf.com.
Joe: I would like to thank you very much, Jeff. I appreciate it. Great book and I think it well deserves the broad appeal that it’s had. Thanks again and the book, we mentioned a few times the long title I guess, Jeff.
Jeff: ‘Lean UX: Applying Lean Principles to User Experience.’ Amazon, O’Reilly. LeanUXbook.com will get you anywhere you need to go to grab a title.
Joe: Well thanks again. This podcast will be available on the Business901 iTunes and the Business901 Website. Thanks, everyone!
Lean Sales and Marketing: Learn about using CAP-Do