How Lean UX builds better products: Q&A with Jeff Gothelf

Lean UX, a little prototyping and a whole lot of product development – we take a peek inside Jeff Gothelf’s mind.

This week, Justinmind was lucky enough to be able to talk to one of the biggest names in UX right now, Jeff Gothelf. As the co-author of Lean UX: Applying Lean Principles to Improve User Experience, Jeff’s hypothesis-based approach to user experience design has helped revolutionize product creation over the last five years.

In the book, which just launched its second edition, he and Josh Seiden combine lean ideas with design and strategy to build processes that are more collaborative, iterative and open. The result? Better teamwork, better transparency and, ultimately, better products. Products that people actually want to use.

We spoke to Jeff about Lean UX, its impact on business, and his tips for building a user-centric design process. Oh, and he also told us about that time he ran away to join the circus. No, really.

Can you explain what Lean UX is, in your own words?

To explain it concisely: Lean UX is how we integrate user experience and design into Agile product development. It’s really an approach to bring the customer into the center of the conversation consistently, and to do so in a cross-functionally collaborative way, working with colleagues in engineering, product management, marketing, and QA.

The point of that is to experience our ideas together as a team, so that we build a shared understanding of what’s working and what’s not. Instead of debating “does this work, does this make sense”, we actually get to the fun part of making products and services, which is figuring out how to solve problems. I think that’s the biggest benefit of practicing Lean UX.

Give us an example of what a Lean UX product development process looks like and where it fits in with Agile

If you think about Agile in the way it’s being adopted today – which is different from the way it was intended– but if you think about it in the way it’s adopted by most companies, Agile is focused on increasing the pace of delivery of software. The Agile folks call it ‘velocity’ – how to get more stuff out the door faster.

Where that fails is it doesn’t help teams determine what they should actually be working on, and it doesn’t help teams understand what done actually means. When you optimize velocity, done means “it works, we shipped it”; but that doesn’t tell us whether customers use it, whether it adds value, whether it makes our business more successful, etc.

And so what Lean UX does is it adds a brain, a decision-making mechanism into the Agile software delivery process.

We do that by discovering collaboratively what we should be working on. We take a look at what we’re tasked with doing, and we try to understand the business problem that we’re trying to solve. Baked into that business problem are typically a whole lot of assumptions about who the customer is, what value they might gain from a product or feature, etc.

So let’s extract those assumptions, and then using those assumptions we create hypotheses – testable statements that help us think about how we can potentially solve this business problem.

We then start to run experiments round those hypotheses to get a sense of whether they’re valid. Those experiments take many forms – landing page tests or feature fakes, for example – but even earlier than those tests you can bring in a lot of design-based tests like prototyping, paper sketches or customer interviews.

These are all ways where you can start to build a dialogue with the folks you’re building products for, to understand whether or not you’re actually building something they want.

So, outlining the steps of a Lean UX process: we take a cross-functional team, we get them to declare their business assumptions and write hypotheses; we start designing some solutions together to figure out how to build lightweight experiments against those designs; then we use that feedback to determine whether this is still a good idea and whether we should invest in developing it.

We’re moving away from the feature as the measure of success, and proposing a change in customer behavior, an outcome, as a measure of success.

Tell us a true story that illustrates why large enterprises should be investing in UX, and how they should be doing that?

There are several case studies in the book. One of my favorite is PayPal . We started engaging with them 4 years ago, and when we started working with them they would write 30 page specs to change one line of copy on the website, and it would take 2 months to implement.

Now they’ve taken a tremendously healthy step forward in modernizing their processes, the integration of design, front-end engineering and product management. They’ve facilitated a tech environment that allows them to build experimental prototypes, and then if those prototypes succeed they can move seamlessly from prototype to production.

Integration of their various disciplines has moved them away from heavy documents and deliverables, which kept them from moving forward with any kind of speed for a long time.

Another example is AutoTrader UK. As an organization they realized that implementing Lean UX is not a standalone silver bullet; they’ve taken the ideas behind Lean UX and have built cross-functional teams that are tasked with changing customer behavior.

They realize that this is a cultural shift as well, so they are changing how the teams are incentivized, measured for success and they are shifting the way they assign work to the teams.

One of the biggest challenges of product discovery or Lean UX is you frequently discover something that goes against what you were tasked with doing; that happens a lot, because what we’re tasked with doing is built on assumptions, and if we go in there and start to test those assumptions we may find that that task is the wrong thing to be doing.

In many organizations that’s not a very comfortable or safe conversation to have; very few people feel comfortable going up to their boss and saying ‘that’s a bad idea, we shouldn’t do that’. And so what AutoTrader UK has done is create a culture where evidence trumps: you can come in, present the evidence and use it as a justification for doing one thing instead of another.

