073: The Unstoppable Designer with Jeff Gothelf

Jason Ogle: All right today I have with me Jeff Gothelf and I don’t know if Jeff really needs an introduction.
Jeff is an author. He’s a speaker he’s done so many things. So he helps organizations build better products and executives build cultures that build better products.

I really like that a lot. He’s the co-author of Lean UX, which, I’m sure if you haven’t read yet, I’m sure you’ve heard of it. He’s also been a co-author of Sense & Respond, which is a great book as well. just recently, and I just found this out, Forever Employable, which is coming out pretty soon and I think the timing couldn’t be better.

Jeff works as a coach. He’s a consultant and a keynote speaker, as I mentioned. And he’s done a lot for our field. I can’t wait to dive in and I got to say a fun fact about Jeff. I love this. His first job was in a traveling circus. I can’t wait to learn more about that, Jeff, but first of all, I want to say welcome officially to User Defenders. I am super excited to have you on the show today.

Jeff Gothelf: Ah, awesome. Jason, thanks so much for having me. That was a great intro. So I think the answer is yes, I needed an introduction. I needed that introduction, which was great. So thanks for that. It’s a pleasure to be here and I can’t wait to share some stories.

We could talk about the circus. I’ve got about a thousand stories from that or anything else you’d like to talk about.

Jason Ogle: I’d love to hear one circus story. Yeah. What did you do in the circus?

Jeff Gothelf: Yeah. So look, this is a long time ago, just to be very specific how long it was 25 years ago. I actually had hair back then and it was long hair. So my running joke was that I was the bearded lady. That’s a, that’s my running joke. but I was not the bearded lady, in the circus.

I actually, I think that, sound and lighting. For the Clyde Beatty Cole Brothers Circus, which is at the time was the largest three ring tented circus in the United States. We were a traditional. Three ring, tented, elephants putting up the tent type of circus.

And at the time, 25 years ago, when I was graduating from university, I was heading into what I thought was going to be some kind of a career in audio production. I wanted to be a, an audio engineer record producers, something along those lines. And I got a gig right out of school. In the circus doing live sound and lighting for the circus.

So that’s what I did for six months. very crazy six months, amazing that I remember them vividly to this day, 25 years later. yeah.

Jason Ogle: That is awesome. That’s amazing, man. I’m sure you have a lot of stories, but we probably, we could take up the whole time talking about it.

Jeff Gothelf: Easily.

Jason Ogle: That’s fun on the resume. So we’re going to, we’re not going to be talking about the circus today, unfortunately, Defenders, but, we are going to talk about product design, about UX, about Agile and, whatever else comes about in the midst of this. Jeff. I tried to think about some questions that maybe you haven’t been asked before. I don’t know if that’s possible, cause I know that this has been a passion project for you for many years, and I know you’ve done a lot of talks and interviews and so I hope I can keep this fresh, I guess for you, I’m going to ask some questions that maybe are a little different than normal.

So yeah, anyway, I’m curious, UX is really. If you think about it, it’s still a pretty new thing. And in our industry of software development, it’s that the practice of UX? I know that if you want to get semantic, we can talk about, the early days of aviation and ergonomics.

And some of that of course was user experience. But I think in our field of developing digital products, This is still relatively new and Agile is still relatively he knew. And I think that there’s just a lot of mystique to how a UX design team and process integrates, most efficiently into the Agile process.

So I guess on the outset, I would love to. To get your thoughts on what that looks like in an ideal, even if it’s in a perfect world, what should we as designers? How should we, as in the design process, integrate most efficiently into Agile.

Jeff Gothelf: Yeah. So I have direct experience building a team that had to deal with this first hand in a world where this was even newer. So we’re talking about 10 or 12 years ago, in fact, and that’s where this whole Lean UX conversation came from . The work that we did as a team there, the work that we shared with others who were struggling with the same challenges is an approach to doing this.

It’s an approach that worked for us. It’s an approach that’s worked for other people and like anything else, it’s a framework. It’s a starting point. And so anything that I share with you and I’ll share a specifics here in just a second. Anything that I share should be treated as a starting point, rather than a destination.

It should be the first thing that you try. That’s fine. But then you’re going to wrap that thing or that framework of that process in the context of your organization, of your target audience, of your regulatory issues in your domain with your corporate politics, with whatever’s going on in the world.

And so the way that you do that, In your world is going to be different than, probably than what I say to some extent, but it’s a good place to start, but always thinking about how you can adjust it to make it fit your world. The most important thing we learned, so we tried, honestly this was years ago now, but at the time we had tried.

Every, what felt like every permutation of integrating UX into Agile or Agile into UX that we could have come up with. We tried to take our entire process, which took anywhere from three to six months and squeeze it down into two weeks. That was a disaster. There’s just no way you’re going to get a three month level of effort done in two weeks, but we tried, it didn’t work out. we tried doing the sprint ahead. Models. So where design works for a sprint and then hands off their work to engineers so that they can build the thing. And then we moved on to the next set of tasks.

Now that is a. Step in the right direction, but it’s definitely not the goal because all that really is as many waterfall. You’ve just taken what you’d normally do in three months cycles and reduced it to two weeks cycles. So in a waterfall world, if you’re lucky you get a month, two months, three months for the design phase, and then you hand off here, it was just reducing that timeframe to two weeks.

