The Client Who Rewrote My Product Spec Mid-Call (And Why I Let Them)
I was three months into Finvestfx when I got on a call with the CFO of a mid-sized exporter. We were demoing our forex reconciliation module, something I'd spent weeks speccing out with our dev team.
Five minutes in, he stopped me.
"This won't work. Your matching logic assumes we get bank statements daily. We don't. Sometimes it's weekly, sometimes the format changes mid-month, and half our transactions are split across multiple counterparties."
He wasn't being difficult. He was just right.
I had two options. Defend the product I built, or admit I didn't know his world as well as he did. I picked the second one, and it changed how I think about client expertise.
The Real Problem Isn't That They Know More. It's That You're Scared to Admit It
Here's the thing about enterprise clients, especially in finance or ops-heavy domains. They've been living in the problem space for years. You've been building a product for months.
At Sonic Linker, I worked with marketing teams who'd been running link-building campaigns since before I knew what a backlink was. At Finvestfx, treasury heads who understood currency hedging better than I ever would. The gap was real.
But most PMs, myself included at first, treat this like a threat. We get defensive. We explain why the product works the way it does, cite best practices, maybe throw in a "well, most clients actually prefer this approach."
That's ego talking. And it kills trust fast.
What I started doing instead was treating these clients like co-PMs. Not in a fluffy "customer collaboration" way, but literally. I'd send them rough specs before we built anything. I'd ask them to poke holes in the logic. I'd get on calls and say, "walk me through how you actually do this today, step by step."
At Finvestfx, this turned into a two-hour screen-share session where a client showed me their Excel hell. Fourteen tabs, manual lookups, three people touching the same file. I recorded it, sent it to the team, and we rebuilt the entire reconciliation flow based on that.
Retention on that account went from shaky to rock-solid. They renewed early.
When to Push Back (Because Sometimes You Actually Do Know Better)
Now, this doesn't mean roll over every time a client says "this won't work."
There's a difference between domain expertise and product intuition. Clients know their workflow cold. But they don't always know what's possible, what scales, or what breaks when you add 50 more users.
At Sonic Linker, we had a client who wanted us to build a custom CRM integration for their specific use case. It would've taken three weeks and served exactly one account.
I didn't build it. But I didn't dismiss it either.
I asked why they needed it. Turned out, they were manually copying link data into their CRM because our export format didn't match their fields. So instead of a custom integration, we added flexible field mapping to exports. Took two days, solved the problem for them and eight other clients who hadn't even asked yet.
The rule I follow now is simple. If a client says "this won't work for us," I believe them about their context. If they say "you should build it this way," I listen, but I decide based on whether it fits the product direction.
You own the product. They own their reality. Both can be true.
How I Actually Run These Conversations Now
When a client pushes back hard or tries to redesign something mid-demo, here's what I do:
- Stop defending immediately. Just listen. Let them finish. Most of the time, they're not attacking you, they're trying to help you not waste time building the wrong thing.
2. Ask for the underlying goal, not the feature request. "Why do you need it to work that way?" gets you to the real problem. Half the time, there's a simpler solution they haven't thought of because they're too deep in their current process.
3. Acknowledge what you don't know. I literally say, "I haven't worked in treasury ops, so I'm going to need you to walk me through this." It's not weakness. It's efficiency.
4. Separate "this won't work for us" from "this won't work for anyone." If it's specific to their workflow, maybe it's a config option or a manual workaround. If it's a fundamental flaw, you need to fix it for everyone.
At NJ Group, I coached 60+ advisors on product adoption for insurance and investment tools. Half of them had been in the field longer than I'd been alive. The ones who trusted me weren't the ones I impressed with product knowledge. They were the ones I let teach me how the business actually worked, and then I showed them how the product could fit into that.
The Takeaway: Confidence Without Ego
The best PMs I know are the ones who can hold two ideas at once. They're confident in their product vision and their ability to make decisions. But they're also humble enough to know they don't have all the context.
If a client thinks they know the product better than you, maybe they do. Or maybe they know their problem better than you, which is just as valuable.
Your job isn't to prove you're smarter. It's to build something that works. And sometimes, that means letting the client rewrite your spec mid-call, recording it, and thanking them for it.
That CFO at Finvestfx? He's still a client. And he still tells me when I'm wrong. I just don't take it personally anymore.