Notes
Monday, February 16, 2026

What Customers Say vs. What They Mean

Last week, a customer told me our product was "missing a critical feature." When I dug deeper, I found out they were trying to solve a problem we already solved—they just couldn't find it.

Customers rarely lie to you. But they also rarely tell you the truth in a way you can immediately act on.

Here's your translation guide for the most common things customers say, and what they actually mean:

1. "I need an export to Excel button"

What they mean: "I don't trust your data, I need to analyze it myself, or my boss requires a specific format."

Before you build the export button, ask: Why do they need the data in Excel? You might discover they're doing calculations you should build into your product, creating reports for stakeholders (build that report view), or they simply don't believe your numbers are accurate (you have a trust problem, not a feature problem).

The export button might still be the right answer. But now you know what you're really solving for.

2. "This is too complicated"

What they mean: "I can't figure out how to do what I came here to do."

They're not asking you to remove features. They're telling you the path to their goal isn't clear. Watch them try to complete their task. You'll probably find they're three clicks away from what they need, but those three clicks aren't obvious.

I've seen teams spend months simplifying products when all they needed was better onboarding or clearer labels.

3. "I love this feature!"

What they mean: "I'm being polite" or "I haven't used it enough to find the problems yet."

Early praise is almost worthless. People are nice. They want to encourage you. They're excited about the idea of the feature.

The real signal comes later: Do they keep using it? Do they tell their colleagues about it? Do they complain when it's slow or buggy?

If you get praise in week one and crickets in week four, that feature didn't actually solve their problem.

4. "Can you just add a simple toggle for that?"

What they mean: "I don't want to change my workflow, so give me an escape hatch."

Settings and toggles are technical debt in disguise. Each one doubles your test surface, splits your user base, and adds complexity.

When someone asks for a toggle, they're telling you the default behavior doesn't work for them. Don't ask "Should we add a setting?" Ask "Why isn't the default good enough?"

Sometimes the answer is that you have genuinely different user segments. But often, it's that you haven't nailed the default yet.

5. "This workflow takes forever"

What they mean: "There's friction I can't articulate" or "I have to wait for someone else."

Time them. Seriously. They'll say "It takes 20 minutes." You'll watch them do it in 3 minutes.

The actual problem is usually: waiting for approvals, switching between tools, manually copying data, or repeating the same task 50 times.

The solution isn't making your UI faster. It's removing the wait, integrating the other tool, or adding bulk actions.

6. "We need this to integrate with [tool]"

What they mean: "We have data in that tool that we need in yours" or "Our boss mandates that tool."

Before you build an integration, ask: What data needs to move between the tools? How often? Who uses it?

Half the time, they just need to import a CSV once. A quarter of the time, they're stuck with a legacy tool and won't actually use your integration. The remaining quarter is a real integration need.

7. "Your competitor has this feature"

What they mean: "I'm evaluating you against them" or "I want leverage to negotiate."

This one's tricky. Sometimes they're genuinely comparing products. Sometimes they're trying to pressure you into building something or lowering your price.

Ask: "How do you use that feature in [competitor]?" If they can describe it in detail, they're a real user. If they're vague, they saw it on a marketing page.

8. "This would be nice to have"

What they mean: "I thought of this just now and it sounds good, but I haven't actually felt pain without it."

These requests go straight to the bottom of the backlog. You're looking for "I currently do this hacky workaround" or "I pay for another tool just for this."

Pain scales. Nice-to-haves don't.

The pattern you're looking for

Real needs show up as stories about current behavior, not hypothetical futures.

"I need X" is a feature request. "Right now, I do Y and it's painful because Z" is a problem worth solving.

Your job isn't to build what customers ask for. It's to understand what they're actually trying to accomplish, and build something better than they imagined.

Stop taking notes. Start asking why.


Related reading: