Not too long ago, companies could exist offline. Back then, Jeff Gothelf started his career with the first businesses to go online.
More than two decades have passed since.
Today, Jeff works as a coach, trainer, speaker, and author, training executives in enterprise and high growth businesses around the world.
He’s been busy.
We talked to Jeff about his thoughts on the UX profession.
This article summarizes what we learned from him on:
- The concept of “Lean UX” - a collaborative approach to UX that requires you to validate solutions before you build them
- UX pitfalls that product leaders fall into
- Tech Debt and the harms of mindless shipping
- His tips for UXers in the current job market
Lean UX
Jeff has co-written an award winning book called “Lean UX”.
Reading is tough so we asked him to explain it to us instead.
What is Lean UX?
Jeff Gothelf defines it as follows:
“it is a way to take the designer's toolbox and apply it more broadly, to build across functional, collaborative, shared understanding of the problem that we're solving, the people that we're solving it for, and the measures of success once we've solved that problem, in an effort to learn quickly which solutions will deliver the value that we're looking for and solve the problem and which won't.”
We get that it’s a bit complicated — we asked for a lot of clarification 😁.
How is Lean UX different from “traditional” UX?
Traditionally, building products has been top-down and hierarchical.
A manager tells the designer what’s to be designed, what it should look like, how it should work, and the deadline which will let them keep their job.
This is risky business. Just look at the assumptions that go into the manager’s instruction:
- this problem is worth solving
- building this product/feature is the best way to solve this problem
- your users will like and use this solution
Instead of piling on all these risky assumptions, Jeff suggests a more collaborative approach.
- What’s the problem?
The manager should explain the problem instead of prescribing a solution. How is she sure this is a problem?
- What’s the outcome we want?
After the team knows the problem, they should think about what would be different after solving it.
- Will there be a change in user behavior?
- Which users should show this change?
- How would these users benefit from the solution?
- What are potential solutions to the problem?
Once this is done, the team will only come up with hypotheses of solutions.
- Will any of these solutions work?
Once the team has some hypotheses, they will come up with some ways to test these hypotheses using simple experiments. No product/feature has to be built at this step either.
- What should you build now?
Finally, if some experiments return positive results, the team should build new features/products based on these.
This process derisks development! Looking back at the assumptions we were making:
✅ this problem is worth solving. you have identified a real problem
✅ building this product/feature is the best way to solve this problem. you have already experimented with solutions
✅ your users will like and use this solution.̣ through experimentation, you have a good idea for what would help your users
As Jeff puts it, this is a radically different approach from “Yes boss, I’ll build the thing”.
To be clear, the “traditional” way is not ancient.
It is still commonplace, sadly.
Where does User Research fit into the Lean UX process?
“User research isn’t optional. Full stop.” says Jeff, winning Looppanel’s heart.
You conduct research to figure out the actual problem to be solved.
Then you conduct research to figure out how to solve it.
Research has never been more central to business.
Experimentation, validation, customer discovery, getting out of the building, — it’s called all sorts of things! Regardless of what you call it though, Jeff sees UX research as inseparable from the Lean UX process.
And yet, Product leaders aren’t talking to users
There are plenty of product folks out there who would like to talk to users but just never end up doing so. We asked Jeff about it. He has heard his fair share of excuses.
Some common pitfalls
Who has the time for it?
In most teams, people are rushing to finish the tasks they’ve been assigned. This rush leaves little time for thinking about what they’re doing. Talking to users, spending time coming up with hypotheses, testing these hypotheses — all of this will prevent you from hitting the next deadline. If teams fail to make time for it, meaningless shipping continues and the illusion of progress is constantly maintained.
Stick to the plan
Following through with Lean UX can end up contradicting the team’s current plan. You’ve already committed to the market, to your investors, to the boss who will control your promotion.
At that point, admitting that you’re building a solution no one wants is almost more painful than shipping something and then having it fall flat. Better to preserve your deadlines and dignity.
Where are my users?
Another common pitfall is people thinking their users are unreachable.
Executives in companies building mass consumed products have asked Jeff where to find users to talk to! If your organization sells cars, go stand in a parking lot — it’s that easy sometimes.
How to avoid these pitfalls?
Stop hyperfocusing on output and focus on outcomes instead. Mindlessly shipping features and versions is the best way to impress a boss who doesn’t know any better and lose the users you have.
PS: Following Jeff’s Lean UX canvas will prevent your team from endlessly building features no one asked for.
Speaking of which…
The tech debt you accumulate by shipping constantly
Amazon ships nearly every second.
And I still haven’t received my package.
Ba dum tisss.
But seriously, in a world where companies can ship to production in the time it takes you to say “ship”, shipping is a non-event. There must be better metrics of success.
The trap of velocity in product development
“Velocity” is a term straight out of the Scrum framework for project management. Regardless of how terrible they are at it, the framework is broadly adopted across all organizations.
The result? Teams focusing too much on the speed with which they ship code. Shipping things fast is great, of course, but not at the cost of outcomes. Building for the sake of building just makes you a bloated feature factory. Take YCombinator’s word for it.
Do users really love the last major update? Who cares — we have deadlines to meet!
Anything that gets in the way of making things faster is seen as an obstacle in the way of work. Talking to customers is more likely to be seen as an obstacle! There goes your dream of Lean UX.
A better North Star
It’s easy to believe that shipping a lot and shipping quickly is the best possible thing a team can do. Teams end up seeing shipping speed as their north star and can quickly be buried under features no one uses.
Shipping thousands of features no one uses will not help you.
Yes, shipping speed is important—but only if everything you ship gets you answers.
A better North Star to prioritize for would be learning.
Did your experiments leave you with more information about your users?
Did you uncover new user behaviors through the last few versions you shipped?
And yes, how fast can you learn?
If not, it’s time to pause and work through the steps of Lean UX again.
Another trip to the canvas won’t hurt anyone.
We hope this conversation with Jeff was useful for you. You can purchase his authoritative book on Lean UX through this link (not affiliate). Go build great products!
.webp)
.svg)
