3 Truths of Product Discovery & UX


Dear Reader,

Last week, I introduced you to "product discovery," a term for your team's work to build the right product.

It's an important term because too many teams are focused on delivering, a.k.a. building the product right.

If you're a designer stuck in delivery, you won't get to explore problems...only solutions.

UX Research, UX Strategy, and pretty much anything with UX requires time for discovery. Give a UX Designer all delivery tasks, and you will severely limit the methods she can use.

It's like trying to design with one hand behind your back.

Design can't reach its full potential if it only lives in delivery. Tacking a usability test at the end of a project is like "putting lipstick on a pig."

You might uncover a few problems, but what's the point if you've already decided what to build?

3 Truths of Product Discovery & UX

If you want to do UX and Product Discovery right, you have to accept these three premises to be true.

If you can't imagine saying these sentences out loud, you might be in more of a UI role in product delivery (a crucial role but not today's topic).

Oh, and you should yell them at the top of your lungs in your office ;)

1) "Your stakeholders and executives can't tell you what to design."

But boy, will they try!

It's not UX or product discovery if someone gives you detailed directions on exactly what to design and how. You have to work that out for yourself.

If people outside the product team tell you precisely what to build, it will always turn into product delivery, not discovery.

If you want to do product discovery, stakeholders and executives have to give you problems to solve, not solutions to build.

Discovery requires team empowerment, meaning the responsibility and authority to make decisions.

Empowered teams give decision-making power to the people building the product, not executives. It's a dream for both UX and Product Discovery.

2) "Your users can't tell you what to design."

All the Junior UX Designers just gasped.

It's true, though. Users don't have all the answers.

UX Researchers will know that not everything a user says is reliable, and self-reported wants and needs are unreliable (what users do should get more weight than what they say).

When customers tell you what they want, they tell you what they think they want. Instead of figuring out what they want, try to figure out why they say and do these things.

In the end, customers don't have the solutions...they have the problems.

It would help if you were going to your customers to understand problems. The way that you will solve that problem is up to the team.

3) "You can't decide what to design by yourself."

Just because you talk to users doesn't mean you have all the answers. You need the whole product team to figure out what to design and build.

Product discovery should be a collaborative activity. UX is also a collaborative role, but product discovery is even more collaborative.

You need the constraints of users, stakeholders, and execs, and you need the decisions of the product trio: the product manager, product designer, and even the engineers.

Even if you're an expert researcher or a data scientist with access to all the world's data, you can't decide what to build with gathered data alone. Product ideas should be prototyped and tested before the delivery stage, which should be the product team's work.

UX shouldn't be one person's job, and product discovery can't be.

TL;DR: Product discovery and UX share the collaborative challenge of deciding on the right thing to build despite the constraints of the users, business, and technology.

It ain't easy doing discovery. But if you're a UXer, the process should be familiar to you.

What is the product discovery process?

The Product Discovery process is a bit different from a typical UX process. There's a lot of generating data, not just gathering it.

Rather than building that shiny thing your CEO just dreamed up, you can implement an actual discovery process...and finally, get a say in what gets built.

I hope to see you there!

Jeff Humble
Designer & Co-Founder
The Fountain Institute

P.S. Last night, Maximilian Schmidt gave a talk called No Design Future Without Data. Watch the recording here and get the slides below:

No Design Future without Data.pdf

Have a great weekend, y'all!

The Fountain Institute

The Fountain Institute is an independent online school that teaches advanced UX & product skills.

Read more from The Fountain Institute

Every 2024 Newsletter You Missed by Jeff Humble Dear Reader, It's that time of the year again! Here are all the newsletters you missed in 2024 from the Fountain Institute: A Designer's Uncertain Path to Success Design Strategy vs. Design Vision: What's the difference? Is Poor Communication Hindering Your Projects? Balancing Freelance Life with Maya McBeath Innovation by Design with Cristina Colosi Shaping the Future of the Guild of Working Designers Figma Skills Won't Get You Promoted See...

A hand holding a illustration of a brain representing dyslexia

Turning Challenges into Confidence: Lessons from Dyslexia By Hannah Baker Dear Reader, When I was seven, I was an expert at pretending. I could "read" picture books without actually decoding the words, using context to fill in the gaps. It wasn’t until my mom, a teacher, noticed I was faking it that I was tested and diagnosed with dyslexia. What followed were years of frustration, advocacy, and learning how to embrace a brain that simply worked differently. While my initial reaction was...

4 risks of designing new products

28 Ways to Test an Idea (that is NOT an A/B Test) by Jeff Humble Dear Reader, Today I'm thankful for all the ways you can test that are not A/B tests. Executives and product people think A/B testing is the only thing on the testing menu. 🍽️ For me, it doesn't usually make sense to A/B test. Here's why: A/B tests should happen as late as possible. They might be the most scientific approach, but they require a lot of traffic. Plus, they're usually live and in code, so everything must be...