So when you design, there’s still no shared understanding, there’s still no collaboration and worst of all, there’s still that negotiation during the handoffs. So if you think about the anti-patterns of software development, when it comes to design and engineering working with, well together for me.

From my personal experience, it was always the negotiation for me. That was the biggest, anti-pattern the worst thing that could happen, which is I worked for however long, a day, a week, a month on my design. I’ve, wireframed everything I’ve created the spec document, the prototypes, whatever it is. And then I showed it to engineers, in the first word out of their mouth was no Right now. No, there’s no way we’re doing no. Yeah. surprisingly, I’m not building all of this. I’m not no way we can get this done. It’s unrealistic. It’s too hard, it’s unnecessary, blah, blah, blah. And then all of a sudden, on a good day, on a good day, 50% of my work got implemented. that meant that on a good day, on a good day, 50% of my work I’ve thrown away. And that was too much for me. The amount of waste that generated just simply my own, forget everything, everybody else that had to deal with that. Just me personally, understanding that on a good day, half of my work is going to get thrown away.

That sucks. And so right. And so even when you do the staggered sprint model, where designers work ahead of engineers, you’ve still got that hand off and you’ve still got that negotiation. So the goal we were shooting for the target audience, the target, condition, if you will, which is a nice lean phrase, lean manufacturing phrase, the target condition for us was to eliminate the negotiation. Which meant the only way that this is going to happen is if the entire team product design and engineering is working on the same thing at the same time, that’s the only way that you start to eliminate the handoffs and the negotiations. Because if you’re working on the same things at the same time, then you’re building a shared understanding.

Of the work you’re building a shared understanding of the problem that you’re solving a shared understanding of the customer. And most importantly, you’re building a shared understanding of what success looks like. And if you have that if you have that together as a team, that alone cuts out a tremendous amount of unneeded unnecessary conversation. And so all of a sudden you can start to focus on the things that actually matter. And the way that you do that is by number one, as a designer, opening up the design process. And this was something that was difficult, certainly for me and for a lot of folks and continues to be difficult for a lot of designers, because it can feel like you’re devaluing your job.

So if I open up the design process, And everybody can offer their opinion and offer designs and design suggestions. What value do I bring to the table? Why do I even need to be here? Just let everybody say what they want, build it. But of course that’s not true. I think what I’ve learned over the years is that by opening up the design process and inviting others into it, They see just how hard it is.

That’s number one. So they truly understand the value actually even more.so, understand the value that you bring. Believe me, if you’re working with somebody and you disappear behind your monitor for a week and you come back and you say, “Tada!”, I made this thing, isn’t it awesome. and they might say, “Yeah it’s awesome.”, or, “I dunno, I don’t like red, why did you choose red? And also there’s no way I’m implementing all of this because it’s too difficult.”, they’re never going to know how much effort went into that. They’re not going to know why you made those decisions. You’re not going to understand what the rationale was behind the choices that you’ve made.

And so when you include. Non-designers people and non-designers any people that don’t have design in their title, in the process. You’re exposing them to the work that goes in to making good design, to the decisions that you’re undertaking. And you’re offering them the opportunity to participate in that process to offer their thoughts well in advance of you finalizing anything so that as you start to finalize the design, their feedback is already baked into it.

So they’re bought in. Even if it’s something small, that somebody said to you was like, Oh I told him to move that button to the right three pixels and he did it. And so now I feel like I was heard. So cross functional collaboration, everybody working on the same thing at the same time, shared understanding of the customer and what problem we’re solving for the customer.

And then opening up the design process to allow others to participate in it. And this includes big D design, a design as the umbrella term for all of the various things that we do as part of not just interaction design, but visual design research, prototyping, copywriting, right?

Let’s make sure that people are aware of what we’re doing and why we’re doing it. And if they’d like to contribute to that, Terrific. The other thing that I think is extremely powerful in ensuring that user experience gets included in every sprint is to. Bring the non-designers along with you every single time that you sit in front of the customer, or you have a conversation with the customer, there’s nothing more powerful than watching the people that you’re making products and services for struggle with the thing that you built for them.

And so that starts to build that empathy with your engineering colleagues, with your QA colleagues, with your, sometimes even your product colleagues, not every product manager, gets it, right off the bat, which is extremely valuable. So that’s at the high level. I can get into a lot of more specifics about how to manage your backlog and that type of thing, but at the high level, a, from a process thing, it’s about transparency and it’s about collapsing. the efforts into parallel paths that happen at the same time.

Jason Ogle: I love that. And the involvement of other disciplines in the design process, It seems like you said at face value, as designer, why am I needed? and I think as a designer, one of the hardest parts about being a designer is that sometimes, particularly, of course, with visual design, it can be so subjective.

So I always say, I don’t tell a pool cleaner how to clean my pool, yet everybody has an opinion on what the design or what the visual design looks like, I think there’s that part of it, but there’s also like the deeper levels and I’m a big believer in visual design.

