They Shouldn’t Know It’s a “User” Interview
SubscribeSign in
They Shouldn’t Know It’s a “User” Interview<br>Done well, user interviews are a staple for product discovery. Done wrong, they’ll make you shoot yourself in the foot. With confidence.
Pawel Brodzinski<br>Aug 19, 2026
Share
In a short brainstorming session, we exchanged ideas for the most effective product discovery tools. Sure, the right tool is not right, period. It’s right only in the right context. No silver bullets here, sorry. Still, some evergreens emerge almost every time.<br>Assumption mapping is one. I personally like user journey mapping, too. However, there’s one thing that we don’t often consider a proper discovery technique, yet it should be a staple. User interviews.<br>User interviews definitely make it to my top 3. Yet, as with everything, there’s a caveat here.
Subscribe
The Mom Test
Before we jump to the actual analysis, I wholeheartedly recommend reading Rob Fitzpatrick’s The Mom Test. It’s short. It’s well-written. It tackles just one idea and does it superbly. Heck, it’s fun. Rarely is there a business book that crosses all the t’s and dots all the i’s. This one does.<br>Do yourself a favor and get a copy. Better yet, listen to the audiobook. The author does fabulous work turning it into something like an informal chat, rather than a professional yet dry-as-hell narration that’s the baseline for business literature. It feels almost like you got a chance to invite Rob Fitzpatrick for a few hours over coffees or beers. Which I would totally do, if I had a chance.<br>User Interviews 101
If you want to skip the reading (don’t), and user interviews are a new concept (they shouldn’t be), here’s the gist of it.<br>You talk with an existing user of your product (if you have some), or a potential one (if you don’t yet have any), for 30-60 minutes to get valuable insight into your plans. The plans may mean changing UX, adding a new feature, or building an entirely new product.<br>The tricky part: asking direct, closed questions along the lines of “Do you think this is a good idea?” or “Would you use it if we built it?” is the worst—and utterly useless—way to run user interviews. Also, it’s the most intuitive way, which makes the whole activity tricky.<br>By contrast, good questions revolve around interviewees’ needs and problems, and how they solve them now. In a way, it’s an exercise in beating around the bush to extract valuable insight that will validate (or, more likely, invalidate) the product assumptions you might have.<br>The Curse of Knowing Too Much
When we run engineering internships, we often ask the interns to build an MVP of a simple product. On more than a few occasions, we developed a thing for which we had potential customers inside Lunar. An obvious move was to interview these hypothetical future users.<br>So there I was, being user-interviewed by two interns. People with relatively limited engineering skills and no experience building products whatsoever. The only preparation they got was some advice from our product folks.<br>It was one of the best user interviews I’ve ever seen.<br>I got zero questions leading me to the idea that they might be working on a product. It was all about my problems and how I was handling them. We spent some 45 minutes chatting, and no products, features, or users were ever mentioned.<br>Lack of experience didn’t hold them back. In fact, it might have helped them. We prompted the interns to explore the problem, and that’s what they did. Founders, on the other hand, tend to be overly focused on their idea, which makes it so much harder to avoid treating their interlocutor as a potential user.<br>Now that I look back, I think that was the key part. It didn’t feel like I was a user in that interview.<br>They Shouldn’t Know It’s a “User” Interview
OK, the name of the technique doesn’t do it many favors. It’s called a user interview. It should be something something interview. I don’t know. A problem interview. A need interview. Yeah, I know. You don’t interview a problem.<br>Anyway. Revolving around the idea of a user tricks us into asking the wrong questions.<br>Hack 1: Never treat an interviewee as a user. If you mention the product, you’ve lost. If you mention the word “user,” you’ve lost.
Review your questions. If any of them might make an interviewee feel like they are a product user, throw it out and never look back.<br>Of course, in some contexts it would be blatantly obvious to an interviewee that they are, in fact, a user. It’s fine. Just make sure none of the questions suggest it. In any way.<br>Two Is Ten Times One
Our interns run their interview in a pair. In a new environment, trying to prove themselves, most would choose such a setup. It’s less stressful when you’re in it together. You can support each other. It’s a safe play.<br>Yet, once you get familiar with the task and the environment, it would be tempting to skip the pairing part. In this case, though, it’s so much better to run it as a duo. In this case, 2 * 1 = 10....