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:
Jeff has co-written an award winning book called “Lean UX”.
Reading is tough so we asked him to explain it to us instead.
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 😁.
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:
Instead of piling on all these risky assumptions, Jeff suggests a more collaborative approach.
The manager should explain the problem instead of prescribing a solution. How is she sure this is a problem?
After the team knows the problem, they should think about what would be different after solving it.
Once this is done, the team will only come up with hypotheses of solutions.
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.
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.
“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.
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.
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.
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.
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.
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…
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.
“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.
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!
Looppanel automatically records your calls, transcribes them, and centralizes all your research data in one place
.webp)