I come from an advertising background and I there’s a lot of value to good visual design of course. but then there’s other levels of design and I think there’s maybe just that, That lack of understanding, perhaps amongst other disciplines that it’s not just about making it look pretty. It’s about how the interactions take place.

It’s about who the users are about, what their needs are, what their environment, their context. There are so many more things and you’re right. Jeff, other people don’t know it if you never invite them into the process. and they may just think that all you’re doing is making something pretty. And so I think that’s an awesome takeaway Defenders, right there.

Just try to open up the design process more. Don’t feel threatened, be confident in your skill set knowing that doing that will actually help other folks understand how hard your job is.

Jeff Gothelf: And I look and I believe that in doing so you start to develop a skill set that I think it’s becoming increasingly more valuable for designers these days, which is facilitation. so facilitating, look, we don’t work in a vacuum. We work on teams and those teams have stakeholders.

They have clients, or they have customers, inevitably, you’re going, there’s going to be inbound. input to use a nice word, right? feedback from those folks and your job as a designer is going to be to synthesize all of that into the next iteration of the thing. And so if you can successfully facilitate those conversations in a way that.

Benefits you right? Benefits your work to make you more successful. And then ultimately the customer, that’s a fantastic skill set as well. So as you open up the process, facilitation becomes a skill that I would absolutely invest in. If it’s not something that you know how to do, or that comes naturally for you, it’s an absolutely worthwhile skill to invest in.

Jason Ogle: I love that. that’s an awesome takeaway too. Facilitation is, it’s. Being able to present your work confidently and being able to explain why you did something is a really great skill and articulate that in a way that business people, stakeholders C-Team that they can get behind and they can understand cause they’re not gonna understand these ins and outs of the design itself as much, they are going to understand and resonate with the business impact that this design is going to make. That’s a great testament to that. And then just being able to, get up and speak. I is a skill you’ll take with you anywhere you go. If you decide to leave UX, if you decide to do anything else, you still gotta be able to sell what you’re doing. You still gotta be able to market yourself.

You always have to be able to do that. So that’s a great skill just to practice and to grab hold of any way, no matter what you do, especially in UX.

Jeff Gothelf: Yep. And I do want to call it a distinction because I wholeheartedly agree with you, Being able to compellingly tell, a story when you’re in front of a room of colleagues, stakeholders, customers, clients, bosses, C-suite, whatever is yet another very important skill.

And then if you can combine that storytelling with an ability to facilitate the kind of feedback that is going to help you improve that design. You become, I think you become an unstoppable designer in that sense, right? Because look, you don’t know everything. Nobody knows everything. And there are there all of these kinds of forces at play on the thing that you’re building and the thing that you’re designing.

So if you can extract the business context that you need from. The business stakeholders, if you can extract the technical constraints and challenges that we’re facing in delivering the kind of service that we’re hoping to from the engineering leads, That starts to, and that takes facilitation, right?

Facilitating that, drawing that out of people after you’ve told your compelling story, you’ve really, I think you become a really unstoppable designer at that point.

Jason Ogle: I love that. And you may have just named the episode there, Jeff, the unstoppable designer. I love that. That’s great. One of my biggest frustrations as a designer, more historically, not as much lately, thankfully I’m in a different environment, different job. There’s a lot of value and emphasis on UX where I am now. But, especially earlier on, and you touched on this a little bit, Jeff, with kind of some of the waste that you were experiencing with all the work you put into something, and maybe you were in your cave for a week or two, and then you come out, “Tada” right. that’s not how thankfully how we designed products anymore.

Thanks to Agile and a lot of more understanding around that process. but I think for me, seriously, one of my biggest frustration was again, being more of a visual designer background was working on something for so long and then handing it off to the engineering team. And then like knowing how to code that myself.

I know some front end code and I know no I could do it and make it look exactly like what I put on the screen. keep getting it back after the fact. Again, probably two or three days, maybe two days, if I’m lucky before it was set to go live where it’s almost as you in, are you planning this? cause they know I’m going to come back and say, these are, this is all wrong.

Basically what I’m getting at is phase two reality or myth , how does a product team actually get to phase two? And is it even possible?

Jeff Gothelf: The opening line in Lean UX, right? The biggest lie in software development is Phase 2. And in the waterfall world that’s true, right. Phase two was where ideas went to die. They’re like, ah, like the death knell for an idea was, Oh, we’ll get to it in phase two.

Jason Ogle: Yes,

Jeff Gothelf: Which means we’ll get to it next. Never. that’s, when we’re getting to it. and that was true because look in the waterfall world, we worked on something for so long, Even if it was six months, nine months, 12 months, a year and a half, some projects go on for three years or even longer.

When you finally shipped a thing and you get your tee shirt and you have the party and like you’ve never, ever want to look at that thing again in your life. and that’s, and rightfully so because you’re burned down on it. And so phase two is a thing that alluded a lot of waterfall projects in Agile software development done properly.

Let’s qualify it as that right. Done properly. Every sprint is the next phase of the project. So phase two phase X is a thing in that we are continuing to iterate on the work and continue to make it better based on the feedback loops that we’ve built into learning that we’re getting back and that type of insight, you could even break it down. And if you don’t want to think about each sprint as a phase, you can think of every Epic as a phase, but even epics are significantly shorter. In most cases, there should be than a waterfall project. And so phase two is a reality.

