The Client Who Knew Our Product Better Than Me (And Why That Was Actually My Fault)

Three months into Finvestfx, I hopped on a call with the treasury head at a mid-size bank. We'd just shipped a new FX reconciliation feature I was pretty proud of. He spent the first 40 minutes of our call explaining, very patiently, why the entire flow was backwards.

He wasn't wrong. I'd built it for a workflow I thought made sense, not the one he actually used. The worst part? He'd told me this exact thing two months earlier. I just didn't listen.

The problem isn't that they think they know better. It's that they probably do.

When a client pushes back hard on your product decisions, the reflex is to defend. I did this constantly in my first year. I'd think: "They don't see the full picture. They're too close to their own process. They don't understand the technical constraints."

Sometimes that's true. But most of the time, especially in B2B, the client actually does know their domain better than you. They live in it 50 hours a week. You're building for 10 different companies at once, so you're always working from a generalized model.

At Finvestfx, I managed 20+ enterprise clients across forex and treasury. Every single one had a slightly different workflow. The ones who pushed back hardest were usually the ones who'd been doing treasury ops for 15 years. They knew every edge case, every regulatory nuance, every place where our "elegant" solution would break their actual day.

The trick isn't to out-argue them. It's to figure out whether their specific need represents a broader pattern or a one-off edge case.

Here's how I started handling it differently

First, I stopped going into client calls trying to defend the product. I started going in trying to understand where my mental model was incomplete. That's a subtle shift, but it changed everything.

When a client said "this feature doesn't work for us," I'd ask: "Walk me through exactly how you'd use this today. Start to finish. Don't skip the boring parts." Most PMs do discovery like this early on, but we stop once the product is live. That's the mistake. The client who's been using your product for six months has way more insight than the one you interviewed before building it.

Second, I got better at separating "you built the wrong thing" from "you built it for the wrong persona." At Finvestfx, we had one client who kept insisting our dashboard was too complicated. Another client said it was too simple. Turns out the first one was a senior treasury manager who wanted a 10-second overview. The second was an analyst who needed to dig into transaction-level detail. Both were right. I just hadn't built enough flexibility for different user types within the same org.

Third, I started being way more honest about constraints. When a client wanted something I knew we couldn't build, I'd say: "Here's why that's hard for us right now. Here's the tradeoff we'd have to make. Does that change how you think about it?" Half the time, they'd come back with a simpler version of the request that actually worked. The other half, they'd at least understand why we couldn't just "make it configurable."

The client I almost lost (and what I learned)

At Sonic Linker, we had an early enterprise client who was basically running their entire lead gen operation through our platform. They had opinions about everything. Every call turned into a feature negotiation.

I got frustrated. I started dreading our syncs. I'd think, "If they want this much customization, they should just build it themselves."

Then our founder asked me a simple question: "Why are they pushing so hard?" The answer was obvious once I said it out loud. They'd bet their entire Q3 pipeline on our product. If we didn't get it right, they were screwed. They weren't being difficult. They were terrified.

Once I reframed it that way, the dynamic changed. I started treating their feedback like an early warning system. If they were worried about something, there was probably a real product gap. I just had to figure out if it was their gap or everyone's gap.

We didn't build everything they asked for. But I got way better at explaining why, and way better at finding the 20% of their requests that would help 80% of our users.

What actually works

You don't have to agree with every client request. But you do have to take them seriously enough to understand where they're coming from. The ones who "think they know better" are often the ones who care the most. That's not a problem to manage. That's an asset to leverage.

Next time a client tells you your product is wrong, don't defend it. Ask them to show you how they'd fix it. You'll either learn something useful, or you'll get clarity on why your current approach actually makes sense. Either way, you'll stop seeing them as a difficult client and start seeing them as free product research.