Episode #269 Jeff Gothelf - Discover What Customers Really Want with Lean UX
When some people hear the term Lean UX, they dismiss it as simply a nouveau buzzword. There can be some confusion as to its relationship to Agile, both the methodology and the adjective. Some of the biggest resistance came from the idea that Lean UX was shortcutting and lazily undoing much of the groundwork to get organizations to buy into the value of UX. But as waterfall development increasingly becomes “the old way” of doing things, teams are operating in more agile, or Lean, ways.
Jeff Gothelf co-wrote the Lean UX book with Josh Seiden. Over the years since the book was released, he has seen the initial resistance to the idea die down. The conversation has shifted to domain-specific challenges and how Lean UX can address those.
It all comes back to research and the idea of the Minimum Viable Product. This isn’t to confuse an MVP for the “first conceivable thing we can ship.” Getting your product in front of customers early in the process lets you test any hypotheses you have about both the product and your customer base. Uncovering misconceptions up front allows you to iterate and pivot to arrive not just at the best design, but the right one.
Jared Spool: Hello, everyone. Welcome to another episode of The SpoolCast. I have returning star, and author, Jeff Gothelf, who is going to be speaking at UI20 this November 2nd through 4th in Boston, Massachusetts. He's doing a full day workshop on bringing "Lean UX" to your organization, and using it as a tool to collaborate, and get everybody on the same page. It's really going to be awesome.
We were talking about it the other day, about the content of the workshop. It's just going to be a fantastic workshop. A necessity for any team that really needs to push the boundaries on what they're delivering to their clients and customers. Today we get to talk to Jeff about it.
Jeff, how are you?
Jeff Gothelf: I'm well, Jared. It's great to be back. Thanks so much for having me, both back on The SpoolCast, but as well at the event.
Jared: Yes. Yes, it is something that I've been looking forward to having you back. This is your fourth time, right, third or fourth?Jeff: Third or fourth, yeah.
Jared: You've been a very popular and very highly rated workshop presenter. I don't know if you know that.
Jeff: I knew some of it. I credit it all to my boyish good looks. That's what it's about.
Jared: That it is. You're the Bieber of the UX world.
Jeff: That's right.
Jared: Speaking of Lean...
Jared: It must have been four or five years ago when you did the first workshop for us. At that point, that was before the book had come out.Jeff: Yeah.
Jared: That was when Lean UX was one of these new buzzwords, and everybody seemed to have different ideas about as to what this phrase, Lean UX, meant. There were all sorts of common misconceptions. People thought it was UX without any effort, we just cut out all the items, and just claim that we've done user experience. People thought it was just massive shortcutting of good technique and process.
Has that changed? Do you run into less of that? Do people seem to know what it is now? I mean, the book has been out, and you've been talking about it, other people have been talking about it. Has that changed a bit, or do people have new misconceptions as to what it is?
Jeff: Yeah. It's definitely gotten better. It was very, very tough the first couple years out, teaching and talking about this stuff. There seemed to be a genuine desire to figure out how to bring many of the UX and design practices into worlds that were becoming increasingly more agile, both lowercase a as well as the religion, uppercase a version of Agile.
Back then it was, "Hey, this is shortcutting. This is lazy. This is undoing years of training that we have worked so hard to get our organizations to finally buy into UX. "I don't see that as...
Jared: You bastard.
Jared: You're ruining it for all of us.
Jeff: There was some of that, for sure. I don't see that as much anymore. I think what's been super helpful is five years of really putting the message out there, and then practicing the work, then case study, after case study, after case study.
Now look, what's working in our favor, in this case, is that...again, speaking from my anecdotal experience, but my anecdotal experience means that I stand in front of hundreds of people, almost on a weekly basis, whether it's a conference, or a workshop, or a keynote, or something along those lines.
When I ask the question, "How many of you work in an Agile environment," 100 percent of the hands go up. There's always a couple of hands in the back that are kind of waving in that [deliberating sound] kind of signal that they're making, but essentially every organization is at least using the language of Agile. They're not necessarily practicing it, or practicing it well, but they're using the language.
There are very few people who will raise their hand, and actually and admit to being a Waterfall organization these days. There is a desire and a drive, both from the folks running these organizations, as well as the teams working in these organizations, to figure out how to do great design in this increasingly Agile world.
The resistance has definitely come down. The conversation has gotten a lot more realistic, which is really what I find to be the fascinating part now.
It's not so much, "I don't believe in this, I don't think we should do it. It's poor design practice," but it's more like, "OK. I buy into this and my org is interested in doing better design. How do I do this in healthcare? How do I do this in medical devices? How do you make this happen in financial services? How do you deal with a 150-year-old brand that's not very comfortable running experiments?"
I'm really happy to say that the conversation has moved from resistance to the idea, to domain specific challenges more than anything else. That's encouraging. That means people are trying it. That means people are interested in trying it. They just need to figure out how to make it work in their specific domain, or corporate context.
Jared: Is the myth that we are reducing things down so light that we're going to miss important stuff? Do you still run into that at all? Do people really understand that this shifts the way the conversation happens?
Jeff: The biggest obstacles right now, when it comes to is this too light, or is this not informative enough, generally comes from the visual design space.
I'll be honest with you. If I had to list one of the biggest challenges in winning teams over, and providing concrete insight about how to make this work with everybody on the team, visual design is, by far, the biggest obstacle at this point because there's a subjectivity there to the level of fidelity that's necessary to learn what you need to learn.
The conversations that we have with teams that ask us those questions, "Where does visual design fit into all of this," really relate back to their brand, and back to the definition of what, ultimately, the conversation ends up around minimally viable products. People try to pigeon hole that conversation as, "An MVP is X and, therefore, it can't be anything else."
I think that that's one of the biggest misconceptions and challenges. For example, take a brand like Warby Parker. Warby Parker is a fashion brand.
They're a startup, and they were running on many highly risky assumptions that they could really bring low-cost, high-end fashion to eyewear, and, somehow, deliver this through technology. Now, when they're going out to test these assumptions, and these hypotheses that they have about their business, they can't go out as a fashion brand with an MVP that looks like Craigslist.
It's not going to work. Their brand, their audience, and their hypotheses rest on some assumptions that they can create a desirable brand for glasses, for eyewear.
The amount of visual design, and brand work that they require to build their MVPs, that they required to build their MVPs, would be significantly higher than if you are running a landing page test for a top-of-the-funnel, B2B sales service. There's an amount of visual design that you don't need in building MVPs for the B2B sales service that you would require for a brand-conscious or fashion-related brand.
I think that that's been where some of the biggest challenges have been, and really comes back, again, to the definition of MVP. Which again, one of my favorite exercises to do in the workshops is to go around the room, and have half a dozen people define "MVP." You'll get half a dozen definitions.
I always come back with, "It's the smallest thing that you need to make or do to learn the next most important thing."
Jared: Right, and that learning part is the thing that I think trip a lot of people up. What I see happens is someone who's higher up the food chain in the organization hears the term "MVP," and thinks that it really does mean "Oh, we're just going to ship something faster."
Jeff: Yeah, phase one.
Jared: Right, exactly. Then, you have this conflict of mindset in the organization where the people who know what MVP means think it means what it really means, this idea of producing something that'll help you find out the next piece of information versus the first product.
To some extent, the acronym gets us into trouble. It sets an expectation that it's a product. "Minimum viable product" actually sounds like something that is got all the attributes of a product that will sell and be profitable.
Jeff: Look, that's why you see blog post, after blog post, after medium article, after minimum lovable product, minimum viable effort, minimum viable experiment, minimum marketable feature, all of these variations on it. It's a confusing term, and you're right.
What it boils down to, I think, is the overwhelming majority of organizations, big or small, value delivery over learning. When they hear, "Minimum viable product," they say, "OK. Product, ship it. I'm on board with that, because what I want to do is ship features, or ship product."
It's extremely difficult, especially in a large company, but also in small companies, as well, to move people, to shift the culture, and the value that the organization places on delivery to one of valuing learning. That's the key.
I think if you can successfully start to shift the organizational mindset to one that values learning first and, then, delivery second. In other words, let's figure what we need to ship, and then ship it, then it doesn't matter how you define "MVP." As an organization, you're focused on learning, first.
I won't lie. It's a rare organization that truly embraces this particular shift in culture and shift in values. When it's done right, the products do better, the teams do better, the risks that the organization takes are significantly smaller. That's really the goal of all of this.
I joke about this all the time. All of these, Lean UX, "Lean Startup," "Lean Enterprise," all of these approaches to working. They're risk mitigation, that's what it is. Ultimately it's just risk mitigation, which perhaps doesn't make a sexy book title, but that's the end of the day. We want to make sure that we're not wasting our time working on things that don't stand a good chance of succeeding.
Jared: This brings me to another thing that I've been having conversations with folks about. I was talking to somebody about something that had happened to one at my clients.
We had a client who was really into Agile, was really thinking they were doing Lean UX. Then they said, "We've got this important project coming up. Before we get the Agile project going, we're gonna spend six weeks gathering requirements so we know what the Agile project's going to be."
I'm like "Wait, wait, wait, wait. What do you mean spending time gathering requirements?"
"Well, you know, we have to hone it down to something that we can do in the Sprints. We have to scope it, so we need to talk to all the stakeholders, we need to find out what they think this needs."
"Of course, none of the stakeholders agree, so we have to negotiate with all the stakeholders to get the requirements down to a set. We're gonna write these documents, and then we're gonna start our Agile process, and our Lean UX process once we know what it is we're trying to build."
Jeff: Right. Again, this is obviously a holdover from the Waterfall world. It provides a false sense of security to the people involved in that project, the people who've been tasked with delivering that thing. First of all let's start with that, right? Those people who have been tasked with delivering something, a set of features. Let's be clear.
Jared: What I'm sensing is there's a little bit of frustration, and fear, outright fear, of just going into a project having no sense of scope.
Jeff: Yeah, and that's perfectly OK. It's perfect you got to have that fear. You should have a sense of the business problem that you're attacking. You should have a sense, at a high level, of the type of solution that you're considering building to solve that problem, and that should give you a sense of scope in the T-shirt sense of scope, small, medium, large, extra-large.
That's the sense of scope. This is potentially a massive effort, because we're thinking about reinventing e-commerce, or it's a relatively minor effort in that we're just changing the way that people authenticate into the product, hypothetically speaking. Again, it's about how the projects are framed.
If I'm a middle manager, and I'm tasked with shipping an iPhone app, that's my task. Then, I'm going to go figure out what needs to...then, understanding the requirements that need to go into the app, feels like the next natural step in the process. "OK. Let's figure out what are the features we want to build in the app, and let's go build the app."
That boils right back up to that discussion that I had a second ago about a culture of delivery. We've given a team a mandate as the iPhone App Team, perhaps they're even known as the iPhone App Team, in which case, they must then deliver an iPhone app.
Seeking the requirements, and then chopping these requirements up into sprints gives the leaders of that project that false sense of control that we know what we're going to build, and we know exactly how long it's going to take, and when it will actually ship. Of course that inevitably breaks down.
Now, if you take that situation, you flip it on its head, and you change the name of the team from the iPhone App Team to the Mobile Commerce Team, and then you change the way that you task that team, you no longer ask them to build an iPhone app.
You say, "Your job is to increase mobile commerce, increase the amount of sales that we do through mobile channels." That fundamentally changes the task of that team. They don't necessarily have to ship an app, they don't necessarily have to ship anything.
Jared: They just have to improve commerce.
Jeff: They have to improve commerce. What happens there is the measure of success changes. It's really easy to manage delivery. Delivery, in the sense that if you are the iPhone App Team, and your job is to ship an iPhone app, then that's a fairly binary thing. You either shipped the app, or you didn't, and so you won, or you lost.
It's a lot more difficult to manage to this type of outcome. You say, "Hey, your job is to increase mobile commerce by 15 percent. We're not gonna tell you what to build. You have to figure it out." At the end of a period of work, let's say 6 months or a quarter, your team comes back up in front of the organization, and says, "Well, we increased mobile commerce by 4 percent. Did we fail? Should we go again?"
It's about learning, "Well, terrific. You did 4 percent, how did you get there? Can you scale that up, or is there another approach?" Again, what they build is not required. There are no requirements upfront. The requirement is an outcome it's an objective, "Achieve this particular business goal."
They get to figure out whether it's an iPhone app, or whether it's geolocated SMS alerts to buy certain things based on where you are, or maybe it's a WhatsApp integration or, who knows. Facebook messenger integration for customer service like they're doing with some brands right now. Ultimately, the team decides what they're going to build based on how they're affecting customer behavior.
The concept of requirements, at least upfront requirements, goes out of the window. The team then has to experiment, and learn which ideas drive customer behavior in that particular direction. Then they define the requirements for the ideas that actually move customer behavior towards their stated objective. It flips the whole conversation on its head.
The scope becomes time. Let's say we're going to work on this for three months, and then we'll figure out at the end of the three months if this is something that we should continue to work on, because we'll know if this is something we should continue to work on. Because we've been trying to achieve this particular outcome for three months. Again, this assumes that it's then safe for the team to come back and report their findings very openly, very frankly.
Because they may come back and say, "You tasked us with increasing mobile commerce by 15 percent, we don't believe this is achievable. We've been working for three months, we think this is a waste of time. We need to figure out a different way."
Or, they may come back and say, "Hey, you know what, it's been three months, we hit 15 percent. What do you want to do next?" Whereas, an iPhone app would have been given a year. Maybe you don't need a year. Again, it's about shifting the conversation.
Jared: Other than shipping an iPhone app, it doesn't have any business goal that you can point to the bottom line and say, "This was worth it."
Jeff: Yeah, exactly, the "so what." No one is asking, "So what?" Few organizations ask that question, "Hey, we shipped this feature, we shipped the app." "So what?"
Jared: Do you have different ways you phrase that question? One of the ways that I've been using is "Imagine we do this project, imagine we ship this app, and a year has gone by since we shipped the app. What's different?" I find that oftentimes, when I do that, I get this deer in the headlights stare of, "Well, we shipped the app. [laughs] There's an app in the world that wasn't there before."
"OK, but what's different? How is the business better?" "Well, because they're using our app." "OK. What are they using our app for?" "Well, we have to figure that out, that's what the requirement thing is for." "No, no, no. [laughs] What outcome does the business need that an app is the right way to get there?" Sometimes that conversation's really hard to have.
Jeff: It's extremely difficult because most of the people tasked with doing that work have never been asked that question before. It's not how they're incentivized.
They get their bonus, or they get to keep their job if they ship on time, and on budget. It's not about, "Hey, did you actually move the needle?" It's, "Did you ship it?" That's what they're test with and that's what the incentive structure is. That's unfortunate.
The conversations we have, similar kind of things. My favorite question when I talk to new clients is, "How do you determine success in your organization?" Invariably, the response is always, "That's a really good question."
Jeff: A hundred percent of the time, that's always the first thing that comes back, because they have to think about it. They have to think about it beyond shipping.
Jared: You would think that that would be the thing that everybody could just come out off the top of their head, as if they said it a thousand times. This should be the thing they wake up and talk about every day.
It should be the first conversation. "We're Pinky and the Brain."
Jared: "We're going to do what we always do. We're going to try to take over the world." At least they knew what they were trying to do. [laughs]
Jeff: That's right. It's amazing. Again, it's because of the way that they're being tasked, and the way that they're being paid.
Jared: Right. No one's paid for success. People are paid for getting shit done. [laughs]
Jeff: It's true across the board. There's this perception that, somehow, delivering stuff is valuable.
Jared: Yeah. You're absolutely right.
Jeff: Again, no one...Not no one, but very rarely does anyone ask the question, "So what?" One of my favorite, and I'll probably use it in the workshop at UI20, but it's one of my favorite photos, there's this guitar. I forget the name of it, but I used a photo of it.
It was a guitar that was custom made for Pat Metheny. It has dual necks, and 18 or 20 different strings on it, a variety of knobs and controls and so forth. I always reference it as the Microsoft Word version of a guitar. 95 percent of the things that are included in this particular guitar are useless to 95 percent of the population. Only a couple of people can actually use a hundred percent of these things.
Microsoft Word is exactly the same way. We all use the same 10 features. There's a thousand other ones that only five other people use. That's the conversation that I like to have with people that I'm working with.
It's a question of...shipping features is not a measure of success. Let's figure out what customer behavior we actually want to impact, and then decide how we're going to impact that customer behavior.
Jared: I'm looking at this crazy thing. This is the Picasso guitar by Manzer. I found it by just googling "Pat Metheny custom guitar." This is insane. It's got 42 strings.
Jeff: 42 strings, yeah, exactly.
Jared: And four necks. [laughs] Apparently, he actually played it in concert a couple of times.
Jeff: Yeah. Again, awesome. If you're the Pat Metheny of Microsoft Word, terrific. All that bloat has value to you. This is why products like Sketch and Pixelmator are clawing at the Adobe Creative Suite products. Because Photoshop is Microsoft Word of photo editing.
Jared: Right, it's got 42 strings, and 4 necks. Deep inside is a feature that somebody asked for that no one's ever used.
Jeff: Yeah, and then you fire a Pixelmator, and you're, "OK, I can crop. I can resize. I can put a couple of filters on there, tweak the levels a little bit, and ship it. That's what I need Photoshop for 97 percent of the time.
Jared: Right. This is exactly, I think, what the problem is. Are there tricks that you've learned, like having everybody repeat first thing of the day, "Our goal is not to ship an app. Our goal is to increase e-commerce, mobile commerce sales"?
Jeff: The trick that we use, the trick that I've used repeatedly, and it's UX 101. It's go meet your audience. Go talk to your people. This comes back to UX, which is the beautiful part about all of this.
We've been here all along. Now is the time in that, this is customer experience. This is go meet, go see how your users currently solve these problems. Go talk to them about what's valuable to them, what they actually need the thing to do.
Get a sense of what's getting in their way, what's keeping them from solving these tasks today and then solve for those problems, for those real problems, not for the thing that you think that they actually need.
I know you promote this in everything that you do, and everything that you've done in your organization. People have been talking. It's not that I invented this, or that Eric Ries invented it, or Steve Blank invented it.
It's so easy, and yet, practiced relatively infrequently. It's to have just a continuous qualitative conversation with the market, so that you always have a sense of what your audience is doing, and what they're struggling with.
I have another story that I'd love to tell, which is back from my days at The Ladders, we used to talk to three customers every Thursday.
Jared: Three customers every Thursday?
Jeff: Yeah, three customers. We'd recruit them on Monday, and we'd figure out what we would talk to them by the time they showed up. I did this every week for three and a half years. When we started this in 2009, late 200, early 2009, every conversation with a customer starts off with a little context setting. "Tell me a little bit about yourself."
In this case it was, "Tell me a little bit how you look for a job. Tell me about your family situation. When we started in late 2008, early 2009, the context setting conversation revealed that text messaging was not a legitimate form of communication for our target job seeker audience.
We're talking about executives with 25 to 30 years of experience, typically in their mid-50s, or older, teenage kids. Text messaging in late 2008, 2009, was something that their kids did. Maybe it was something that they did with their kids.
That was simply learned...It wasn't a direct question that we were looking for. We weren't looking for features to build text-based features. We just simply learned that by having this regular conversation.
Now, having this continuous conversation over three and a half years, by 2012, late 2012, early 2013, it became very clear that there was a significant shift in the mental model of our targeted audience when it came to SMS and text messaging.
All of a sudden iPhones are much more prolific, and text messaging becomes this way for executives to get around their corporate firewall, their Blackberry corporate firewalls, and have private conversations that their bosses can't see. Especially if they're job seeking, this is really important.
Again, we weren't seeking out this information. But by having this continuous qualitative conversation with our audience on a weekly basis, we began to see this shift, and then, ultimately, start to take advantage of it.
That's the trick. The trick is to know what your customers are trying. Why were they doing it? Because they needed a private channel. They needed something that their bosses couldn't see, and this provided that.
All of a sudden you've got a sense of what problems are arising and opportunities. Then that's where creativity and genius comes in to creatively solve those business problems.
Jared: This has been really enlightening.
Jeff: I'm glad. [laughs]
Jared: I think there really is this nice idea of reframing what you're trying to do, and getting everybody back on page, and then using the users as the way to keep them on the right page.
If it's resonating with the users, as you're testing your assumptions, as you're testing your hypotheses, then you're going in the right direction.
It doesn't dictate the deliverable or the outcome from the get-go when you don't go down this rut of saying, "Well, we have an app, and if we have an app that must mean that we have a splash screen. On the splash screen we have to have this, and this, and this."
It's like, "No, it doesn't say that you have to have any of that stuff."
Jeff: Yeah, we discover. We call a part of discovery, you'll hear the other folks in the space talk about it, Marty Cagan, Jeff Patton, and all of those guys talk about product discovery.
That's what we're doing. We're discovering the product. We have a sense of the business problem we'd like to solve, and we're discovering the solution as we go.
Jared: That makes it sound so much easier than the way so many folks want to do it.
Jeff: And yet. [laughs]
Jared: And yet...which is why you have to give this workshop at UI20. Did you know you're giving a workshop at UI20?
Jeff: I did, yes.
Jared: Did we tell you that?
Jeff: You did.
Jared: That's good. Our communication's working. For the rest of you, if you want to hear this and spend a full day with Jeff talking about exactly how you can reframe these problems in your organization, you want to come to UI20.
You want to sign up for Jeff's incredible workshop. You will not regret this. You want to do it soon, because his is always one of the first ones to fill up and sell out.
You want to make that happen. It's going to be November 2nd through 4th. It's in Boston, Massachusetts. You can find out more about it at uiconf.com. I'm so excited that we're going to do this. Thank you, Jeff. This has been really awesome.
Jeff: Thank you very much, Jared. It was my pleasure. Always fun chatting with you. I look forward to seeing you in the fall.
Jared: Yes. To the rest of you, thank you so much for spending time with us today and listening. As always, thank you for encouraging our behavior. We'll talk to you again. Take care.