When someone who uses your product every day tells you exactly what to build, the instinct is to listen. They’re the expert. They live in the workflow. They know what’s broken.

The problem is, they’ll almost always tell you a solution. Rarely the actual problem.

A user says “add a filter here.” Another says “this should open in a new tab.” A third wants a toggle to switch between two views. Each one feels specific, actionable, reasonable. And if you build all three, you now have a product with a filter, a tab, and a toggle that nobody asked you to reconsider. You’ve added surface area. You haven’t solved anything underneath.

This is how products get clunky. One reasonable feature request at a time.

The drift from problem to solution

There’s a book called The Mom Test by Rob Fitzpatrick that I keep coming back to. The core idea is simple. When you’re talking to users, don’t ask them what they want. Don’t ask them if your idea is good. Ask them about their life, their workflow, the specific moments where things break. Fitzpatrick’s three rules are basically, talk about their life instead of your idea, ask about specifics in the past instead of opinions about the future, and talk less and listen more.

The thing Fitzpatrick nails is that the drift from problem to solution happens in seconds. A user starts by saying “I can’t tell which of these items are new.” That’s a real problem. Useful. But within thirty seconds it becomes “so maybe add a counter here, and a badge there, and colour-code the new ones.” And now you’re co-designing a UI together instead of sitting with the actual issue, which might be that the information architecture itself is wrong and no amount of badges will fix it.

Your most engaged users, the ones who care enough to give detailed feedback, are also the most likely to hand you a feature shopping list. Because they’re problem-solvers by nature. They encounter friction, they immediately imagine a fix. That’s what makes them good at their jobs. But it’s also what makes their feedback dangerous if you take it at face value.

Why this hits differently in workplace software

Consumer products are “want” products. People choose to use them. If they don’t like it, they leave. So when a consumer user tells you what they want, there’s signal there because they’re telling you what would make them come back.

Workplace software is “need” software. People use it because the job requires it. And that completely changes the dynamic. When a workplace user says “I want to see the raw data behind this summary,” what they’re often actually saying is “I don’t trust the summary.” The request is for a feature. The problem is trust. And the solution to a trust problem is almost never “show more data.” It’s usually “show less data, but make it verifiable.”

This distinction matters because workplace products, especially ones that change how a person interacts with their core task, are not just adding a tool to someone’s stack. They’re asking someone to abandon muscle memory. A person who’s spent ten years doing their job a certain way, when you put a new product in front of them, their instinct is to describe the old way with slightly better buttons.

At Sidecar we run into this constantly. We’re building AI workplace software for freight forwarders, and when we sit down with operations people who’ve spent their careers in Outlook, their feedback almost always gravitates toward making our product more like Outlook. Which makes complete sense from their perspective. But if we build Outlook with AI stickers on it, we’ve trapped ourselves into maintaining assumptions from a workflow we’re supposed to be replacing.

The fine line between transition and transformation

This is genuinely the hardest product design question I think about, and I don’t have a clean answer for it.

When you’re reimagining a workflow, you’re walking a narrow line between two failure modes. Build something too different from the user’s existing mental model and they can’t adopt it. The cognitive load kills them before the value kicks in. But build something too familiar and you’ve just rebuilt the old thing with a new coat of paint. Quick adoption, sure, but you’ve locked yourself into every assumption the old workflow carried. And every future feature has to be backwards compatible with a way of working you were supposed to be moving past.

The way I’ve started thinking about this is through what I call transitional hangover vs. legitimate need.

Transitional hangover is when a user wants a feature because they’re still thinking in terms of their old workflow. “I want to open the original document in a new tab” might be transitional hangover if the whole point of your product is that the AI already extracted and verified the relevant information. The user doesn’t actually need the document. They need to trust the extraction. Those are very different problems with very different solutions.

But sometimes what looks like a transitional hangover is actually a legitimate need that you’d be stupid to ignore. “I want to see who’s CC’d without clicking into the message” might sound like a nitpick, but if CC lists determine who the user replies to and how they frame their response, you’re hiding decision-critical information behind an extra click. You’re just removing context from someone who needs it.

Telling the difference between these two, on every feature, every day, is the actual job.

Designing for workflows, not tasks

The Mom Test has this idea of “the question you’re afraid to ask.” In every user conversation, there’s one question that would give you the most useful information, and it’s usually the one you’re avoiding because the answer might invalidate what you’re building.

For anyone building workplace software that fundamentally changes a workflow, I think that question is: do your users actually want a different way of working? Or do they just want the old way to suck less?

If the answer is the second one, you have a product strategy problem that no amount of UX polish will fix.

And you won’t get the answer by asking the question directly. You get it by watching. Where do users lean into the new workflow? Where do they instinctively try to revert to the old one? The patterns tell you more than any feedback session.

The bigger thing I keep coming back to though is this. UI changes should never be for individual tasks. They should be for entire workflows. A task is “approve this item.” A workflow is the full sequence from intake to resolution. If you design for tasks, you end up with a screen full of action buttons, one per user request. If you design for workflows, you end up with something that guides the user through the natural sequence and only shows what matters at each step.

When users suggest task-level solutions, “add a filter here, add a button there,” they’re optimizing locally. The product person’s job is to zoom out and ask whether the workflow itself needs to change, not whether this particular screen needs another control.

Sitting with the problem

The instinct to jump from problem to solution is strong because it feels productive. Someone says “I can’t find what I need here” and your brain immediately goes to search bars and filters and sort options. Sitting with the problem, asking “why can’t you find it, what are you actually looking for, when was the last time this happened, what did you end up doing,” that feels slow. Uncomfortable. Like you’re not making progress.

But that’s where the actual product insight lives.

At Sidecar we have an in-house subject matter expert from the freight forwarding industry who tests our product daily. Every session is us catching the drift. He suggests a solution, we redirect to the problem. He describes what he wants to see, we ask what he’s trying to do. Sometimes his solution is exactly right. Sometimes the problem underneath points to something completely different from what he suggested.

The hardest part isn’t learning to ask about problems instead of solutions. It’s learning to stay there. To not immediately start sketching the fix. To let the problem sit long enough that the right solution becomes obvious, instead of grabbing the first one that sounds reasonable.

I catch myself doing it too. I sit in these sessions and write down “add a filter for agent threads” before I’ve even finished understanding why the user wanted to see only agent threads in the first place. It’s a muscle you have to keep training.

And honestly, I think that’s the real takeaway from The Mom Test that people miss. Everyone remembers “don’t ask leading questions” and “talk about their life not your idea.” But the deeper lesson is about discipline. The discipline to hear a user describe their pain and not immediately reach for the painkiller. To sit with the diagnosis a little longer. Because the first solution that comes to mind, whether it’s yours or the user’s, is almost always a patch. And patches on patches on patches is how products become the thing everyone complains about but nobody can fix.