That’s a cultural shift that is needed to support this way of working. It’s a big shift for companies to adopt this way of thinking and this way of working.

Top tips for building a strong UX team within an enterprise?

I think the best thing you can do is to start engaging with customers as regularly and consistently as possible, and bring as many people as you can to the conversation. The more we can expose people to customers, the more humility we start to drive into the organization and the resistance to Lean UX, product discovery and outcome-based management starts to soften. That’s key.

Jared Spool talks about exposure hours – the minimum hours per month that staff are required to spend with customers – and companies that mandate exposure hours build more successful products. By far that’s the most successful tactic.

The second tip is to build small dedicated cross-functional teams. Build these pods of product, design and engineering that sit together (if they’re distributed at least make sure they’re in the same or very close time-zones) working on the same project for an extended period of time.

You want these folks to get to know each other, to build trust, shared language and rapport, and through that simple spending of time together they start to look at different ways of working and respect each other’s opinions more. They start to think of themselves as a unit that wins or loses together.

If you already work in a company and you’re trying to get this way of working to be more mainstream, find the one executive that has already bought into the idea. There are executives in your company that have read all the lean books; find that executive and ask them to sponsor some kind of pilot initiative.

One of the most important things to getting this way of working accepted is transparency: people fear change, they fear for their job, their bonus, their salaries, and if you try to change stuff too quickly without telling them why, they’ll resist.

The more transparent you can be about why you’re trying to change and what that change looks like, the more likely you’ll be to drive meaningful impact in your organization.

You’ve spoken about Amazon as something of a software development paragon – what do they do that works?

I’ve spoken about Amazon both for good and bad in the past! There are things they do culturally as company that are right in line with this way of thinking – they put the customer first, solving real customer problems, delivering customer value and waiting for the business value to come from that as opposed to just shooting for short-term business gains.

Amazon has always had a customer centric point of view, but on the other hand they also have CEO/Founder who is very smart and opinionated, and he forgets some of these customer-centric mantras sometimes. Look at the Fire phone – that was a Bezos driven project focused solely on competing with Apple, that didn’t take into account any assumptions about customer value and that delivered a product that was DOA.

The company learned a very valuable and expensive lesson. If you hear Bezos talk about it today, he says, “we’re a huge company, we took a huge risk, and they only way we’re going to continue to grow and get better as a company is to take these risks”.

Very few companies are on the scale of Amazon, but taking small risks, doing experiments and running tests provides insight into where to go next with products and services. Lean Start-Up, Agile, Lean UX, product discovery – all of these things are risk mitigation tactics. That’s it.

If you could make risk mitigation into a sexy book title, you could sell it just like that. You’re reducing the risk of making things that people don’t want.

The second edition of your book is coming out in October, co-written with Josh Seiden – what updates have you made, and how has the Lean UX landscape changed since you first published?

It’s been 4 year since we turned in that manuscript: in those 4 years there’s been an even more rapid adoption of Agile, there are a lot more people practicing Lean UX and our thinking around what we wrote initially has evolved.

We wanted to update the book to include new case studies, explicit conversations around design sprints, the concept of dual track Agile and dual track Scrum, and to really update the thinking to be more strategic.

While the book is still practical and tactical, when we wrote it initially it was a very tactical designer to designer conversation, and we wanted to be more strategic because that’s where they questions that we’re seeing these days are headed.

People want to know how to get buy-in for this way of working, how to build it into roadmaps and planning, and how to use data to make decisions. We added a lot of those elements into the book and modernized it, and frankly just wrote it a bit better. We’re just better writers than we were 4 years ago!

There’s a hunger for participation in the strategic planning process by UX designers and designers in general. In most organizations designers don’t get that privilege, so this way of working helps make the design process more transparent, and hopefully more obvious to the folks who strategic decisions. Design and UX are critical to those strategic conversations.

Is it true you ran away and joined the circus after graduating? What did it teach you? What out-there advice would you give young graduates hoping to start their careers in UX?

It’s true! I was in my last week of university I wasn’t sure what I was going to do. I was partially a music major and partially a media production major, the circus was coming through town and they needed a sound guy.

It was a gig, and it paid more money than I’d ever made in my life; so I graduated on Saturday and I joined the circus on Monday, travelling with them up and down the East coast for 6 months. It was crazy and I hated it for a while, then I kind of learned to love it.

My advice is, do that crazy shit. I’ve been telling circus stories for 20 years and I wouldn’t have those stories if I didn’t do this crazy thing. I learned a ton about a world that I never knew existed, and in hindsight I wouldn’t trade it for anything. As crazy stuff like that comes up, take the risk.

Folks always ask me what’s a good way to break into design or Lean UX, and my answer is just start doing something – you don’t have to do it all, or transform a company or department top to bottom, but pick a thing that you care about and activity that you think will add value and take the initiative to drive it forward – take that risk.