I’ve sat through enough “UX Research Workshops” to know they’re mostly just expensive ways to learn how to ask leading questions. Most of these polished, multi-step frameworks are designed for people with massive research budgets and nothing better to do than color-code sticky notes. But if you’re a dev or a solo founder, you don’t have that luxury; you just need to know why the thing is actually breaking. Learning how to interview your own users shouldn’t require a certification or a specialized toolkit. It’s not about validating your genius; it’s about finding the friction points before they turn into a high-priority ticket at 2 AM.

I’m not going to give you a list of academic best practices or tell you to build a persona profile for a user who doesn’t exist. Instead, I want to share the messy, unscripted way I actually get answers. I’ll show you how to cut through the polite lies people tell you to avoid hurting your feelings and get to the brutal truth of how they use your software. This is about practical, low-overhead tactics that work when you’re in the trenches and just need to stop guessing.

Mastering Customer Discovery Techniques to Avoid Production Disasters

The biggest mistake I see is treating customer discovery like a checkbox for a PM. If you go into a session looking for validation of the feature you just spent three weeks architecting, you’ve already lost. You aren’t looking for “yes” men; you are looking for the friction that causes a system to fail under real-world pressure. To do this properly, you need to lean into qualitative user research methods that force people to tell you about their actual workflows, not their idealized versions of them. I’ve learned that the most valuable data lives in the gaps between what they say they do and what they actually do when the UI gets in their way.

When you’re building your user research interview script, keep it lean. Don’t ask leading questions like, “Would this dashboard be helpful?” That’s a trap. Instead, ask them to walk you through the last time a task went wrong. This is how you actually start uncovering user pain points that aren’t documented in any Jira ticket. You want to find the manual workarounds, the Excel spreadsheets they use to bridge your API’s gaps, and the “temporary” fixes that have become permanent. If you don’t find those edge cases during the interview, you’ll definitely find them when the pager goes off at 2 AM.

Using Qualitative User Research Methods to Find Real Truths

When I talk about qualitative user research methods, I’m not talking about academic rigor or perfecting a lab setting. I’m talking about finding the gap between what a user says they do and what they actually do when the system starts throwing 500 errors. Most of the time, if you ask someone, “Would this feature be helpful?” they’ll say yes just to be polite. That’s a trap. You aren’t looking for validation; you are looking for the friction points that lead to support tickets.

The trick to uncovering user pain points is to stop acting like a salesperson and start acting like a forensic investigator. Instead of following a rigid user research interview script that feels like a deposition, try to steer the conversation toward recent failures. Ask them to show you exactly how they completed a task yesterday. When they stumble or express frustration, that is your real data.

You also have to watch out for avoiding interviewer bias—it’s much harder than it sounds. We all have a subconscious urge to lead the witness toward the solution we’ve already spent three weeks building. If you find yourself asking leading questions, stop. The goal isn’t to prove your architecture is sound; it’s to find out where it’s actually going to break in production.

Five things I learned from building things nobody actually wanted

• Stop asking if they like your idea. People are polite, and polite people lie to your face to avoid awkwardness. Instead, ask them how they currently solve the problem. If they aren’t already trying to fix it with a messy spreadsheet or a manual workaround, they don’t actually care enough to pay for your solution.
• Look for the “workaround” rather than the “wishlist.” When a user tells you, “It would be great if the system did X,” they are guessing. When they show you a post-it note stuck to their monitor with manual steps they have to follow every morning, they are giving you a real requirement. Build for the post-it note, not the wish.
• Embrace the silence. When you ask a question and the user stops talking, don’t jump in to fill the gap with a leading question or a clarification. Just wait. Usually, the most honest, unpolished insight comes right after that uncomfortable three-second pause when they’re actually thinking instead of just reacting.
• Watch their hands, not just their eyes. If you’re doing a remote session or a screen share, watch where they struggle to click or where they hesitate. A user saying “this is intuitive” while they spend thirty seconds hunting for the ‘Submit’ button is a technical debt signal you can’t afford to ignore.
• Record the friction, not just the features. I don’t care if they think the UI is “clean.” I want to know which part of the workflow makes them sigh or lean back in their chair. Those moments of micro-frustration are the early warning signs of a system that will eventually cause a support ticket avalanche.