The concept of the next version of the thing is a reality. If we change the measure of success for the project, that’s the thing that makes the difference. So in waterfall, measure of success for the project that we worked on was shipping the project. And so you shipped it and that’s where you had the party and you got the tee shirt and you moved on to the thing, The project t-shirt right. That’s the project diamond on it or whatever it was, whatever it’s called. and, when people switch to Agile, they. Treat and still do to this day, treat it as a fact faster way to ship stuff, To deliver features in that world phase two struggles to exist.

It struggles to exist because, we shipped it. It’s done. It’s even an Agilent. It’s in the done column. It’s in the done column. If you have one of those columns on your board, right? Some people have a done column. I’ve seen those. If it’s done, why would I go back and work on it again?

It doesn’t make any sense. That’s the key when you shift. The measure of success of a project from an output for making a thing to an outcome, a change in the behavior of your users or your customers phase two phase N exists by default. And the fundamental difference is this. if you’re a member of a team, And that team is the iPhone app team, right?

Here’s an example, right? The measure of success for the iPhone app team is shipping the iPhone app. That’s the name of the team? That’s the measure of success, right?

Jason Ogle: Mmm hmm.

Jeff Gothelf: Is there a phase, two of the app? maybe not, but we shipped the app. So we’re done, If you take that same group of individuals and instead of calling them the iPhone app team, you call them the mobile commerce team. And the measure of success for them is to increase mobile commerce by 25%. Right now, implicitly phase two phase three phase X has to exist because the team has to go discover. Do design research, prototyping, product discovery, interviews, whatever it is, What combination of code copy design value proposition business model helps achieve an increase of 25% in mobile commerce.

They don’t know off the bat, what’s going to do that. And so they’re going to try something and then they’re gonna learn and they’re gonna try it again, and then they’re gonna learn and they might try it slightly differently. And they’re going to continue to iterate and move forward. with that guy in mind, the goal, remember the goal is not to ship features at this point.

The goal is to change behavior, to change, to get, to change to an outcome, to increase mobile commerce, to get people buying more through the mobile channel. And so in that world phase two exist by default because it has to, because you’re not going to get it right the first time. Very few people are going to come right out of the gate, be like, boom.

25% lift in mobile commerce, drop the mic. I’m done, I’m gone. I’m going on break. See in a week. Like it’s just not gonna happen. And so that’s the fundamental shift. That’s how we get to phase two existing. As long as we’re managing to output phase two is never a sure thing, because we’re done, we shipped it when we managed to outcomes. Phase two has to happen because we have to continuously learn our way until we hit 25% or get really close to it at that point we’re done, but I guarantee you, it’s going to take you more than one phase to get there.

Jason Ogle: That’s really great. I feel like there’s that word done in software? it’s a paradox. It software is never done. It’s never done however projects and increments and iterations need to be done. I love engineers a lot and I’ll be honest. Like I have so much respect for that discipline.

Cause I’ve, again, I’ve. Dabbled a little bit in front end, and I know how hard that is and let alone, like once you start getting under the hood and you get, and the servers and you’re like, I, that blows my mind, all that stuff. So I have a lot of respect for engineers. I worked with many who have that done mindset though, to where it’s I just got to deliver, I just got to ship this code. I just gotta put the check mark on this and if I never have to look at this again or refactor this again, I’m going to be on my way to Nirvana. You know what I mean? Like I’ve worked with in those environments, like how do you convince engineers who maybe have that mindset to see the bigger picture maybe. And just to go for that, like phase two is important. Phase three, phase four. It may be a necessity for this product to really be the best it can be at the current time that it needs to be available.

Jeff Gothelf: It’s tough. We ran an agency initially in New York and it becoming a part of a global agency. We’re an agency in New York in between 2012 and 2015 that attempted to sell. It was a product design and development studio that attempted to sell services in a lean Agile customer centric way with it, with a heavy focus on great design.

And one of the things we were a small shop, and if we got a bigger project, we would augment the staff with, temporary engineers that we’d hire from a staff augmentation firm that we knew and that we liked in the city. and I remember there were several instances where we would bring in these engineers and we would say, look, we don’t know exactly what we’re building yet. We know what problem we’re solving, and we have a sense of what success looks like, but what we’re building, we have some space, some hypothesis. And so there’s a good chance. Look, there’s a good chance this code is going to get thrown away. So don’t worry about it too much about stability or scalability above a thousand concurrent users or a hundred concurrent users or whatever it is, right.

That type of thing. And, don’t worry about all your testing, coming out green or whatever it is, right? Like it’s just, we’re just learning. And we, I brought in some engineers from these staff augmentation firms that simply could not function like that. it was against their. Moral fiber as engineers, really to half-ass the code, which is what we were asking them to do. That’s exactly what we were asking to do. We said, look, don’t write great code. Cause we don’t need great code right now. What we need is to learn. And so you’ve really got to find engineers that are comfortable with that.

And we’ve met, we were lucky over the years to find someone, to hire them and to have them work with us now, I don’t want this to be taken the wrong way. There is nothing wrong with wanting to write great bug free, scalable, stable, secure high-performance code. that should be our aspiration.

