Brian Rhea Brian Rhea

Mastering Customer Interviews: Encouraging Honesty and Embracing Feedback

When you're kicking off customer interviews to collect feedback on a design or prototype, one of the most important things you should say is:

"None of the designers are on the call. You aren't going to hurt anyone's feelings."


"We're in the very early stages here, so please feel free to shoot down anything you see."

Even if it isn't true!

Nurture Honesty in Customer Interviews

People don't like hurting other peoples' feelings and your customers will lie to you to avoid the sense that they've delivered bad news.

You want to do everything you possibly can to relieve your customer of any sort of pressure or responsibility in the process.

It doesn't matter if I'm the actual designer that created the screens they're seeing and it's my favorite work of all time, or if we're one short sprint away from launching what they're about to see, at the beginning of all the customer interviews, I will say:

"This is very low stakes because we're still early on in this process."

"We're not at all invested in the specifics that you're about to see. But we are invested in getting it right so it's no big deal to us to blow this whole thing up."

"Feel free to be blunt, this isn't my baby. I've not put a lot of time into the prototype up to this point. My job is to poke some holes into what's here now."

Be Willing to Go Back to Square One

That whole thing about being willing to start back from scratch? You need to mean it.

A lot of the time, customer research folks will argue that you shouldn't show customers a prototype or a mock-up because it will prime their expectation and you'll be refined to a local maximum.

That's definitely true.

But in my experience, the greater risk is not that your customers will be primed or polluted by the prototype, but that you will!

Mock-ups are subject to the Lindy effect. Each time they're posted to Slack, someone will become attached to a certain element or offer an anecdote for why a potentially meaningless feature is an absolute must-have.

The longer mock-ups exist prior to customer research, the more likely they are to exist regardless of the results of customer research.

You have to be willing to trash your favorite screen, your favorite micro-interaction, your favorite anything if what you learn is that, in fact, it's not useful.

Neutrality is Easier When You're Early

You're going to get attached to your thing. Either because it becomes your Precious or because the inertia created by seeing it day-in-day-out lets you get used to it.

If you want to be able to mean it when you say, "Yeah, we're in the early stages here so be honest. You're not going to hurt any feelings," then have those conversations when that's actually true.

In building new things, the quote to always keep in mind is this gem by the founder of LinkedIn, Reid Hoffman:

"If you're not embarrassed by the first version of your product, you've launched too late."

Take that approach to your wireframes, mock-ups, prototypes, and your MVP.

What often happens is that founders and teams wait until they've fixed all the things that they think are wrong before showing it to anyone else. This puts you into diminishing returns way too early as you fine-tune all your own specific preferences, when in fact, there are massive gains to be made from just five customer interviews.

In short:

  • Talk to customers
  • Talk to them early
  • Let them know that they won't hurt anyone's feelings
  • Believe that to be true

Streamline Your Research with AI-Powered JTBD!

I'm working on, an AI-Powered tool to help you generate JTBD examples, forces analyses, job canvases, job maps, and switch timelines in 60 seconds!

Related posts

If you're still reading, you'll probably like these.

Jobs to Be Done Canvas: Mastering the Brush Strokes of Innovation

First things first, I gotta apologize for that dad joke of a title, but I just couldn’t help myself.

Jobs to Be Done Framework and Its Benefits

Are you looking for an innovative approach to understanding why a customer buys products or services?

Common Challenges in Jobs to Be Done Research: Overcoming Obstacles for Better Insights


Understanding Jobs-to-be-Done (JTBD) Analysis for Product Development

In today’s competitive marketplace, it’s more important than ever to understand your customers’ needs and develop products and services that meet those needs. One way to do this is to use Jobs-to-be-Done (JTBD) analysis.

The Worst Question to Ask a Customer in Product Development

“Would you use this?” is probably the worst and most expensive question you could ask a customer.

Why Small Businesses Should Embrace Nimble Business Planning

If you’re early stage and small, take advantage of those strengths with an equally small and nimble business plan.

Understanding Product Risk vs Market Risk for Startups

Understanding the difference between these two types of risk should change how you approach customer research.

The Lethal Mistake of Arriving at a Solution Too Early: Why You Should Fall in Love with Your Customer's Problem

One of the most common mistakes people make early on is jumping to a solution too quickly and getting attached.

The Dos and Don'ts of Customer Discovery Interviews

If you haven’t heard this nugget of truth yet, you will soon: “You’ve got to get out of the building.”

How to Deal with the Uncertainty of Startup Failure

I was a guest on a podcast talking about early-stage startups recently and the host asked: "We know most startups fail, but the number one reason is they don't meet a market need. Why is that?"

Disruptive Innovation: How Under-Doing Your Competitors Can Lead to Success

Do you find yourself in a market with a long-standing, dominant player, and you’re wondering:

Uncovering Unmet Customer Needs with Jobs to Be Done: Step-by-Step Guide

In this post, I’ll show you step-by-step how I’ve used the approach described in Tony Ulwick’s book, "What Customers Want" to help my clients get a much better handle on what to build, what to improve, what to leave alone, and what to ignore.

How to Write Jobs to Be Done Example Statements

If you're trying to integrate [Jobs to Be Done](/jobs-to-be-done-framework-benefits/) into your design process, you've probably found yourself looking for some concrete examples of Jobs to Be Done statements to be sure you're on the right track.

Choosing Between Simplicity and Reducing Complexity

I was having a conversation with a client recently and they’d more or less come to the conclusion that they needed to do a hard reset on the company and rebuild their application.

Kano Model (Part 2): Creating a Kano Model Survey for Customer Feedback

Using a Kano-based survey, you can avoid false positives (“Oh, sure I'd totally use that!” ... never uses it) and identify the features your product actually needs to have to satisfy and delight your customers.

Kano Model (Part 1): Understanding the Kano Model and Customer Satisfaction

What is the Kano Model?

Ready to know what your customers actually want? Get in touch.