What I’ve Learned from Building Things Nobody Wanted

Stop asking people if they “would” use a feature; they’ll lie to be polite. Instead, ask them how they currently solve the problem and look for the messy, manual workarounds they’ve already built. That’s where the real requirement lives.

If you aren’t feeling slightly uncomfortable during the interview, you’re probably leading the witness. If you find yourself saying “Don’t you think it would be better if…”, you’ve stopped researching and started pitching.

Treat user feedback like a production log, not a feature request list. Don’t just note what they want; note the friction points and the “why” behind their frustration. A list of features is a wishlist; a list of pain points is a roadmap.

The Post-Mortem of Your Assumptions

At the end of the day, interviewing users isn’t about collecting a tidy set of data points to present in a slide deck; it’s about de-risking your roadmap. We’ve talked about moving past the polished, leading questions and actually digging into the messy reality of how people interact with our systems. Whether you are using structured discovery or just sitting in on a support call, the goal is the same: to find the gaps between what we think happens and what actually happens. If you skip this, you aren’t saving time; you are just deferring a production incident that will eventually cost you a very long, very frustrating night of debugging a feature nobody actually wanted.

I’ve spent too many hours fixing “elegant” solutions to problems that didn’t exist, simply because I was too proud to ask the person using the tool if it actually worked. My advice is to treat user feedback like a system log—it might be noisy, and it might be uncomfortable to read, but it is the only source of truth that matters. Don’t build in a vacuum. Get out of your IDE, talk to the people breaking your software, and use what they tell you to build something that actually holds up when the load hits. It’s a lot easier to change a line of code today than it is to rebuild a broken architecture six months from now.

Frequently Asked Questions

How do I stop users from just telling me what they think I want to hear?

Stop asking “Would you use this?” You’re basically inviting them to lie to you to be polite. People are terrible at predicting their own future behavior, but they’re great at describing their past pain. Instead of pitching your idea, ask them to walk you through the last time a process failed. If they can’t describe the specific friction point, the problem doesn’t exist. Don’t build for their aspirations; build for their actual, messy reality.

What do I do if the feedback I get completely contradicts the technical roadmap we already committed to?

This is where the friction starts. You’ve got a roadmap built on logic and a user base telling you the logic is useless. Don’t pivot immediately—that’s just emotional whiplash. Instead, treat the contradiction like a production bug. Is the feedback a fundamental flaw in your architecture, or just a loud minority requesting a feature that doesn’t scale? Validate the “why” behind the noise. If the roadmap is technically sound but solves the wrong problem, stop coding and re-evaluate.

How much time should I actually spend on this before it starts feeling like I'm neglecting my actual sprint work?

Look, I get it. The Jira board is screaming, and every hour spent talking to users feels like an hour stolen from your sprint. But here’s the trade-off: spending five hours a week on discovery now is much cheaper than spending fifty hours next month rewriting a feature that nobody actually wanted. Aim for a predictable cadence—maybe one afternoon a week. If it starts eating your actual coding time, you’re doing too much; if you’re building in a vacuum, you’re doing too little.

Is there a way to run these interviews without feeling like a therapist or a salesperson?

The trick is to stop looking for validation and start looking for friction. If you’re pitching, you’re a salesperson; if you’re digging for trauma, you’re a therapist. Instead, act like a debugger. Don’t ask “How do you feel about this feature?” Ask “Show me the last time you tried to do X and it failed.” You aren’t there to fix their feelings; you’re there to trace the error logs of their actual workflow.

About Tomasz Wierzbicki

I am not interested in arguing about frameworks. I am interested in why the thing broke at two in the morning and what would have prevented it. Most of what I know came from being wrong in production and writing it down afterwards.