Everybody should want to do that. But there’s a time for that. And there’s a time for throw away code that’s part of the thing. And I think that if, you’re struggling with some engineers who can’t see themselves writing throwaway code again, most powerful thing that I can, that I’ve done.

And I would recommend is to take them out, to see people using their products today. Show them how customers struggle today and then ask them how much time did you spend and making sure that was stable, secure high performance, scalable code, right? It’s Oh, I spent three months doing that.

is it useful? Is it usable? Is it helpful? No. Cool. That’s what we’re talking about. So what we’re trying to do is find the best way to solve this problem for our customers, and then we’ll harden it. And then we’ll scale it. And then we’ll put in the real engineering effort and that’s, to me, that’s the key.

And then look at the same thing goes for design as well. But you asked about engineers. so

Jason Ogle: Yeah, I’d love to hear your take on the design aspect of that as well.

Jeff Gothelf: Yeah. So look, the same thing, it’s the same, it’s the same exact logic. It’s just the output is different. So instead of spending hours and days, on screen rounding the corners and making sure that everything looks beautiful. Get something in front of customers quickly because you’re not testing necessarily, certainly at the beginning of an idea, you’re not testing usability, you’re testing value. You’re testing product solution fit that I come up with the right set of features in roughly the right order interaction model, whatever it is to solve the problem for the customer.

And if the answer is yes, then you refine and then you focus that look the nice thing. For design today is that you can get a nice looking clickable prototype out in front of people very quickly, right? Way faster than you ever had to, you ever could in the past. So that’s fantastic.

So if you’re struggling with the sort of the rough, raw versions of stuff, there’s lots of tools that can help you get something very nice looking out in front of people very quickly. So that helps in the realism. But it’s a double edged sword. It’s a double edged sword because you’re starting to set expectations, particularly with your team and with your stakeholders about what this thing might look like, how it might work, what it might do, that type of thing.

And if your early stage feedback is negative, you’re going to have to kill that idea and start again, if it took you a couple of hours to put it together, Fantastic. But if somebody, if a stakeholder saw it and then you’ve changed it a bit, where’s that thing you showed me last week? Oh yeah, that didn’t work. We threw it away, and so there’s a risk there. And so again, just because the tools can let you put something really nice looking in front of people very quickly. I would still err, on the side of rougher is better. Just to set expectations that you’re testing value before usability.

Jason Ogle: That’s great. Yeah. You’re always going from doubt to certainty and we should always be in a continuous learning mode. And the only way to learn is to you put stuff out there. and again, like before, okay. With it not being perfect. I think as designers, we tend to err on the side of perfectionism and we really need to get a lot more scrappy with our experiments and being willing to just put something together and get it out there for feedback validation.

That leads me into my next question. You said MVP has become one of the most bastardized phrases in modern software development. What did you mean by that?

Jeff Gothelf: Yeah. look, there is, it’s funny. I do a lot of teaching with Jeff Patton who, is another really great advocate for design and Agile and product management. And, Jeff knows the whole history of MVP. And I was joke him for telling the story because Eric Ries who wrote The Lean Startup was the guy who popularized MVP.

But he’s not the guy who came up with the term originally. There’s a guy named Frank Robinson who gets a very tiny footnote in the book, Lean Startup, but he coined the term. And when Frank Robinson coined the term. Minimum Viable Product, he literally meant Minimum Viable Product.

So it was the smallest thing that you can ship to market and start selling to your customers and then start to collect feedback from them. Yeah. So it was a literal viable product. But Frank didn’t sell as many books as Eric Reese. and so Eric Reese, Erica, and who sells the most books wins.

That’s how this kind of stuff works. And Eric resold a lot more books and he made it took the term MVP global, but what people, and I’m sure not everybody who bought Lean Startup, read it, but even those people who read it, a lot of folks miss the fact that what Eric meant by MVP was test.

He meant experiment. He did not necessarily mean viable product. Minimum, yes. Viable, no. And product, definitely not until you have enough evidence to justify it. And so sadly what’s happened is that organizations have latched onto this term and MVP has largely become synonymous with things like what phase one, for example, So MVP becomes our first release. MVP is the most we can get done by the deadline, Maximum viable product. it could be the crappiest thing we can get away with. I’ve heard that description as well.

Jason Ogle: Why.

Jeff Gothelf: Because what’s the least amount of work that we can get out and start selling the goal of MVP in the lean startup context was test or experiment. the MVP, the scope of the MVP is the answer to the question. What’s the least amount of work you need to do to learn the next most important thing. And the answer to that question is your experiment. It’s your test. And in Lean Startup terms, it’s your MVP. But unfortunately, and look, it’s not their fault, right? The majority of people see the words viable product. In there. And when you tell them, Hey, I’m working on the Minimum Viable Product, they’re like, okay, great. I’m getting a viable product out of this, because those are the words that you said.

Jason Ogle: Yes.

Jeff Gothelf: And so for me, these days, I usually give this little rant to my clients and to workshop attendees and that type of thing. And then we stop using that word. And then we just call it what it is we call what’s your next test, your next experiment. That’s what we’re talking about right. Now, look, to be just to be perfectly clear at some point, if you gather enough evidence, the only way to learn the next most important thing about your product is to build and ship software.

Right to build phase one, whatever that is, The first release. At some point that’s going to be the case. If you continue to get positive feedback, but rarely is it the first thing that you should do.

Jason Ogle: Absolutely. I put a tweet out recently expecting UX’ers to have all the answers the first time is like expecting Thomas Edison to have invented the light bulb the first try.

We’re scientists before. We’re pixel pushers and Thomas Edison himself said, I haven’t failed. I’ve just found 10,000 ways that don’t work.

Jeff Gothelf: Yup.

Jason Ogle: We need to take more of that approach.

Jeff Gothelf: Absolutely. James Dyson, right? At one point, if not, it’s still to this day the wealthiest man in the UK, maker of those hand dryers, we all love. And vacuum cleaners.

Jason Ogle: I’m a customer.

Jeff Gothelf: He is very open about the fact that he built 5,000 prototypes. Imagine the dedication, It’d be like 3,748 didn’t work, 3,749. But the 5,000 prototypes before he got it. Yeah. so your tweet is spot on, right? We are to expect us or a product development team to nail it right out of the gate is completely unrealistic.

And that’s why this continuous learning discovery, Agile kind of work makes sense. Small batches, right? Sprints are small batches, right? The benefit of a sprint, a small batch is that you take significantly less risk. If I work on something for nine months and I get it wrong, I wouldn’t be surprised if I got fired. I should get fired. I would fire me.

Jason Ogle: Yeah. [laughter]

Jeff Gothelf: If I spent nine months working on something only after nine months to find out I got it wrong. Because that’s too much. It’s too much investment. And the speed of the market of consumer consumption patterns of technological change is it does not simply allow you to be away for nine months and then to come out with something.

So if you work on something for two weeks and then you get some feedback and you find out that you’re wrong, fantastic. I only lost two weeks and the next two weeks is going to be far more focused. Far more accurate than they were going to be without that learning. That’s the whole point of this process and design fits squarely in the middle of that. It makes a ton of sense.

Jason Ogle: Coffee’s better in small batches, so is software.

Jeff Gothelf: That’s right. Absolutely.

Jason Ogle: Tweet that! [laughter]

Jeff Gothelf: Yeah. I told you, I’ve, it’s funny. I’ve, I have a friend, who’s a designer friend. He runs an agency in, In Italy, Northern Italy and, he’s Italian and you need to leave. They just drink it presses, It was extra, super small coffees. Yeah. But for some reason, my friend, Nick, he likes American style coffee. He’s Italian guy. But he likes American style, like a coffee pot in the coffee maker kind of coffee.

Jason Ogle: He’s an anomaly.

Jeff Gothelf: He is totally. And when I, first time I visited him, at his shop in Italy, this was a few years ago. He told me that, his colleagues in the agency that he runs, tell him that he’s drinking “brodo” and “brodo” in Italian means broth. Like soup, like you’re drinking coffee soup, and they can’t understand why he’s drinking broth.

Jason Ogle: Oh, that’s so good.

Jeff Gothelf: To this day that’s his thing. So

Jason Ogle: Broth. [laughter] That’s a neural pathway that hasn’t connected yet for me. That’s great.

Jeff Gothelf: It’s coffee soup, that’s what it is.

Jason Ogle: Love it cowboys used to say, yeah, when you put a spoon in the cup, if it stands up, the coffee’s done. [laughter] Yeah. Stands up straight ah man. That’s great.

This next question is a selfish one:

I just started at this company recently and I love it here. There’s a lot of emphasis on UX. This whole team is really new. Our business model is software. And we’ve had these incredible suite of software tools that are, indispensable, to be honest with you, with the people who use it. And I can’t talk a lot about it because there’s government and stuff involved there. But what I’m trying to say is. I’ve been really impressed that engineers have been able to really create this product and it works albeit difficult to use and some areas. and that’s why we’re here to try to help that with that.

But, we need to get some quick wins and we need to show value. What are some ways for any new UX team to do that, to get some quick wins and show value immediately,

Jeff Gothelf: That’s a really great question because I’ve been in that position myself multiple times in my career. And I think it depends on the context I’ll answer the question by sharing experiences. So instead of saying you should do this, I’ll just tell you what I did. so in 2000, this is a long time ago.

My last in house gig. Ended in January of 2012. So some of these stories are, I’ve been doing a lot of work since then, but working in house, I’ve been a consultant for eight years now. But, in 2006, I moved to Portland, Oregon to manage the UX team at web trends. At the time they were the, the granddaddy of the analytics world that even back

Jason Ogle: I remember it

Jeff Gothelf: Yeah. As far as I know, they’re still in business

Jason Ogle: They were like the Google of a analytics back then before Google had Google Analytics.

Jeff Gothelf: Correct. yeah. So before, yeah, before a Measure Map became Google Analytics, there was Web Trends. And, I went to build a UX team there. I inherited a team. There were four of us in a heavily engineering kind of organization.

And it’s similar to you. I just moved across the country, launching this new practice. How do I show quick wins? How do I show value very quickly? And the first thing I realized was that the majority of your organization had no idea what we even did. and so the first thing that I did without being prompted or asked was I started a weekly UX newsletter that I sent to the company.

And the first one was “Meet your UX Team”. I remember to this day I was like, Oh, there are only four of us. So yeah, this is me. This is that person, this person, that person, this is what was their name. This is what they do here. And this is how they can help make the product better. So that was week one, week two was that, Hey, last week we engaged on this project and we did this other thing.

Here’s what we learned. And here’s how we think we helped. Week three. Here’s what we did. So that’s one thing that I helped to raise the visibility and the understanding across the organization of who we were and what we did and how we can help. And part of that was to generate inbound leads to the team so that if people understood better, what we did.

Then they would reach us. Oh, you know what? We should get those, the you, what I call the UX guys. Yeah. We’ll get the UX guys over here. Get the UX folks over here and get them engaged. I’m working on this. And so that was one thing that I did there. So that’s one thing, one experience. I think when I started the, at the ladders, a couple of years later back in New York, and building that team and scaling that team as well, the quick wins there were again, really trying to for me, it’s always getting back to the customer first. So understanding the customer and building an alignment in the organization around the customer. One of the first things I remember doing there, I think there’s a blog post about this somewhere.

It might even be on my blog from. I don’t know, 10, 11 years ago at this point, I’ll have to look, but there’s a blog post about this somewhere where one of the most impactful things that I did, I said, look where the UX team UX stands for user experience. Who’s the user. I asked the leadership team, there were eight of them and we got in a room and we did a persona creation exercise. And between eight of them, they came up with 21 unique personas.

Jason Ogle: Oh my goodness.

Jeff Gothelf: I see. So basically you’ve got the leaders of the organization and every single one of them is dragging the organization in a different direction. and so we worked for two days together, starting with 21 different personas to boil that. I think I got them down to five, maybe six, still too many. for a very clear value proposition, right? Like job seekers and employers and head hunters. We should not have had more than three or four, but nevertheless down from 21 to five or six was a win.

Jason Ogle: That’s a big win. Yeah.

Jeff Gothelf: And again, this builds alignment and builds value.

It builds a clear understanding of what we do as a team and what we’re focused on. And then every time that we did work, we would say this work is, or this persona we’ve made little persona cards. And we said, look, it’s for this persona. Remember, this is literally it has the, one of the, like the executive sketch on it.

It wasn’t a fancy photo or anything. It was the executive sketch, so they could see their work was there. And again, that helped. And that was a relatively easy, quick win. To show value to build alignment and to give a clear sense of what it is that we do. So that’s two experiences from my world.

Jason Ogle: I love that. Thank you for sharing that. Jeff. create checkpoints and visibility into what you’re doing, what you’re accomplishing and how you’re lifting the products. The lift that you’re creating.

Jeff Gothelf: Be transparent and be proactive. So don’t wait for somebody to ask you. Don’t wait for somebody to ask to be shown something, just put it out there.

Jason Ogle: That’s awesome. Why really matters a lot I told you on the outset of our conversation here, the thing that I feel like separates this podcast from any other design podcasts, is that I really go all in on why? We got how to you just Google something. You could figure out how to do anything. I really want to know why. Why to do this?

Why should we do this? Why does it matter? Why does what we do impact the world in such a way? And so I’m curious, Jeff, with all that said , why do you do what you do?

Jeff Gothelf: That’s a great, a really great question. Look, I, at this point where I’m drifting towards, even more explicitly these days is I want to make companies more successful and I want people to be happier at their jobs. I want them to feel like they have an impact. Like they make a difference. Like they’ve positively changed somebody’s life. Look, I think back on my career and I bounced around a lot, especially in the early years because of the.com bubble bursting, that type of thing. The overwhelming majority of the work that I’ve done in that I did in the first half of my career, I wouldn’t want my name on it. and doing that work was a slog. It was tough. it was waterfall. It was top down command and control. And I felt like a cog in the machine. In the second half of my career, I’ve been able to do work in a far different way in a far more impactful way in a far more meaningful way.

And I know that exists, and I know that not a lot of people experience that. And so if I can help them through whatever, through workshops, training, through consulting, through coaching, their executives, through whatever it is through books and articles, rethink how they approach what they do every day in a way that satisfies them at work on one level and makes their customers was more successful, which in turn, then hopefully satisfies them as well.

Then that’s a win. That’s a win for me.

Jason Ogle: I love that. thank you for sharing that. Jeff, what’s your UX superpower.

Jeff Gothelf: I think my UX superpower is talking to customers. I think it’s the most powerful thing that you can do. And I think that, the more that you do it, the better you get at it. And it’s the number. It’s my number one. Go to tool in my toolkit. What’d we do first, I’m going to go talk to people, right? Get grounded in the real world.

Jason Ogle: it’s not user experience if you’re not talking to users, and customers too. It’s customer experience just as well. So I really like that.
What’s your UX kryptonite?

Jeff Gothelf: “My mom thought it was cool, so we built it.” Like in like in other words, as it’s 99% of startups, like I showed, I had an idea and I showed it to my mom or my significant other, and she, or he said it was awesome. So we’re building it. That’s my Kryptonite. You’re killing me.

Jason Ogle: Killing me Smalls.

Jeff Gothelf: Seriously. There’s so much material. There’s so much material, easily digestible material in every format you can imagine to teach you how to de-risk, some of your ideas and for you to be like, ‘My mom said it was cool, so I’m building it’. It’s like a knife through my heart. I can’t do it.

Jason Ogle: Yeah. Five most dangerous words: “There’s an app for that.”

Jeff Gothelf: Exactly.

Jason Ogle: To quote Golden Krishna. what would your UX superhero name be?

Jeff Gothelf: I think I’d be “Customer Obsession Man”. [laughter] Even today I was working, I was reviewing a findings deck for a client and it was all quantitative data. And did you talk to the customers about this? Like why they did this? Oh, no, we didn’t. We forgot. yeah. That’s I think that’s because Customer Obsession Man is, would be it.

Jason Ogle: Oh, that’s great. What’s one habit that you believe contributes to your success.

Jeff Gothelf: Inbox Zero.

Jason Ogle: Ooh, tell me more.

Jeff Gothelf: I just, my inbox, is, for me is a to do list. And my goal is to basically clear it out as best as I can. Like I’m not that person who’s got 78,102 unread messages in their Gmail. I currently. there are 12 unread messages in my inbox. I’m looking at it at the moment and those 12 messages came in while we were talking.

Jason Ogle: My goodness.

Jeff Gothelf: And so that’s, and I think that contribute to my success because I get back to people quickly. I delegate tasks that I don’t need to do myself and I archive and delete the rest of it. And so it just helps me just get out and get the crap out and focus on my work more and more easily.

Jason Ogle: it’s been said, if you don’t block your time, somebody else will. Like an email is a big part of that.

Jeff Gothelf: Absolutely.

Jason Ogle: What’s your most invincible UX resource or tool you can recommend to our listeners?

Jeff Gothelf: I look, I think in the reality that we’re living in right now, I’m in the kind of the globally distributed workforces that we’re forced into for me, some kind of a shared, collaboration space is absolutely critical. I’m a big fan of Mural. So I use Mural for everything. and it’s the go to thing for any kind of facilitation that I’m doing right now.

Let’s get that space up there. Let’s get to using it. Let’s build that shared understanding visually. And since we can’t be in the same place at the same time, this is the tool.

Jason Ogle: That’s awesome. In addition to, I’m going to recommend highly Lean UX, Sense & Respond and, maybe lesser known, design thinking versus Agile versus lean. Or I probably said that wrong, but lean versus Agile versus design thinking. it’s a really, it’s a quick read and it’s really great.

So in addition to those books, I’m going to recommend, and I’m sure I’m going to love Forever Employable by the way. but in addition to those books, that I genuinely recommend, I would like to ask you, Jeff, if you could recommend one book to our listeners, what would it be and why.

Jeff Gothelf: The book I’d recommend right now is, there’s two books I’d recommend that I can think of. Think of. So Melissa Perry’s, The Build Trap. Technically it’s a product management book, but Melissa comes from a UX background and she totally gets it. And the build trap is a really great look at, customer centricity in product.

So not necessarily in design specifically, but there’s no way you’re going to extract design from that. And so I would definitely read Melissa’s book, The Build Trap, and then the other one, I like a lot, these days is Barry O’Reilly’s Unlearn, kind of a more broader, methodology about rethinking what got you, your success so far? And what you’re going to unlearn to make room for learning new things, to keep moving you forward. And so I really liked those two books right now.

Jason Ogle: No, it sounds great. I’ll have links to those in the show notes, Defenders. What’s your best advice for aspiring UX superheroes?

Jeff Gothelf: My best advice is this, be humble and be curious. I think if I was hiring UX designers today, the hard skills is no longer the right way to say it, but like the technical skills, I can teach you that. But I can’t teach you humility and I can’t teach you curiosity.

And I think that if you can come at every job with it, I love this phrase. I use it in Forever Employable. I borrowed it from Astro Teller, the guy who runs Alphabets X, the moonshot laboratory and his Ted talk. he calls it enthusiastic skepticism. So to me, build that into your ways of working, be enthusiastically skeptical about your work.

In other words. Yes, it’s good, but I know there’s a better way, right? And there’s always a way to make it better or how can I learn to be better? Or what can I do? So it’s humility, curiosity put together is enthusiastic skepticism and that’s my best advice.

Jason Ogle: Ah, so good. Jeff, what’s the best way for the Defenders listening to connect and to keep up with you. Cause I know they’re going to want to.

Jeff Gothelf: Yeah, so easiest way. So everything you need to know is that JeffGothelf.com. It’s all there. connect with me on LinkedIn. I’m super easy to find. follow me on Twitter, @jboogie. It’s a long story. We don’t have time for it right now, but @jboogie

Jason Ogle: Oh darn

Jeff Gothelf: on Twitter. but that’s it. And that’s the best way to find out, but JeffGothelf.com is the easiest way.

Jason Ogle: Wonderful. Jeff, this has been amazing. Thank you so much for taking the time. Thank you for all that you have done and continue to do for our community and for humanity. you are a superhero, I just want to say last but not least fight on my friend.

Hide transcript